# Role-based access control

 related topics {system, computer, user} {law, state, case} {math, number, function} {service, military, aircraft} {company, market, business} {group, member, jewish} {theory, work, human} {food, make, wine} {black, white, people} {disease, patient, cell}

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 sometimes referred to as role-based security.

## Contents

### RBAC Model

Within an organization, roles are created for various job functions. The permissions to perform certain operations 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 appropriate roles to the user; 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 execute a transaction 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. Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can execute only transactions 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 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.

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$