Role-based access control

From Wikipedia, the free encyclopedia

(Redirected from RBAC)
Jump to: navigation, search

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

RBAC is a policy neutral and flexible access control technology sufficiently powerful to simulate Discretionary Access Control (DAC) [3] and Mandatory Access Control (MAC). [4]

Prior to the development of RBAC, MAC and DAC were considered to be the only known models for access control: if a model was not MAC, it was considered to be a DAC model, and vice versa. Research in the late '90s demonstrated that RBAC falls in neither category.[citation needed]

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 (such as 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 login account for someone, and also be allowed to authorize the procedure.

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

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.

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 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 [5] to address the limitations of RBAC for enterprise-wide deployments. Several academic papers exist as well as at least one commercial system Beyond NIST.

  1. ^ Ferraiolo, D.F. and 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. IEEE Press. 
  3. ^ Ravi Sandhu, Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control: 47-54. 
  4. ^ Sylvia Osborn, Ravi Sandhu, and Qamar Munawer (2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security (TISSEC): 85-106. 
  5. ^ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control: 47-63. 


Advanced Search
Included Web Search Engines


Safe Search

close

Top Matching Results

Occasionally Search.com will highlight specialized results that are based on the context of your query. Examples of specialized results include specific links to news, images, or video.

Top Matching Results may highlight information from other Search.com pages, content from the CNET Network of sites, or third party content. The listings are based purely on relevance. Search.com does not receive payment for listings in this section but our partners that provide this data may get paid for listing these products.

Sponsored Links

This section contains paid listings which have been purchased by companies that want to have their sites appear for specific search terms and related content. These listings are administered, sorted and maintained by a third party and are not endorsed by Search.com.

Search Results

Search.com sends your search query to several search engines at one time and integrates the results into one list which has been sorted by relevance using Search.com's proprietary algorithm. You can customize the list of search engines included in your metasearch from the preferences.

The search engines that are used in your metasearch may allow companies to pay to have their Web sites included within the results. To view the Paid Inclusion policy for a specific search engine, please visit their Web site. Search.com does not accept payment or share revenue with any search engine partner for listings in this section.