Role Based Access Control - Frequently Asked Questions
Back to Top
What is role based access control?
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:
- 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
- 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.
- 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
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.
Back to Top
How are roles different from groups?
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.
Back to Top
What is the relationship between RBAC, MAC,
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 , and that MAC can
be used to implement RBAC  when the role hierarchy is a tree rather
than a partial order.
Back to Top
What about complex relationships and constraints?
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).
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."
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.
Back to Top
What is the RBAC standard?
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 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
- Functional specification of the model components.
Back to Top
- 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
- 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
- The fourth model component, Dynamic Separation of Duty
Relations, defines relations with respect to roles activated as part of
a user’s session.
What theoretical results have been established?
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.
- 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. 
- Nyanchama and Osborn (1994) developed a role graph model
for RBAC, providing efficient algorithms for analyzing role
- 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. 
- 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. 
RELATIONSHIP BETWEEN RBAC, MAC, AND DAC
- Sandhu (1996) showed that RBAC could be used to implement
traditional multilevel security policies. 
- 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
- Sandhu and Munawer (1998) provided a method of implementing
discretionary access control using RBAC. 
SEPARATION OF DUTY
Back to Top
- Kuhn (1997) provided theorems on necessary and sufficient
ensure safety in RBAC separation of duty. 
- Li, Bizri, and Tripunitara (2004) -
extended results of Kuhn, 1997. 
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.
Back to Top
– Ferraiolo and Kuhn paper defining RBAC with access only
roles, hierarchies and constraints; formal model
– DTOS based RBAC prototype developed by Ferraiolo, Kuhn,
- 1994 – Nyanchama and
Osborn paper defines role graph model
– IBM files (in Europe) first patent application in RBAC
cites Ferraiolo, Kuhn work as “closest prior art”
– Ferraiolo, Cugini, Kuhn extended formal model,
separation of duty forms
– Sandhu Coyne, Feinstein, and
Youman paper on family of RBAC models
– Sandhu method for implementing MAC on RBAC system
– Sybase, Secure Computing, Siemens announce RBAC products
described as based directly on Ferraiolo-Kuhn RBAC model
– Secure Computing incorporates Ferraiolo-Kuhn RBAC model
DoD Global Command and Control System
– Kuhn paper on separation of duty; necessary and sufficient
conditions for separation safety
– Osborn paper on relationship between RBAC and multilevel
security mandatory access (MLS/MAC) security policy models; role lemma
RBAC and multilevel security
– Ferraiolo and Barkley paper on economic advantages of RBAC
– Kuhn method for implementing RBAC on
– Open source prototype RBAC for web servers developed by
- 2000 – Sandhu, Ferraiolo,
Kuhn paper defining unified RBAC model and propose
– American National Standards Institute, International
for Information Technology Standards (ANSI/INCITS) adopts Sandhu,
Kuhn RBAC proposal as an industry consensus standard
- D.F. Ferraiolo and D.R. Kuhn (1992) "Role Based Access
Control" 15th National Computer Security Conference, Baltimore, October
- M.Nyanchama and S.L. Osborn. "Access rights administration
in role-based security systems". Proc. IFIP WG11.3 working conference
on database security, 1994.
- D.F. Ferraiolo, J. Cugini, D.R. Kuhn(1995) "Role Based
Access Control: Features and Motivations", Computer Security
- R. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman
(1996), "Role-Based Access Control Models", IEEE Computer 29(2): 38-47,
IEEE Press, 1996
- Sandhu, R., “Role Hierarchies and Constraints for
Lattice Based Access Controls”, Proc.Fourth European
Sysmposium on Research in Computer Security, Rome, Italy, Sept. 25
– 27, 1996.when the role hierarchy is a tree rather than a
- D.R. Kuhn, "Mutual Exclusion of Roles as a Means of
Implementing Separation of Duty in Role-Based Access Control Systems"
Second ACM Workshop on Role-Based Access Control. 1997
- Osborn, S.L., Mandatory Access Control and Role-Based
Access Control Revisited, Proceedings of Second ACM Workshop on
Role-Based Access Control, Nov. 1997.
- D.R. Kuhn. "Role Based Access Control on MLS Systems
Without Kernel Changes"Third ACM Workshop on Role Based
Access Control, October 22-23,1998.
- Sandhu, R., Q. Munawer. How to do Discretionary
Access Control Using Roles. In Proc. of 3rd ACM Workshop on Role Based
Access Control (RBAC-98), Fairfax, VA, USA, October 1998, ACM Press.
- Ninghui Li, Ziad Bizri, and Mahesh V. Tripunitara
. Tripunitara. In Proceedings of ACM Conference on
Computer and Communications Security (CCS),