World Library  
Flag as Inappropriate
Email this Article

Role-based access control

Article Id: WHEBN0000066181
Reproduction Date:

Title: Role-based access control  
Author: World Heritage Encyclopedia
Language: English
Subject: Access control list, Comparison of web application frameworks, Security-Enhanced Linux, Role hierarchy, Organisation-based access control
Collection: Access Control, Computer Security Models
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Role-based access control

In computer systems security, role-based access control (RBAC)[1][2] is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees,[3] and can implement mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

Contents

  • Design 1
    • Standardized levels 1.1
  • Relation to other models 2
  • Use and availability 3
  • Comparing with ACL 4
  • RBAC and employees' responsibilities alignment 5
  • See also 6
  • References 7
  • Further reading 8
  • External links 9

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 (or other system users) 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 (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:

  1. Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
  2. 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.
  3. 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 (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 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:

  • PA \subseteq P \times R and is a many to many permission to role assignment relation.
  • SA \subseteq S \times R and is a many to many subject to role assignment relation.
  • RH \subseteq R \times R
A subject may have multiple simultaneous sessions with different permissions.
RBAC

Standardized levels

The NIST/ANSI/INCITS RBAC standard (2004) recognizes three levels of RBAC:[4]

  1. core RBAC
  2. hierarchical RBAC, which adds support for inheritance between roles
  3. 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[5] or MAC.[6] DAC with groups (e.g., as implemented in POSIX file systems) can emulate RBAC.[7] MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set.[8]

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.[9][10] Unlike 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,[11] 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,[12] such as Extended Role-Based Access Control[13]) system is able to secure instances of data by considering their association to the executing subject.[14]

RBAC differs from 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.[15][16]

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. Applications including WorldHeritage, Microsoft Lync, Microsoft Active Directory, Microsoft SQL Server and operating systems implementing SELinux (Linux, Solaris and some other Unix-like operating systems), grsecurity (Linux), TrustedBSD (FreeBSD), 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.[3]

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.[17] Newer systems extend the older NIST RBAC model[18] 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.[19]

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 (1997)[20] 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 (file system) implementations".

RBAC and employees' responsibilities alignment

In Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture[21] 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.[22]

See also

References

  1. ^ Ferraiolo, D.F. and Kuhn, D.R. (October 1992). "15th National Computer Security Conference" (PDF). pp. 554–563. 
  2. ^ Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). "Role-Based Access Control Models" (PDF). IEEE Computer (IEEE Press) 29 (2): 38–47.  
  3. ^ a b A.C. O'Connor and R.J. Loomis (December 2010). Economic Analysis of Role-Based Access Control (PDF). Research Triangle Institute. 
  4. ^ Alberto Belussi; Barbara Catania; Eliseo Clementini; Elena Ferrari (2007). Spatial Data on the Web: Modeling and Management. Springer. p. 194.  
  5. ^ Ravi Sandhu, Qamar Munawer (October 1998). "3rd ACM Workshop on Role-Based Access Control". pp. 47–54. 
  6. ^ Sylvia Osborn, Ravi Sandhu, and Qamar Munawer (2000). "ACM Transactions on Information and System Security (TISSEC)". pp. 85–106. 
  7. ^ Brucker, Achim D.; Wolff, Burkhart (2005). "A Verification Approach for Applied System Security". International Journal on Software Tools for Technology (STTT).  
  8. ^ D.R. Kuhn (1998). "Third ACM Workshop on Role Based Access Control" (PDF). pp. 25–32. 
  9. ^ National Institute of Standards and Technology FAQ on RBAC models and standards
  10. ^ David Ferraiolo and Richard Kuhn
  11. ^ A. A. Elliott and G. S. Knight (2010). "Proceedings of the 2010 International Conference on Software Engineering Research & Practice" (PDF). 
  12. ^ [1]
  13. ^ Dr. Bhavani Thuraisingham and Srinivasan Iyer (PPT)
  14. ^ Kalle Korhonen: tapestry-security-jpa, a JPA/Tapestry 5 specific implementation of the ERBAC concept
  15. ^ D.R. Kuhn (1997). "2nd ACM Workshop Role-Based Access Control" (PDF). pp. 23–30. 
  16. ^ Ninghui Li, Ziad Bizri, and Mahesh V. Tripunitara . Tripunitara (2004). "11th ACM conference on Computer and Communications Security" (PDF). pp. 42–51. 
  17. ^ Beyond Roles: A Practical Approach to Enterprise User Provisioning
  18. ^ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "5th ACM Workshop Role-Based Access Control" (PDF). pp. 47–63. 
  19. ^ Ferraiolo, D.F., Kuhn, D.R., and Sandhu, R. (Nov–Dec 2007). "RBAC Standard Rationale: comments on a Critique of the ANSI Standard on Role-Based Access Control" (PDF). IEEE Security & Privacy (IEEE Press) 5 (6): 51–53.  
  20. ^ J. Barkley (1997) " 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.
  21. ^ Feltus C. (2014). "Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture" (PDF). 
  22. ^ Feltus, c., Petit, M., Sloman, M. (2010). "Enhancement of Business IT Alignment by Including Responsibility Components in RBAC" (PDF). CEUR-WS 599. 

Further reading

  • David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Role-based Access Control (2nd ed.). Artech House.  

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
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.