| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
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:
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:
The notation: x > y means that x inherits the permissions of y.
A user may have multiple simultaneous sessions with different permissions.