Role-Based Access Control |
In computer systems security Role-Based Access Control is an approach to restricting system access to authorized users. It is a newer and alternative approach to discretionary access control and mandatory access control.
Within an organization, roles are created for various job functions. The permission 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.
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 (ACL s) 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:
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles. 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:
The notation: x > y means that x inherits the permissions of y.
A user 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, Oracle database, SAP R/3 and many others effectively implement some form of RBAC.
Use of RBAC to manage user entitlements across multiple applications, however, is much more controversial. This is because users are often unique, and so the task of defining sufficient roles and assigning adequate role memberships in an organization with a heterogeneous IT infrastructure, in order to capture user privilege requirements, as those requirements span dozens or hundreds of systems and applications, becomes extemely complex. This problem, and alternate strategies, are discussed in a white paper: [http://www.idsynch.com/docs/beyond-roles.html Beyond Roles: A Practical Approach to Enterprise User Provisioning].
=See also=
=External links=
*[http://csrc.nist.gov/rbac/ Role Based Access Controls at NIST] - huge US government website with lots of information on the theory and implementation of RBAC *[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] - OASIS (organization) XACML standard. (PDF file) *[http://www.xml-dev.com/blog/action=viewtopic&id=143 RBAC for WebApps using LDAP] RBAC for WebApps using LDAP|
|