In computer systems security, role-based access control is an approach to restricting system
access to authorized users. It is used by the majority of enterprises with more than
500 employees, and can implement mandatory access control or discretionary access control.
RBAC is sometimes referred to as role-based security.
Design Within an organization, roles are created
for various job functions. The permissions to perform certain operations are assigned
to specific roles. Members or staff are assigned particular roles, and through those role assignments
acquire the computer permissions to perform particular computer-system functions. Since
users are not assigned permissions directly, but only acquire them through their role,
management of individual user rights becomes a matter of simply assigning appropriate roles
to the user's account; this simplifies common operations, such as adding a user, or changing
a user's department. Three primary rules are defined for RBAC:
Role assignment: A subject can exercise a permission only if the subject has selected
or been assigned a role. Role authorization: A subject's active role
must be authorized for the subject. With rule 1 above, this rule ensures that users can
take on only roles for which they are authorized. Permission authorization: A subject can exercise
a permission only if the permission is authorized for the subject's active role. With rules
1 and 2, this rule ensures that users can exercise only permissions for which they are
authorized. Additional constraints may be applied as well,
and roles can be combined in a hierarchy where higher-level roles subsume permissions owned
by sub-roles. With the concepts of role hierarchy and constraints,
one can control RBAC to create or simulate lattice-based access control. Thus RBAC can
be considered to be a superset of LBAC. When defining an RBAC model, the following
conventions are useful: S = Subject = A person or automated agent
R = Role = Job function or title which defines an authority level
P = Permissions = An approval of a mode of access to a resource
SE = Session = A mapping involving S, R and/or P
SA = Subject Assignment PA = Permission Assignment
RH = Partially ordered Role Hierarchy. RH can also be written: ≥
A subject can have multiple roles. A role can have multiple subjects.
A role can have many permissions. A permission can be assigned to many roles.
An operation can be assigned many permissions. A permission can be assigned to many operations.
A constraint places a restrictive rule on the potential inheritance of permissions from
opposing roles, thus it can be used to achieve appropriate separation of duties. For example,
the same person should not be allowed to both create a login account and to authorize the
account creation. Thus, using set theory notation:
and is a many to many permission to role assignment relation.
and is a many to many subject to role assignment relation.
A subject may have multiple simultaneous sessions with different permissions.
Standardized levels
The NISTINCITS RBAC standard recognizes three levels of RBAC:
core RBAC hierarchical RBAC, which adds support for
inheritance between roles constrained RBAC, which adds separation of
duties Relation to other models
RBAC is a flexible access control technology whose flexibility allows it to implement DAC
or MAC. DAC with groups can emulate RBAC. MAC can simulate RBAC if the role graph is
restricted to a tree rather than a partially ordered set.
Prior to the development of RBAC, the Bell-LaPadula model was synonymous with MAC and file system
permissions were synonymous with DAC. These were considered to be the only known models
for access control: if a model was not BLP, it was considered to be a DAC model, and vice
versa. Research in the late 1990s demonstrated that RBAC falls in neither category. Unlike
context-based access control, RBAC does not look at the message context. RBAC has also
been criticized for leading to role explosion, a problem in large enterprise systems which
require access control of finer granularity than what RBAC can provide as roles are inherently
assigned to operations and data types. In resemblance to CBAC, an Entity-Relationship
Based Access Control system is able to secure instances of data by considering their association
to the executing subject. RBAC differs from access control lists, used
in traditional discretionary access-control systems, in that it assigns permissions to
specific operations with meaning in the organization, rather than to low level data objects. For
example, an access control list could be used to grant or deny write access to a particular
system file, but it would not dictate how that file could be changed. In an RBAC-based
system, an operation might be to 'create a credit account' transaction in a financial
application or to 'populate a blood sugar level test' record in a medical application.
The assignment of permission to perform a particular operation is meaningful, because
the operations are granular with meaning within the application. RBAC has been shown to be
particularly well suited to separation of duties requirements, which ensure that two
or more people must be involved in authorizing critical operations. Necessary and sufficient
conditions for safety of SoD in RBAC have been analyzed. An underlying principle of
SoD is that no individual should be able to effect a breach of security through dual privilege.
By extension, no person may hold a role that exercises audit, control or review authority
over another, concurrently held role. Use and availability
The use of RBAC to manage user privileges within a single system or application is widely
accepted as a best practice. Applications including Oracle DBMS, PostgreSQL 8.1, SAP
R/3, ISIS Papyrus, FusionForge, Wikipedia, Microsoft Lync, Microsoft Active Directory,
Microsoft SQL Server and operating systems implementing SELinux, grsecurity, TrustedBSD,
and many others effectively implement some form of RBAC. A 2010 report prepared for NIST
by the Research Triangle Institute analyzed the economic value of RBAC for enterprises,
and estimated benefits per employee from reduced employee downtime, more efficient provisioning,
and more efficient access control policy administration. In an organization with a heterogeneous IT
infrastructure and requirements that span dozens or hundreds of systems and applications,
using RBAC to manage sufficient roles and assign adequate role memberships becomes extremely
complex without hierarchical creation of roles and privilege assignments. Newer systems extend
the older NIST RBAC model to address the limitations of RBAC for enterprise-wide deployments. The
NIST model was adopted as a standard by INCITS as ANSI/INCITS 359-2004. A discussion of some
of the design choices for the NIST model has also been published.
Comparing with ACL The primary alternative option to the RBAC
model is the ACL model. A "minimal RBAC Model", RBACm, can be compared with an ACL mechanism,
ACLg, where only groups are permitted as entries in the ACL. Barkley showed that RBACm and
ACLg are equivalent. In modern SQL implementations, like ACL of
the CakePHP framework, ACL also manage groups and inheritance in a hierarchy of groups.
So, specific "modern ACL" implementations can be compared with specific "modern RBAC"
implementations, better than "old implementations". RBAC and employees' responsibilities alignment
In Aligning Access Rights to Governance Needs with the Responsibility MetaModel in the Frame
of Enterprise Architecture an expressive Responsibility metamodel has been defined and allows representing
the existing responsibilities at the business layer and, thereby, allows engineering the
access rights required to perform these responsibilities, at the application layer. A method has been
proposed to define the access rights more accurately, considering the alignment of the
responsibility and RBAC. See also
Access control list AGDLP
NIST RBAC model Discretionary access control
grsecurity Identity Driven Networking
Lattice-based access control PERMIS
Security classification XACML
References
Further reading David F. Ferraiolo; D. Richard Kuhn; Ramaswamy
Chandramouli. Role-based Access Control. Artech House. ISBN 978-1-59693-113-8.
External links FAQ on RBAC models and standards
Role Based Access Controls at NIST XACML core and hierarchical role based access
control profile Institute for Cyber Security at the University
of Texas San Antonio Trustifier RoBAC/RuBAC overview
Practical experiences in implementing RBAC Role-based approach to Active Directory delegation
The Monster Called RBAC Virtual Strategy Magazine 2012