|
|
|
Basics
Security protects access to a node.
In our data model, edges can have a (required) SECURITY property
to restrict access to sensitive nodes.
We assume that the security is an encrypted certificate.
If the user possess a certificate and informs the database in
a query that they have a certificate, then the user has access
to any node protected by that certificate.
In all the examples below and elsewhere at this site, the security is
given in plain text rather than as an encrypted string for expository
purposes only.
In the movie database, the SECURITY is missing from
many of the edges, which means that if a user can gain access to the
from node for that edge, then they can extend a path to the
to node through that edge.
For the remaining edges, the SECURITY is a required property,
meaning that the query must match the property to traverse the edge.
The SECURITY property is matched by giving the appropriate certificate.
The SECURITY can evolve over transaction time, or any of the other
properties in the label.
Open to everyone
To understand the important role of security,
let's start with a simple query that does not explicitly
mention security at all.
What are the names of movie stars?:
The query result is duplicated below.
| Movie
| Name
|
| &Star_Wars_IV
| Bruce Willis
|
Only one name in one movie appears since
information about the other movie requires
an 'over 18' certificate.
|
Over 18 level of security
Let's announce in the query that we have a certificate
which permits access to 'over 18' protected information.
What are the names of movie stars, I'm 'over 18' folks!:
The query result is duplicated below.
| Movie |
Name |
|
&Star_Wars_IV |
Bruce Willis |
|
&Color_of_Night |
Bruce Wilis |
|
&Color_of_Night |
Bruce Willis |
See the transaction time examples
to learn why there are three rather than two or four tuples in the
result.
|
Other security levels
There are three security certificates in the example movie database.
Let's look at all the nodes for each certificate.
| All nodes at different levels of security.:
|
Curtis E. Dyreson,
Michael H. Böhlen, and
Christian S. Jensen
© 1998-2000. All rights reserved.
|