View source for Role-based access control

{{short description|Approach to restricting system access to authorized users}}

In computer systems security, '''role-based access control''' ('''RBAC''')<ref>{{ cite journal|author1=Ferraiolo, D.F. |author2=Kuhn, D.R. |name-list-style=amp | title = Role-Based Access Control | journal=15th National Computer Security Conference |date=October 1992 | pages=554–563 | url = http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf }}</ref><ref>{{ cite journal | author = Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. | title = Role-Based Access Control Models | journal = IEEE Computer | volume=29 | issue=2 |date=August 1996 | pages=38–47 | url = http://csrc.nist.gov/rbac/sandhu96.pdf | doi=10.1109/2.485845| citeseerx = 10.1.1.50.7649 | s2cid = 1958270 }}</ref> or '''role-based security'''<ref>{{ Cite book |author1=ABREU, VILMAR |author2=Santin, Altair O. |author3=VIEGAS, EDUARDO K. |author4=STIHLER, MAICON |title=2017 IEEE International Conference on Communications (ICC) |chapter=A multi-domain role activation model | pages = 1–6|date=2017 | publisher=IEEE Press | url = https://secplab.ppgia.pucpr.br/files/papers/2017-1.pdf | doi=10.1109/ICC.2017.7997247| isbn = 978-1-4673-8999-0|s2cid=6185138 }}</ref> is an approach to restricting system access to authorized users, and to implementing [[Mandatory access control|mandatory access control]] (MAC) or [[Discretionary access control|discretionary access control]] (DAC).

Role-based access control is a policy-neutral access control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments. A study by NIST has demonstrated that RBAC addresses many needs of commercial and government organizations.<ref>{{cite book | chapter=An examination of federal and commercial access control policy needs | publisher=DIANE Publishing | title=National Computer Security Conference, 1993 (16th) Proceedings: Information Systems Security: User Choices | vauthors=Gilbert MD, Lynch N, Ferraiolo FD | page=107 | date=1995 | isbn=9780788119248 | chapter-url=https://books.google.com/books?id=vQEHUD51YNEC&q=An+examination+of+federal+and+commercial+access+control+policy+needs&pg=PA107}}</ref> RBAC can be used to facilitate administration of security in large organizations with hundreds of users and thousands of permissions. Although RBAC is different from MAC and DAC access control frameworks, it can enforce these policies without any complication.

== Design ==
Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Since users are not assigned permissions directly, but only acquire them through their role (or roles), 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|hierarchy]] where higher-level roles subsume permissions owned by sub-roles.

With the concepts of [[Role hierarchy|role hierarchy]] and constraints, one can control RBAC to create or simulate [[Lattice-based access control|lattice-based access control]] (LBAC). 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: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
** 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 to 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|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#Basic concepts and notation|set theory notation]]:
* <math>PA \subseteq P \times R</math> and is a many to many permission to role assignment relation.
* <math>SA \subseteq S \times R</math> and is a many to many subject to role assignment relation.
* <math>RH \subseteq R \times R</math>

A subject may have ''multiple'' simultaneous sessions with/in different roles.[[File:Role-based access control.jpg|thumb|RBAC]]

=== Standardized levels ===
The NIST/ANSI/INCITS RBAC standard (2004) recognizes three levels of RBAC:<ref name="BelussiCatania2007">{{cite book|author1=Alberto Belussi|author2=Barbara Catania|author3=Eliseo Clementini|author4=Elena Ferrari|title=Spatial Data on the Web: Modeling and Management|url=https://books.google.com/books?id=wtDj6VEG7SIC&pg=PA194|year=2007|publisher=Springer|isbn=978-3-540-69878-4|page=194}}</ref>
# 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 [[Discretionary access control|DAC]]<ref>{{ cite journal|author1=Ravi Sandhu |author2=Qamar Munawer | title = How to do discretionary access control using roles | journal=3rd ACM Workshop on Role-Based Access Control |date=October 1998 | pages=47–54 }}</ref> or [[Mandatory access control|MAC]].<ref>{{ cite journal|author1=Sylvia Osborn |author2=Ravi Sandhu |author3=Qamar Munawer |name-list-style=amp | title = Configuring role-based access control to enforce mandatory and discretionary access control policies | journal=ACM Transactions on Information and System Security | year = 2000 | pages=85–106 }}</ref> DAC with groups (e.g., as implemented in POSIX file systems) can emulate RBAC.<ref>{{Cite journal|first1=Achim D.|last1=Brucker|first2=Burkhart|last2=Wolff|title=A Verification Approach for Applied System Security|journal=International Journal on Software Tools for Technology Transfer|volume=7|issue=3|pages=233–247|year=2005|doi=10.1007/s10009-004-0176-3|url=http://www.brucker.ch/bibliography/abstract/brucker.ea-verification-2005.en.html|hdl=20.500.11850/52625|s2cid=6427232|hdl-access=free}}</ref> MAC can simulate RBAC if the role graph is restricted to a tree rather than a [[Partially ordered set|partially ordered set]].<ref>{{ Cite book| author = D.R. Kuhn | title = Proceedings of the third ACM workshop on Role-based access control | chapter = Role based access control on MLS systems without kernel changes | year = 1998 | pages=25–32 | url = http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/kuhn-98.pdf | doi = 10.1145/286884.286890 | citeseerx = 10.1.1.55.4755 | isbn = 978-1-58113-113-0 | s2cid = 1711956 }}</ref>

Prior to the development of RBAC, the Bell-LaPadula (BLP) 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.<ref>{{cite web|url=http://csrc.nist.gov/rbac/rbac-faq.html|title=Role Based Access Control – FAQs|publisher=Computer Security Research Center|date=2016-11-21|website=csrc.nist.gov|access-date=15 August 2018}}</ref><ref>{{cite journal|url=http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf|title=Role-Based Access Controls|pages=554–563|first1=David|last1=Ferraiolo|first2=Richard|last2=Kuhn|date=1992-10-13|website=csrc.nist.gov|access-date=15 August 2018}}</ref> Unlike [[Context-based access control|context-based access control]] (CBAC), RBAC does not look at the message context (such as a connection's source). RBAC has also been criticized for leading to role explosion,<ref>{{ cite journal|author1=A. A. Elliott |author2=G. S. Knight |name-list-style=amp | title = Role Explosion: Acknowledging the Problem | journal=Proceedings of the 2010 International Conference on Software Engineering Research & Practice | year = 2010 | url = http://knight.segfaults.net/papers/20100502%20-%20Aaron%20Elliott%20-%20WOLRDCOMP%202010%20Paper.pdf }}</ref> 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 (ERBAC, although the same acronym is also used for modified RBAC systems,<ref>{{cite web|url=http://www.acronymfinder.com/Enterprise-Role_Based-Access-Control-(computing)-(ERBAC).html|title=ERBAC – Enterprise Role-Based Access Control (computing) – AcronymFinder|website=www.acronymfinder.com|access-date=15 August 2018}}</ref> such as Extended Role-Based Access Control<ref>{{cite web|url=http://www.utdallas.edu/~ppd081000/04-07/2007/ERBAC-DWH.ppt|title=Dr. Bhavani Thuraisingham and Srinivasan Iyer (PPT)|access-date=15 August 2018}}</ref>) system is able to secure instances of data by considering their association to the executing subject.<ref>{{cite web|url=http://www.tynamo.org/tapestry-security-jpa+guide/|title=tapestry-security-jpa|first=Kalle|last=Korhonen|website=www.tynamo.org|access-date=15 August 2018}}</ref>

=== Comparing to ACL ===
Access control lists (ACLs) are used in traditional discretionary access-control (DAC) systems to affect low-level data-objects. RBAC differs from ACL in assigning permissions to operations which change the direct-relations between several entities (see: ''ACLg'' below). For example, an ACL could be used for granting or denying write access to a particular system file, but it wouldn't 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. A Role is thus a sequence of operations within a larger activity. RBAC has been shown to be particularly well suited to separation of duties (SoD) 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.<ref>{{ Cite book| author = D.R. Kuhn | title = Proceedings of the second ACM workshop on Role-based access control - RBAC '97 | chapter = Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems | year = 1997 | pages=23–30 | doi = 10.1145/266741.266749 | isbn = 0897919858 | s2cid = 482687 | url = http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/kuhn-97.pdf }}</ref><ref>{{ Cite book | year = 2004 | pages=42–51 | format = PDF | url = http://portal.acm.org/citation.cfm?id=1030091 | doi = 10.1145/1030083.1030091 | citeseerx = 10.1.1.159.2556 | isbn = 978-1581139617 | s2cid = 798546 | chapter=On mutually-exclusive roles and separation of duty | title=Proceedings of the 11th ACM conference on Computer and communications security | last1=Li | first1=Ninghui | last2=Bizri | first2=Ziad | last3=Tripunitara | first3=Mahesh V. }}</ref>

Then again, a "minimal RBAC Model", ''RBACm'', can be compared with an ACL mechanism, ''ACLg'', where only groups are permitted as entries in the ACL. Barkley (1997)<ref>J. Barkley (1997) "[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.107.6366 Comparing simple role based access control models and access control lists]", In "Proceedings of the second ACM workshop on Role-based access control", pages 127-132.</ref> showed that ''RBACm'' and ''ACLg'' are equivalent.

In modern [[SQL]] implementations, like [http://book.cakephp.org/2.0/en/core-libraries/components/access-control-lists.html ACL of the] [[Software:CakePHP|CakePHP]] framework, ACLs also manage groups and inheritance in a hierarchy of groups. Under this aspect, specific "modern ACL" implementations can be compared with specific "modern RBAC" implementations, better than "old (file system) implementations".

For data interchange, and for "high level comparisons", ACL data can be translated to [[XACML]].

=== Attribute-based access control ===
Attribute-based access control or [[Attribute-based access control|ABAC]] is a model which evolves from RBAC to consider additional attributes in addition to roles and groups. In ABAC, it is possible to use attributes of:
* the user e.g. citizenship, clearance,
* the resource e.g. classification, department, owner,
* the action, and
* the context e.g. time, location, IP.

ABAC is policy-based in the sense that it uses policies rather than static permissions to define what is allowed or what is not allowed.

=== Relationship-based access control ===

Relationship-based access control or [[Relationship-based access control|ReBAC]] is a model which evolves from RBAC. In ReBAC, a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources. 

The advantage of this model is that allows for fine-grained permissions; for example, in a social network where users can share posts with other specific users. <ref>{{Cite journal |last=Gates |first=Carrie |date=2007 |title=Access control requirements for web 2.0 security and privacy |url=https://www.researchgate.net/publication/240787391 |journal=IEEE Web |volume=2 |pages=12–15}}</ref>

== Use and availability ==
The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice. 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.<ref name="autogenerated2002">{{ cite book |author1=A.C. O'Connor |author2=R.J. Loomis |name-list-style=amp | title = Economic Analysis of Role-Based Access Control |pages=145 |date=March 2002 | publisher = Research Triangle Institute | url = http://csrc.nist.gov/groups/SNS/rbac/documents/20101219_RBAC2_Final_Report.pdf }}</ref>

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.<ref>{{cite web|url=http://www.idsynch.com/docs/beyond-roles.html|title=Beyond Roles: A Practical Approach to Enterprise IAM|first=Hitachi ID|last=Systems|website=www.idsynch.com|access-date=15 August 2018}}</ref> Newer systems extend the older [[NIST RBAC model]]<ref>{{ Cite book| author = Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. |title=Proceedings of the fifth ACM workshop on Role-based access control |chapter=The NIST model for role-based access control |date=July 2000 | pages=47–63 | doi = 10.1145/344287.344301 |isbn=158113259X | s2cid = 14539795 | chapter-url = http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf }}</ref> 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.<ref>{{ cite journal | author = Ferraiolo, D.F., Kuhn, D.R., and Sandhu, R. | title = RBAC Standard Rationale: comments on a Critique of the ANSI Standard on Role-Based Access Control | journal = IEEE Security & Privacy | volume = 5 | issue = 6 | date = Nov–Dec 2007 | pages = 51–53 | url = http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-sandhu-07.pdf | doi = 10.1109/MSP.2007.173 | s2cid = 28140142 | url-status = dead | archive-url = https://web.archive.org/web/20080917093137/http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-sandhu-07.pdf | archive-date = 2008-09-17 }}</ref>

== Potential Vulnerabilities ==
Role based access control interference is a relatively new issue in security applications, where multiple user accounts with dynamic access levels may lead to encryption key instability, allowing an outside user to exploit the weakness for unauthorized access. Key sharing applications within dynamic virtualized environments have shown some success in addressing this problem.<ref>{{cite journal |last1=Marikkannu |first1=P |title=Fault-tolerant adaptive mobile agent system using dynamic role based access control |journal=International Journal of Computer Applications |date=2011 |volume=20 |issue=2|pages=1–6 |doi=10.5120/2409-3208 |bibcode=2011IJCA...20b...1M |doi-access=free }}</ref>


== See also ==
{{columns-list|colwidth=30em|
* [[Access control list]]
* [[Attribute-based access control]] (ABAC)
* [[Relationship-based access control]] (ReBAC)
* [[Organisation-based access control]] (OrBAC)
* [[RSBAC]]
* [[Capability-based security]]
* [[Location-based authentication]]
* [[Risk-based authentication]]
* [[Software:AGDLP|AGDLP]] (Microsoft's recommendations for implementing RBAC)
* [[Identity driven networking]] (IDN)
* [[Software:PERMIS|PERMIS]]
* Classified information
* [[Software:Apache Fortress|Apache Fortress]]
}}

== References ==
{{Reflist}}

== Further reading ==
* {{cite book|author1=David F. Ferraiolo|author2=D. Richard Kuhn|author3=Ramaswamy Chandramouli|title=Role-based Access Control|edition=2nd|year=2007|publisher=Artech House|isbn=978-1-59693-113-8}}

== External links ==
* [http://csrc.nist.gov/rbac/rbac-faq.html FAQ on RBAC models and standards]
* [http://csrc.nist.gov/rbac/ Role Based Access Controls at NIST]
* [http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf XACML core and hierarchical role based access control profile]
* [http://www.ics.utsa.edu/ Institute for Cyber Security at the University of Texas San Antonio]
* [https://web.archive.org/web/20110724171153/http://www.servercare.nl/Lists/Posts/Post.aspx?ID=92 Practical experiences in implementing RBAC]

[[Category:Computer security models]]

{{Sourceattribution|Role-based access control}}