Role Based Access Control RBAC

Roles with different privileges and responsibilities have long been recognized in business organizations, and commercial computer applications dating back to at least the 1970s implemented limited forms of access constraints based on the user’s role within an organization. These role-based systems were relatively simple and application-specific. That is, there was no general-purpose model defining how access control could be based on roles, and little formal analysis of the security of these systems. The systems were developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards.

A general-purpose role based access control model was proposed in 1992 by Ferraiolo and Kuhn, integrating features of existing application-specific approaches into a generalized role based access control model. This paper presented RBAC as an alternative to traditional Mandatory Access Control (MAC) and Discretionary Access Control (DAC), and gave a formal description, in terms of sets, relations and mappings, to define roles and role hierarchies, subject role activation, subject-object mediation, as well as constraints on user/role membership and role set activation. Three basic rules were required:

1. Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role. The identification and authentication process (e.g. login) is not considered a transaction. All other user activities on the system are conducted through transactions. Thus all active users are required to have some active role.
2. Role authorization: A subject's active role must be authorized for the subject. With (1) above, this rule ensures that users can take on only roles for which they are authorized.
3. Transaction authorization: A subject can execute a transaction only if the transaction is authorized through the subject's role memberships, and subject to any constraints that may be applied across users, roles, and permissions. With (1) and (2), this rule ensures that users can execute only transactions for which they are authorized.

A key feature of this model is that all access is through roles.  A role is essentially a collection of permissions, and all users receive permissions only through the roles to which they are assigned, or through roles they inherit through the role hierarchy. Within an organization, roles are relatively stable, while users and permissions are both numerous and may change rapidly. Controlling all access through roles therefore simplifies the management and review of access controls. The 1992 Ferraiolo and Kuhn model was extended in 1995 by Ferraiolo, Cugini, and Kuhn.

In 1996, Sandhu, Coyne, Feinstein, and Youman introduced a framework for RBAC models that incorporated the RBAC features described above in a modular arrangement. RBAC0 was defined as the base model, defined through users, roles, and permissions. RBAC1 includes RBAC0 but incorporates hierarchies as a partial order relationship between roles. RBAC2 also incorporates RBAC0, but adds constraints. RBAC1 and RBAC2 are independent of each other, in that a system may implement one without the other. RBAC3 is a fully-featured RBAC model, incorporating RBAC0, RBAC1, and RBAC2. RBAC3 is essentially equivalent to the 1992 Ferraiolo and Kuhn model with the exception that RBAC3 allows a partial order hierarchy while the Ferraiolo-Kuhn model defines the hierarchy as a rooted tree. In object-oriented terms, the 1996 SCFY model can be thought of as incorporating multiple inheritance while Ferraiolo-Kuhn uses single inheritance.

There is a superficial similarity between RBAC roles and traditional groups.  As normally implemented, a group is a collection of users, rather than a collection of permissions, and permissions can be associated with both users and the groups to which they belong. The ability to tie permissions directly to users in a group-based mechanism can be regarded as a "loophole" that makes it difficult to control user-permission relationships. RBAC requires all access through roles, and permissions are connected only to roles, not directly to users.  Another aspect of RBAC that distinguishes it from traditional group mechanisms is the concept of a session, which allows activation of a subset of roles assigned to a user.  Core RBAC includes those systems with a robust group/ACL mechanism that supports the construction of a many-to-many relation among users and permissions.

RBAC is a separate and distinct model from MAC and DAC, but a number of relationships have been discovered. In particular, it has been shown that RBAC can simulate MAC and DAC [5][9], and that MAC can be used to implement RBAC [8] when the role hierarchy is a tree rather than a partial order.

RBAC is well suited to handling "separation of duty" requirements, and was in fact designed with SoD in mind.  This site contains several papers addressing SoD, and the RBAC standard covers this topic extensively (see "What is the RBAC standard", below).

Questions have also been raised as the suitability of RBAC for other relationships.  For example, a 2008 discussion of the RBAC standard includes the following concern:

"However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a "Doctor" role, but also needs to have the "Attending Doctor" role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role."

This type of situation was explicitly addressed in the 1992 RBAC model, which grants access 'only if', not 'if' or 'if and only if' the role requirements are met (an extremely important distinction). This was done to allow additional constraints to be added at access time.  No implementation details were specified for how to handle the additional constraints, since these would vary widely with the application and type of constraint.   The RBAC standard, as the 1992 model, is designed to allow designers to add constraints to handle these relationships.  In other words, nothing in the RBAC model will interfere with adding these constraints.  The standard could be amended to add the means to handle relationships like those suggested above, if there is sufficient community interest, and if there is a sufficiently general mechanism that addresses a wide variety of industries.

In 2000, NIST called for a unified standard for RBAC, integrating the Ferraiolo-Kuhn 1992 model with the RBAC framework introduced by Sandhu et al. in 1996. This proposal was published by Sandhu, Ferraiolo, and Kuhn and presented at the ACM 5th Workshopon Role Based Access Control. Following debate and comment within the RBAC and security communities, NIST made revisions and proposed a U.S. national standard for RBAC through the International Committee for Information Technology Standards (INCITS), the primary U.S. body for developing standards in information and communications technology. INCITS is also the American National Standards Institute’s (ANSI) Technical Advisory Group for ISO/IEC Joint Technical Committee 1, which is responsible for IT standardization at the international level. In 2004, the standard received ballot approval and was adopted as INCITS 359-2004.

Standard Structure.

Standard is in two parts:

• Reference Model, defined as a collection of four model components:  Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. The Model components provide a standard vocabulary of terms to define RBAC features;
• Functional specification of the model components.

Component summary.

• Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a Role-Based Access Control system. This includes user-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately.
• Hierarchical RBAC adds relations for supporting role hierarchies. Hierarchical RBAC goes beyond simple user and permission role assignment by introducing the concept of a role’s set of authorized users and authorized permissions.
• Static Separation of Duty Relations adds relations among roles with respect to user assignments. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, the SSD relations model component defines relations in both the presence and absence of role hierarchies.
• The fourth model component, Dynamic Separation of Duty Relations, defines relations with respect to roles activated as part of a user’s session.

Since the 1990s, an extensive body of scholarly work has been published on all aspects of RBAC. As of 2006, more than 6,000 articles on various aspects of RBAC are listed by Google Scholar. Some early results are given below.

RBAC MODEL

• Ferraiolo and Kuhn (1992) gave a formal definition of roles as sets of permissions, role hierarchies, subject-role activation, subject-object mediation, as well as constraints on user/role membership and role activation. [1]
• Nyanchama and Osborn (1994) developed a role graph model for RBAC, providing efficient algorithms for analyzing role relationships. [2]
• Ferraiolo, Kuhn, and colleagues developed a prototype RBAC implementation and a 1995 paper further developing the RBAC model with formal definitions of static and dynamic separation of duty. [3]
• Sandhu, Coyne, Feinstein, and Youman (1996) introduced a framework of RBAC models, breaking down RBAC into four conceptual models that can be combined to provide a variety of RBAC systems. [5]

RELATIONSHIP BETWEEN RBAC, MAC, AND DAC

• Sandhu (1996) showed that RBAC could be used to implement traditional multilevel security policies. [5]
• Osborn (1997) provided a role lemma that must hold in a system supporting both multilevel security and RBAC.
• Kuhn (1998) showed that a multilevel-secure system can implement RBAC, when the role hierarchy is a tree rather than a partial order. [8]
• Sandhu and Munawer (1998) provided a method of implementing discretionary access control using RBAC. [9]

SEPARATION OF DUTY

• Kuhn (1997) provided theorems on necessary and sufficient conditions to ensure safety in RBAC separation of duty. [6]
• Li,  Bizri, and Tripunitara  (2004) - extended results of Kuhn, 1997. [10]

Rudimentary forms of role based access control were implemented in a variety of ad hoc forms on many systems beginning in the 1970s.   RBAC as used today derives from the model  proposed by Ferraiolo and Kuhn (1992) and the model framework of Sandhu, Coyne, Feinstein, and Youman (1996).   The timeline below traces the evolution of today's RBAC.

• 1992 – Ferraiolo and Kuhn paper defining RBAC with access only through roles, hierarchies and constraints; formal model
• 1994 – DTOS based RBAC prototype developed by Ferraiolo, Kuhn, Gavrila
• 1994 – Nyanchama and Osborn paper defines role graph model
• 1994 – IBM files (in Europe) first patent application in RBAC area, cites Ferraiolo, Kuhn work as “closest prior art”
• 1995 – Ferraiolo, Cugini, Kuhn extended formal model, defined separation of duty forms
• 1996 – Sandhu Coyne, Feinstein, and Youman  paper on  family of RBAC models
• 1996 – Sandhu method for implementing MAC on RBAC system
• 1997-1998 – Sybase, Secure Computing, Siemens announce RBAC products described as based directly on Ferraiolo-Kuhn RBAC model
• 1997 – Secure Computing incorporates Ferraiolo-Kuhn RBAC model into US DoD Global Command and Control System
• 1997 – Kuhn paper on separation of duty; necessary and sufficient conditions for separation safety
• 1997 – Osborn paper on relationship between RBAC and multilevel security mandatory access (MLS/MAC) security policy models; role lemma relating RBAC and multilevel security
• 1997 – Ferraiolo and Barkley paper on economic advantages of RBAC
• 1998 – Kuhn method for implementing  RBAC on MAC system
• 1999 – Open source prototype RBAC for web servers developed by Barkley, Ferraiolo, Kuhn, Cincotta 
•  2000 – Sandhu, Ferraiolo, Kuhn paper defining unified RBAC model and propose RBAC standard  
• 2004 – American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) adopts Sandhu, Ferraiolo, Kuhn RBAC proposal as an industry consensus standard