Authorization Models for Object-Oriented Databases

Frank is a researcher at Johann Wolfgang Goethe-University in Frankfurt, Germany. He can be contacted at [email protected].

It is essential that all databases support authorization to protect data. There are a variety of authorization models, most of which typically describe the kind of information protected, the scope of protection, any constraints, and the model's underlying functionality. Unfortunately, many of these models were originally developed for relational database systems and, because of the huge number of complex objects that can be stored, may not always be appropriate for object databases (ODBMSs). In this article, I will present a flexible method of providing customized authorization to object-oriented databases. This approach is based on Prolog-like rule mechanisms and triggers, and supports definition and execution of authorization models for an ODBMS.

Traditionally, there are two types of access control -- discretionary and mandatory. Discretionary access control lets users determine how they will access the data/objects they own. Mandatory access control, on the other hand, links protection to data, so that users can only access data and/or objects according to specified "rules." Here, I will focus on discretionary access control for ODBMS.

An authorization rule such as (user, right, object) says a user owns access rights to an object. If there is no corresponding authorization rule, access is denied by default. To minimize the number of rules and optimize maintenance, some rules imply others and need not be specified explicitly. For instance, (user, UPDATE, object) can imply (user, READ, object), as long as the right to update an object presumes the right to read it. Furthermore, implications such as this can be extended to users and objects themselves. To disable implied authorizations (referred to as "explicit access denial"), "negative" authorization can be expressed as (user, !right, object). General requirements that must be fulfilled by implementing and executing an authorization model primarily concern authentication, confidentiality, consistency, scalability, transparency, auditing, and administration.

Conventional Authorization Mechanisms

Checking for authorization every time a stored object is accessed would be highly inefficient. Consequently, ODBMS authorization models try to group objects with common characteristics. There are several models that theoretically provide ODBMSs with discretionary-access control, the main differences among them being scope. For the sake of example, I will briefly examine the class-level model because of its simplicity.

With the class-level model, access to an attribute of an object is granted or denied according to authorization rules attached to the class from which they are instantiated. For example, applying inheritance properties to the schema in Figure 1 results in the effective schema of Figure 2. An authorization rule might say that a student advisor is allowed to read the attribute Year of any Student. A set of "policies" (that is, general rules responsible for granting certain access) describe the authorization implications:

• Policy 1 (inherited authorization). Users who have access to a class are allowed to have a similar type of access on the corresponding subclasses to the attributes inherited from this class.
• Policy 2 (class access). Access to a complete class implies access to the attributes defined in that class as well as to attributes inherited from a superclass (but only to the class-relevant values of these attributes). If there is more than one superclass (multiple inheritance), access is granted to the union of the inherited attributes.
• Policy 3 (visibility). Attributes defined for a subclass are not accessible by accessing any of their superclasses.

For example, if the student advisor wants to read the Year of a Foreign Student, he is authorized by applying Policy 1. The access to the Visa, however, would be denied following Policy 3.

An Alternative Authorization Mechanism

The most effective method of placing access control is to extend the schema/object manager. Whenever a class definition or object is requested, this manager can check the authorization of the request. Modifying the manager, however, will likely result in greater work on the part of the programmer. Moreover, every change in authorization policy implies the need for a modification of the manager. Thus, implementing authorization mechanisms within the schema/object manager should only be done if the policies are fixed, and no changes are expected. Access control by precompiling means analyzing existing code in order to insert additional code that can perform appropriate authorization checks. This mechanism has to be extended for any kind of access, especially for the query language and available APIs. Any access to data offered by predefined methods (list primitives, for instance) cannot be controlled in this way. Therefore, except for prototyping concerns, precompiling should not be applied.

Objects in an ODBMS play a different role than data in other database systems. Whenever information flows, messages have been sent to objects. This message passing can easily be monitored and exploited for different needs, including triggering. Rules as part of a schema can be used to keep the database consistent. For access control, you can write rules that perform authorization checks on instantiated objects. Using trigger mechanisms, an authorization model can be implemented without intervention in the running code of a database application or underlying schema/object manager.

To illustrate class-level access using rules, I will present a model for administration of authorization in an ODBMS called Security in an Object-Oriented Database (SecOO). SecOO is based on the authorization model described by E.B. Fernandez, E. Gudes, and H. Song, in "A Model for Evaluation and Administration of Security in Object-Oriented Databases," IEEE Transactions on Knowledge and Data Engineering, April 1994. SecOO is implemented by applying a Prolog-like rule interpreter and trigger mechanism described by C. Collet, T. Coupaye, and T. Svenson (Project GOODSTEP, Technical Reports No. 10 and 11, Laboratoire de GENIE INFORMATIQUE, University Joseph Fourier of Grenoble, France).

As Figure 3 shows, the SecOO system runs on top of an ODBMS and is responsible for installing triggers/rules and managing the administration of users (groups), their authentication, and authorization grant/revocation. All of these services are communicating with the authorization server, running as a single process to serve multiple ODBMS clients. This server behaves like an interpreter for Prolog rules, which are used to describe authorization models in a flexible way.

To see how you create triggers/rules for application code, consider the authorization model and one class of the class hierarchy discussed in Figures 1 and 2 and described in Listing One For class-level authorization, SecOO generates the triggers/rules shown in Listing Two.

After enabling these triggers/rules for each access to the attribute Year of an instance of Student, the corresponding rule is fired, regardless of whether it belongs to a query, running method, API program, or ad hoc request. The requested action will be approved according to the underlying authorization model. It will be continued upon success or canceled with an access violation. The authorization check performed a call to a special method access that is part of SecOO. This will first check the user's authentication and, if necessary, perform a login. Then it will call the SecOO server, which must determine if the requested access can be granted. The method returns False on denial, which cancels the query due to access violation; otherwise it returns True, and the action continues. SecOO processes all classes, their attributes, and inheritance relationships, and generates triggers/rules and SecOO facts, which are interpreted for implication computing. Upon class generation or modification, services are called that keep track of the triggers/ rules and their corresponding entries (facts) in the SecOO server.

SecOO Rules

For further illustration, I present two sets of Prolog-like rules. The first set contains database- and application-dependent facts (rules without body) and are determined by SecOO, database administrators, and database users at run time. The second set contains rules suitable for both representing and executing the authorization policies determined by the database designer. These policies instantiate the access control mechanism offered by SecOO. To protect objects instantiated from certain classes, class information must be provided. This is done with two kinds of facts. One kind describes the composition of a class, the other describes the inheritance relation; see Listing Three.

The first fact, for instance, expresses that the class Person consists of the two attributes, Name and SSN, and that the class Student is a subclass of class Person. A second category of facts is concerned with explicit authorization rules. These rules can be given for a single attribute or for a complete class; see Listing Four.

These facts represent specific information about the actual state of a database -- its classes, users (groups), and explicit authorizations. The facts have to be updated whenever a class, group, or authorization is modified, deleted, or added. This is done by services on the ODBMS client, which communicate with the SecOO server.

The rules in Listing Five describe authorization implication and build the core of an actual SecOO server instantiation. Rules are grouped into policies. The set of given policies describes a major part of the chosen authorization model. This set is fixed as long as the proposed model is able to fulfill security needs. Access to a single attribute or a complete class will be granted if there is an explicit authorization rule for it (the arrow represents the implication direction).

Access to a single class attribute implies access to this attribute in all derived classes (Policy 1); see Listing Six. In Listing Seven, access to a complete class implies access to all (transitively inherited) attributes (Policy 2), while in Listing Eight, a certain right on an attribute implies all its lower rights.

SecOO is designed to minimize the number of access checks by enabling/disabling generated triggers. Whenever a group is authenticated, all demanded triggers are enabled. On any successful access to an object (attribute), the corresponding triggers are disabled. Any subsequent access to objects (attributes) of this class are granted as long as a new login or change in the server's fact base have not taken place; see Figure 4.

This mechanism guarantees full data protection and a minimal decrease in efficiency for applications (methods) stored in the database.

SecOO Administration

SecOO provides a set of administration commands that supplement the ODBMS shell and are dependent on the instantiated authorization model. For the model I have described here, these commands are:

• control <class> [<attribute>]. Installs appropriate triggers and provides the SecOO server with structural information for a given (complete) class or a single attribute. Any further access to (attributes of) objects of this class will be controlled by SecOO.
• release <class> [<attribute>]. The reverse command of control.
• login. Used to authenticate a group by asking for a password, which automatically enables/reenables all installed triggers.
• change_password. Used to change the password of the actual group.

There are also special commands that can only be executed by the database administrator:

• grant access <group><right><class> [<attribute>]. A command that grants access.
• revoke access <group><right><class> [<attribute>]. A command that revokes access.
• insert group <group>. A command that adds a new group.
• add domination <groupA> <groupB>. A command that creates a domination relation from groupA to groupB.
• remove group <group>. A command that removes an existing group including its potential access rights.
• rename group <group>. A command that renames an existing group (which does not affect its access rights).

Conclusion

The approach I have suggested here offers flexibility and a distinct way to formalize authorization policies. Still, further development is needed in this area. For instance, we are still working on ways to keep the rule base up to date with class information. We are also working on the semantics of negative authorizations.

DDJ

Listing One

class Student inherit Person     type tuple ( Year : integer ) 
end;

Back to Article

Listing Two

create rule Student_Year_update    on before update Student->Year with o 
     if ( !access( update, o->class_o f, "Year" ) ) 
   do instead { abort( "access violation " ); } 
create rule Student_Year_read 


</p>
   on before read Student->Year with o 
     if ( !access( read, o->class_ of, "Year" ) ) 
   do instead { abort( "access violation " ); } 
create rule Student_update 


</p>
   on before update Student with o 
     if ( !access( update, o->class_of  ) ) 
   do instead { abort( "access violation " ); } 
create rule Student_read 
   on before read Student with o 
     if ( !access( read, o->class_of  ) ) 
   do instead { abort( "access violation " ); } 

Back to Article

Listing Three

class ( 'Person', ['Name', 'SSN'] ). class ( 'Student', ['Year'] ). 
class ( 'ForeignStudent', ['Visa'] ). 


</p>
inherits( 'Student', 'Person' ). 
inherits( 'ForeignStudent', 'Student' ). 

Back to Article

Listing Four

expl_access( 'advisor', write, 'Person' ). expl_access( 'student_advisor', read, 'Student',' Year' ). 

Back to Article

Listing Five

policy explicit_authorization    access(Group, Right, Class, Att ) <- 
        expl_access ( Group, Right, Class, Att ). 
   access( Group, Right, Class ) <- 
        expl_access ( Group, Right, Class ). 
end policy. 

Back to Article

Listing Six

policy inherited_authorization    access( Group, Right, SubClass, Att ) <- 
       inherits( SubClass, SuperClasses ), 
       member( SuperClass, SuperClasses ), 
       access( Group, Right, SuperClass, Att ). 
end policy. 

Back to Article

Listing Seven

policy class_access    inherited ( Class, Att ) <- 
       class( Class, AttList ), 
       member( Att, AttList ). 
   inherited ( Class, Att ) <- 
       inherits( Class, SuperClasses ), 
       member( SuperClass, SuperClasses ), 
       inherited( SuperClass, Att ). 
   access( Group, Right, Class, Att ) <- 
       inherited( Class , Att ), 
       access( Group, Right, Class ). 
end policy. 

Back to Article

Listing Eight

policy right_domination     access( Group, RightA, Class, Att ) <- 
        rdom( RightB, RightA ), 
        access( Group, RightB, Class, Att ). 
    access( Group, RightA, Class ) <- 
        rdom( RightB, RightA ), 
        access( Group, RightB, Class ). 

    rdom( update, read ). 
end policy. 

Back to Article