Role-Based Access Control
From Wikipedia, the free encyclopedia
In computer systems security Role-Based Access Control (RBAC) is an approach to restricting system access to authorized users. It is a newer and alternative approach to Mandatory Access Control (MAC) and Discretionary Access Control (DAC).
RBAC also differs from the traditional MAC and DAC. Earlier MAC and DAC were the only two known models of access control. If a model is not MAC, it is assumed to be a DAC and vice-versa. But research in late 90s proved that RBAC neither falls in the category of MAC nor DAC.
Within an organization, roles are created for various job functions. The permissions to perform certain operations ('permissions') are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Unlike Context-Based Access Control (CBAC) RBAC does not look at the message context like where the connection was started from.
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 the appropriate roles to the user, which simplifies common operations such as adding a user, or changing a user's department.
RBAC differs from access control lists (ACLs) 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 say in what ways 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 fine grained and themselves have meaning within the application.
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 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.
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate segregation of duties. For example the same person should not be allowed to both create a log-in account for someone, and also be allowed to authorize the procedure.
Thus, using set theory notation:
- PA is a subset of or is equal to P x R and is a many to many permission to role assignment relation.
- SA is a subset of or is equal to S x R and is a many to many subject to role assignment relation.
- RH is a subset of or is equal to R x R
The notation: x ≥ y means that x inherits the permissions of y.
A subject may have multiple simultaneous sessions with different permissions.
The use of RBAC to manage user privileges within a single system or application is widely accepted as a best practice. Systems including Microsoft Active Directory, SELinux, FreeBSD, Solaris, Oracle DBMS, PostgreSQL 8.1, SAP R/3 and many others effectively implement some form of RBAC.
Use of RBAC to manage sufficient roles and assign adequate role memberships in an organization with a heterogeneous IT infrastructure and requirements that span dozens or hundreds of systems and applications, becomes extremely complex without hierarchal creation of roles and privilege assignments. Alternate strategies for large scale assignment of privileges to users are discussed in this white paper: Beyond Roles: A Practical Approach to Enterprise User Provisioning. Newer systems extend the older NIST model to address the limitations of RBAC for enterprise-wide deployments. Several academic papers exist as well as at least one commercial system Beyond NIST.
[edit] See also
- Lattice-Based Access Control (LBAC), equivalent to Mandatory Access Control (MAC).
- Security label
- Security classification
- Covert channel
- Chinese wall
- Authentication
- Blind credential
- Sudo (superuser do) Unix program
- Identity Driven Networking
- The Identity Dictionary
[edit] External links
- Enterprise-wide RBAC
- The Identity Laws
- Role Based Access Controls at NIST - huge US government website with lots of information on the theory and implementation of RBAC
- XACML core and hierarchical role based access control profile - OASIS XACML standard. (PDF file)
- RBAC for WebApps using LDAP RBAC for WebApps using LDAP
- System Administration Guide: Security Services - setting up roles, rights profiles, and privileges for the Solaris Operating System
- RBAC: An Alternative to the Superuser Model Role-Based Access Control (Overview) for Solaris Operating Environment
- SMARTROLES - A commercial system that overcomes limitations of the NIST model of RBAC
- Beyond Roles: A Practical Approach to Enterprise User Provisioning
- A "fine grained" PHP RBAC system
- ActiveRBAC is a Ruby on Rails RBAC library
- RBAC Case Studies