Role-based access control

Last updated

In computer systems security, role-based access control (RBAC) [1] [2] or role-based security [3] is an approach to restricting system access to authorized users, and to implementing mandatory access control (MAC) or discretionary access control (DAC).

Contents

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. [4] 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:

  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:

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:

A subject may have multiple simultaneous sessions with/in different roles.

RBAC Role-based access control.jpg
RBAC

Standardized levels

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

  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 [6] or MAC. [7] DAC with groups (e.g., as implemented in POSIX file systems) can emulate RBAC. [8] MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set. [9]

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

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. [16] [17]

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) [18] showed that RBACm and ACLg are equivalent.

In modern SQL implementations, like ACL of the 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 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:

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 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. [19]

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. [20]

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. [21] Newer systems extend the older NIST RBAC model [22] 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. [23]

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. [24]


See also

Related Research Articles

<span class="mw-page-title-main">Access control</span> Selective restriction of access to a place or other resource, allowing only authorized users

In physical security and information security, access control (AC) is the selective restriction of access to a place or other resource, while access management describes the process. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called authorization.

In computer security, an access-control list (ACL) is a list of permissions associated with a system resource. An ACL specifies which users or system processes are granted access to resources, as well as what operations are allowed on given resources. Each entry in a typical ACL specifies a subject and an operation. For instance,

Rule-set-based access control (RSBAC) is an open source access control framework for current Linux kernels, which has been in stable production use since January 2000.

In computer security, mandatory access control (MAC) refers to a type of access control by which a secured environment constrains the ability of a subject or initiator to access or modify on an object or target. In the case of operating systems, the subject is a process or thread, while objects are files, directories, TCP/UDP ports, shared memory segments, or IO devices. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, the operating system kernel examines these security attributes, examines the authorization rules in place, and decides whether to grant access. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

In computer security, discretionary access control (DAC) is a type of access control defined by the Trusted Computer System Evaluation Criteria (TCSEC) as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission on to any other subject.

Identity management (IdM), also known as identity and access management, is a framework of policies and technologies to ensure that the right users have the appropriate access to technology resources. IdM systems fall under the overarching umbrellas of IT security and data management. Identity and access management systems not only identify, authenticate, and control access for individuals who will be utilizing IT resources but also the hardware and applications employees need to access.

A computer security model is a scheme for specifying and enforcing security policies. A security model may be founded upon a formal model of access rights, a model of computation, a model of distributed computing, or no particular theoretical grounding at all. A computer security model is implemented through a computer security policy.

The concept of type enforcement (TE), in the field of information technology, is an access control mechanism for regulating access in computer systems. Implementing TE gives priority to mandatory access control (MAC) over discretionary access control (DAC). Access clearance is first given to a subject accessing objects based on rules defined in an attached security context. A security context in a domain is defined by a domain security policy. In the Linux security module (LSM) in SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before multilevel security (MLS) or its replacement multi categories security (MCS). It is a complement of role-based access control (RBAC).

In computer security, lattice-based access control (LBAC) is a complex access control model based on the interaction between any combination of objects and subjects.

In computing, delegated administration or delegation of control describes the decentralization of role-based-access-control systems. Many enterprises use a centralized model of access control. For large organizations, this model scales poorly and IT teams become burdened with menial role-change requests. These requests — often used when hire, fire, and role-change events occur in an organization — can incur high latency times or suffer from weak security practices.

AGDLP briefly summarizes Microsoft's recommendations for implementing role-based access controls (RBAC) using nested groups in a native-mode Active Directory (AD) domain: User and computer accounts are members of global groups that represent business roles, which are members of domain local groups that describe resource permissions or user rights assignments. AGUDLP and AGLP summarize similar RBAC implementation schemes in Active Directory forests and in Windows NT domains, respectively.

<span class="mw-page-title-main">Organisation-based access control</span> Access control model in computer security

In computer security, organization-based access control (OrBAC) is an access control model first presented in 2003. The current approaches of the access control rest on the three entities to control the access the policy specifies that some subject has the permission to realize some action on some object.

PERMIS is a sophisticated policy-based authorization system that implements an enhanced version of the U.S. National Institute of Standards and Technology (NIST) standard Role-Based Access Control (RBAC) model. PERMIS supports the distributed assignment of both roles and attributes to users by multiple distributed attribute authorities, unlike the NIST model which assumes the centralised assignment of roles to users. PERMIS provides a cryptographically secure privilege management infrastructure (PMI) using public key encryption technologies and X.509 Attribute certificates to maintain users' attributes. PERMIS does not provide any authentication mechanism, but leaves it up to the application to determine what to use. PERMIS's strength comes from its ability to be integrated into virtually any application and any authentication scheme like Shibboleth (Internet2), Kerberos, username/passwords, Grid proxy certificates and Public Key Infrastructure (PKI).

Attribute-based access control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes.

The NIST RBAC model is a standardized definition of role-based access control. Although originally developed by the National Institute of Standards and Technology, the standard was adopted and is copyrighted and distributed as INCITS 359-2004 by the International Committee for Information Technology Standards (INCITS). The latest version is INCITS 359-2012. It is managed by INCITS committee CS1.

In role based access control, the role hierarchy defines an inheritance relationship among roles. For example, the role structure for a bank may treat all employees as members of the ‘employee’ role. Above this may be roles ‘department manager’, and ‘accountant’, which inherit all permissions of the ‘employee’ role, while above ‘department manager’ could be ‘savings manager’, ‘loan manager’.

Delegation is the process of a computer user handing over its authentication credentials to another user. In role-based access control models, delegation of authority involves delegating roles that a user can assume or the set of permissions that the user can acquire, to other users.

In computer security, general access control includes identification, authorization, authentication, access approval, and audit. A more narrow definition of access control would cover only access approval, whereby the system makes a decision to grant or reject an access request from an already authenticated subject, based on what the subject is authorized to access. Authentication and access control are often combined into a single operation, so that access is approved based on successful authentication, or based on an anonymous access token. Authentication methods and tokens include passwords, biometric scans, physical keys, electronic keys and devices, hidden paths, social barriers, and monitoring by humans and automated systems.

ERP Security is a wide range of measures aimed at protecting Enterprise resource planning (ERP) systems from illicit access ensuring accessibility and integrity of system data. ERP system is a computer software that serves to unify the information intended to manage the organization including Production, Supply Chain Management, Financial Management, Human Resource Management, Customer Relationship Management, Enterprise Performance Management.

In computer systems security, Relationship-based access control (ReBAC) defines an authorization paradigm where a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources.

References

  1. ↑ Ferraiolo, D.F. & Kuhn, D.R. (October 1992). "Role-Based Access Control" (PDF). 15th National Computer Security Conference: 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. 29 (2): 38–47. CiteSeerX   10.1.1.50.7649 . doi:10.1109/2.485845. S2CID   1958270.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  3. ↑ ABREU, VILMAR; Santin, Altair O.; VIEGAS, EDUARDO K.; STIHLER, MAICON (2017). "A multi-domain role activation model". 2017 IEEE International Conference on Communications (ICC) (PDF). IEEE Press. pp. 1–6. doi:10.1109/ICC.2017.7997247. ISBN   978-1-4673-8999-0. S2CID   6185138.
  4. ↑ Gilbert MD, Lynch N, Ferraiolo FD (1995). "An examination of federal and commercial access control policy needs". National Computer Security Conference, 1993 (16th) Proceedings: Information Systems Security: User Choices. DIANE Publishing. p. 107. ISBN   9780788119248.
  5. ↑ Alberto Belussi; Barbara Catania; Eliseo Clementini; Elena Ferrari (2007). Spatial Data on the Web: Modeling and Management. Springer. p. 194. ISBN   978-3-540-69878-4.
  6. ↑ Ravi Sandhu; Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control: 47–54.
  7. ↑ Sylvia Osborn; Ravi Sandhu & Qamar Munawer (2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security: 85–106.
  8. ↑ Brucker, Achim D.; Wolff, Burkhart (2005). "A Verification Approach for Applied System Security". International Journal on Software Tools for Technology Transfer. 7 (3): 233–247. doi:10.1007/s10009-004-0176-3. hdl: 20.500.11850/52625 . S2CID   6427232.
  9. ↑ D.R. Kuhn (1998). "Role based access control on MLS systems without kernel changes". Proceedings of the third ACM workshop on Role-based access control (PDF). pp. 25–32. CiteSeerX   10.1.1.55.4755 . doi:10.1145/286884.286890. ISBN   978-1-58113-113-0. S2CID   1711956.
  10. ↑ "Role Based Access Control – FAQs". csrc.nist.gov. Computer Security Research Center. 2016-11-21. Retrieved 15 August 2018.
  11. ↑ Ferraiolo, David; Kuhn, Richard (1992-10-13). "Role-Based Access Controls" (PDF). csrc.nist.gov: 554–563. Retrieved 15 August 2018.
  12. ↑ A. A. Elliott & G. S. Knight (2010). "Role Explosion: Acknowledging the Problem" (PDF). Proceedings of the 2010 International Conference on Software Engineering Research & Practice.
  13. ↑ "ERBAC – Enterprise Role-Based Access Control (computing) – AcronymFinder". www.acronymfinder.com. Retrieved 15 August 2018.
  14. ↑ "Dr. Bhavani Thuraisingham and Srinivasan Iyer (PPT)" . Retrieved 15 August 2018.
  15. ↑ Korhonen, Kalle. "tapestry-security-jpa". www.tynamo.org. Retrieved 15 August 2018.
  16. ↑ D.R. Kuhn (1997). "Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems". Proceedings of the second ACM workshop on Role-based access control - RBAC '97 (PDF). pp. 23–30. doi:10.1145/266741.266749. ISBN   0897919858. S2CID   482687.
  17. ↑ Li, Ninghui; Bizri, Ziad; Tripunitara, Mahesh V. (2004). "On mutually-exclusive roles and separation of duty". Proceedings of the 11th ACM conference on Computer and communications security (PDF). pp. 42–51. CiteSeerX   10.1.1.159.2556 . doi:10.1145/1030083.1030091. ISBN   978-1581139617. S2CID   798546.
  18. ↑ 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.
  19. ↑ Gates, Carrie (2007). "Access control requirements for web 2.0 security and privacy". IEEE Web. 2: 12–15.
  20. ↑ A.C. O'Connor & R.J. Loomis (March 2002). Economic Analysis of Role-Based Access Control (PDF). Research Triangle Institute. p. 145.
  21. ↑ Systems, Hitachi ID. "Beyond Roles: A Practical Approach to Enterprise IAM". www.idsynch.com. Retrieved 15 August 2018.
  22. ↑ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST model for role-based access control" (PDF). Proceedings of the fifth ACM workshop on Role-based access control. pp. 47–63. doi:10.1145/344287.344301. ISBN   158113259X. S2CID   14539795.{{cite book}}: CS1 maint: multiple names: authors list (link)
  23. ↑ 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. 5 (6): 51–53. doi:10.1109/MSP.2007.173. S2CID   28140142. Archived from the original (PDF) on 2008-09-17.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  24. ↑ Marikkannu, P (2011). "Fault-tolerant adaptive mobile agent system using dynamic role based access control". International Journal of Computer Applications. 20 (2): 1–6. Bibcode:2011IJCA...20b...1M. doi: 10.5120/2409-3208 .

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.