Role-based access control

The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments.

Although RBAC is different from MAC and DAC access control frameworks, it can enforce these policies without any complication.

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.

[8] MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set.

[10][11] Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection's source).

[15] Access control lists (ACLs) are used in traditional discretionary access-control (DAC) systems to affect low-level data-objects.

RBAC differs from ACL in assigning permissions to operations which change the direct-relations between several entities (see: ACLg below).

RBAC has been shown to be particularly well suited to separation of duties (SoD) requirements, which ensure that two or more people must be involved in authorizing critical operations.

[19] The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice.

Key sharing applications within dynamic virtualized environments have shown some success in addressing this problem.