Within an organisation, roles are created for various job functions, and these roles are assigned permissions. Staff are made members of appropriate roles and thus acquire the permissions assigned to those roles.
This leads to greatly simplified administration of permissions. For example, a staff member can be immediately and simply assigned a new role when changing departments, rather than closing all existing access, and creating a new set of access controls. As the staff member's career progresses, then his or her roles are enhanced, and the associated permissions are automatically granted.
In an organisation, there will exist, an ever-evolving policy for access control. RBAC is policy neutral in itself and nicely facilitates the application of the organisation's policy.
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:
U = User = Person or automated agent of some kind.
R = Role = Job function / Title which defines an authority level.
P = Permissions = An approval of a mode of access to a resource.
S = Session = A mapping involving U,R and / P
UA = User Assignment.
PA = Permission Assignment
RH = Partially ordered role Hierarchy
RH can also be written: >
A user can have multiple roles.
A role can have multiple users.
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. For example the same person should not be allowed to both create a log-in account for someone, and also be allowed to authorise 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.
UA is a subset of or is equal to U x R and is a many to many user 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 user may have multiple simultaneous sessions with different permissions.
See also: