Implementing Role Based Access Control
using Object Technology

John Barkley
NIST
B266 Tech
Gaithersburg MD 20899
(301) 975-3346
jbarkley@nist.gov
Tue Nov 28 08:31:40 EST 1995

With Role Based Access Control (RBAC), each role is associated with a set of operations which a user in that role may perform. The power of RBAC as an access control mechanism is the concept that an operation may theoretically be anything. This is contrasted to other access control mechanisms where bits or labels are associated with information blocks. These bits or labels indicate relatively simple operations, such as, read or write, which can be performed on an information block. Operations in RBAC may be arbitrarily complex, e.g., ``a night surgical nurse can only append surgical information to a patient record from a workstation in the operating theater while on duty in that operating theater from midnight to 8 AM.'' A goal for implementing RBAC is to allow operations associated with roles to be as general as possible while not adversely impacting the administrative flexibility or the behavior of applications.

Consider the possible activities associated with defining and modifying roles:

Information is usually accessed by applications based on a fixed set of operations defined by the mechanism or processor which is used to access the information. Applications are built based on a fixed set of operations which they routinely perform. For example, Unix files are accessed by the operations defined by the procedures: open(), close(), read(), write(), fseek(), etc.; tables in a relational data base are accessed by the operations defined by SQL.

Modifying the operations available to an application can have a great impact on an existing application. Removing an operation or modifying the semantics of an operation seriously affects an application's functioning and can produce very unpredictable results.

  
Figure 1: Implementing RBAC with layered objects

One approach which can be used to maintain flexible administration, minimize impact on applications, and maintain a significant capability for defining complex role operations is to use Object Technology in the following manner (see fig. 1). A complete set of operations based on access methods associated with the information storage mechanism is defined and held fixed. These are the operations that are made available to an application. These operations become the methods in a basic access methods class.

Access control for the basic access methods class is provided by role classes, one for each defined role. The methods of the role classes have the same names, types and parameters as the methods of the basic access methods class. Access control to the information accessed by the basic access methods class is located exclusively in the role classes and not in any other part of the application. The bodies of the methods in the role classes are restricted to:

If access is permitted for a role, the methods of the role class then invoke the corresponding methods of the basic access methods class. If not all information obtained by the basic access methods is permitted to a role, then the parts of the information not permitted can be filtered out. Filtering may be more desirable in a application rather than generating an access violation for the entire information block.

The methods of the application interface class also have the same names, types and parameters as the methods of the basic access methods class. The methods of the application interface class invoke the corresponding methods of the role classes. It is the methods of an application interface object which the application invokes. Given the current role associated with the application, the methods of the application interface object select the appropriate role object.

This approach has the following advantages:

  
Figure 2: Example basic access methods class for accessing patient information

In actual practice, RBAC roles, operations, and policy can be numerous and complex. In order to simplify this example, only a small subset of the roles, operations, and policy that would normally be required are illustrated.

This example has the following operations which can be performed by applications on a patient record database:

Get patient ID list
This operation obtains a complete list of patient names and their IDs.
Get patient record
This operation obtains the patient record given the patient ID.

Figure 2 shows C++ code for a basic access methods class (Access_PRDBO) which has methods (GetIDinfo(), and GetPR()) for performing these operations.

  
Figure 3: Example role classes for accessing patient information

Figure 3 shows C++ code for role classes associated with a patient (Pat_PRDBO) and doctor role (Doc_PRDBO). These role classes inherit from a base class (Role_PRDBO) which defines the names, types, and parameters for the methods which correspond to the methods in the basic access methods class. The patient and doctor role classes together implement the following RBAC policy:

In order to ensure that patients only access their own records, the patient role object (Pat_PRDBO) calls a system procedure which returns the patient ID for the user.

  
Figure 4: Example application interface class for accessing patient information

  
Figure 5: Example procedure to locate the proper role object

Figure 4 shows the application interface class (PRDBO) used by applications. When an object of this class is instantiated and a method of that object is called, that method first calls a system procedure (get_role()) which returns the user's current role. The method then calls another system procedure (get_role_obj()) which returns a pointer to the role object for that role. This procedure is shown in Figure 5. Finally, the method calls its corresponding method in the role object passing its input arguments to the role object method.

About this document ...

Presented at the First ACM Workshop on Role Based Access Control, November 1995

Author's email address:

John Barkley - jbarkley@nist.gov, (301) 975-3346

This document was generated using the LaTeX2HTML translator Version 0.6.4 (Tues Aug 30 1994) Copyright 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -t RBAC and Object Technology titlewkshp.tex.

The translation was initiated by John Barkley on Tue Nov 28 08:31:29 EST 1995


John Barkley
Tue Nov 28 08:31:29 EST 1995