|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BasicsSecurity 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 everyoneTo understand the important role of security, let's start with a simple query that does not explicitly mention security at all.
Over 18 level of securityLet's announce in the query that we have a certificate which permits access to 'over 18' protected information.
Other security levelsThere are three security certificates in the example movie database. Let's look at all the nodes for each certificate.
Curtis E. Dyreson, Michael H. Böhlen, and Christian S. Jensen © 1998-2000. All rights reserved. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
E-mail questions or comments to Curtis.Dyreson at usu.edu |