Comparing Simple Role Based Access Control Models and Access Control Lists John Barkley National Institute of Standards and Technology Gait hersburg MD 20899 (301) 975-3346 j barkleyanist .gov August 11, 1997 Abstract The RBAC metaphor is powerful in its ability to ex- press access control policy in terms of the way in which administrators view organizations. The functionality of simple Role Based Access Control (RBAC) models are compared to access control lists (ACL). A very simple RBAC model is shown to be no different from a group ACL mechanism from the point of view of its ability to express access control policy. RBAC is often distin- guished from ACLs by the inclusion of a feature which allows a session to be associated with a proper subset of the roles (i.e., groups in ACL terms) authorized for a user. Two possible semantics for this feature are de- scribed: one which requires a similar amount of pro- cessing as that required by ACLs, and another which requires significantly more processing than that required by ACLs. In addition, the capability to define role hier- archies is compared to an equivalent feature in ACLs. 1 Introduction This paper compares simple Role Based Access Control (RBAC) models and access control lists (ACL). RBAC has several advantages over ACLs. Even a very sim- ple RBAC model affords an administrator the oppor- tunity to express an access control policy in terms of the way that the organization is viewed, i.e., in terms of the roles that individuals play within the organiza- tion. With RBAC, it is not necessary to translate a natural organizational view into another view in order to accommodate an access control mechanism. In addition, most RBAC models have features which most ACLs do not. In particular, some RBAC models[5][2][3] h ave role hierarchies where one role can inherit another. Much of this paper has been derived from the experiences of the NIST team which implemented RBAC on the World Wide Web (RBAC/Web)[l] for U nix and Windows NT servers’. This Introduction describes some concepts needed to discuss access control mechanism implementation. Sec- tion 2 briefly describes simple RBAC models and com- pares them to ACLs. Section 2.2 describes how a very simple RBAC model is no different from an ACL mech- anism which supports groups from the point of view of its ability to express access control policy. Section 2.3 discusses the implementation implications of associat- ing sessions with a proper subset of a user’s authorized roles. Section 2.4 describes how hierarchies are some- times implemented in ACLs. 1.1 Implementation Environment RBAC models are typically independent of the envi- ronment in which they may be implemented. For ex- ample, RBAC can be embedded in operating systems or database systems, or implemented at the applica- tion level. RBAC implementations discussed in this pa- per assume a network environment. All of the objects which are controlled by RBAC are spread among several servers connected by a network. Access control mechanisms require that security at- tributes be kept about users and about objects. User security attributes consist of things like the groups to which the user belongs and the roles authorized for the user. Object security attributes generally consist of the permissions required to perform operations on the ob- ject. Access control mechanisms compare user security attributes and object security attributes in order to de- termine access. Usually (although not always), object security at- tributes are kept with the object (e.g., in the header of a file) and the object resides on a single server. Con- sequently, when an object is accessed, its security at- tributes are quickly obtained once the object has been located. Changes in object security attributes need only be made at a single location. Bowever, in a network environment, the up-to-date values of user security attributes must be available to all servers. If user security attributes are kept on a single server, then that single server must be accessed across the network whenever user security attributes are ‘Because of the nature of this report, it is necessary to men- tion vendors and commercial products. The presence or absence of a particular trade name product does not imply criticism or endorsement by the National Institute of Standards and Technol- ogy, nor does it imply that the products identified are necessarily the best available. 127required by another server. If a copy of user security attributes is kept on each server, then when user security attributes change, those changes must be made on each server. 1.2 Processing Phases This paper compares the processing required for simple RBAC models and ACLs from the perspective of the processing phases associated with most access control mechanisms: Administration The Administration phase consists of creating and maintaining user and object security attributes. Administration tools are usually priv- ileged applications. Administration usually occurs the least often of the three phases. Session The Session phase consists of establishing, changing the characteristics of, and removing ses- sions. A session is a set of processes, called sub- jects, which act on behalf of a user. Session estab- lishment involves authenticating the user, creating one or more subjects, and associating user security attributes with each subject. The Session phase usually occurs more often than the Administration phase and less often than the Enforcement phase. Enforcement The Enforcement phase consists of com- paring the user security attributes associated with the subject (i.e., the subject security attributes) to object security attributes in order to grant or deny access. The Enforcement
View Full Document
Unlocking...