RBAC is a Access Control Models where the central notion is that Permissions are associated with Roles, and users are assigned to appropriate Roles.

The abstraction of removing Permissions from the user greatly simplifies management of permissions.

Roles are created for the various job functions in an organization and users are assigned roles based on their responsibilities and qualifications. Users can be easily be assigned from one role to another. Roles can be granted new permissions as new Protected Resource are incorporated, and permissions can be revoked from roles as needed.


The silly discussion of RBAC vs ABAC.

More Details on RBAC #

"One of the most challenging problems in managing large networks is the complexity of security administration. Role Based Access Control (also called role based security), as formalized in 1992 by David Ferraiolo and Rick Kuhn, has become the predominant model for advanced access control because it reduces the complexity and cost of security administration in large networked applications. Most information technology vendors have incorporated RBAC into their product line, and the technology is finding applications in areas ranging from health care to defense, in addition to the mainstream commerce systems for which it was designed."[1]

It should be noted, that although NIST has done a lot of work on RBAC, the NIST RBAC standard does not work well for all implementations.

Role Based Access Control certainly should be part of your Strategic Directions, but usually, a tactical solution is what is required in the near term.

When discussing 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 Protected 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: ≥

Some items to keep in mind:

  • 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.

Component Summary.#

  • Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a Role-Based Access Control system. This includes user-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately.
  • RBAC Hierarchical adds relations for supporting role hierarchies. Hierarchical RBAC goes beyond simple user and permission role assignment by introducing the concept of a role’s set of authorized users and authorized permissions.
  • RBAC constraints defines constraints upon the various ....
  • Static Separation of Duty Relations adds relations among roles with respect to user assignments. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, the SSD relations model component defines relations in both the presence and absence of role hierarchies.
  • Dynamic Separation of Duty Relations, defines relations with respect to roles activated as part of a user’s session.

There are Others #

There are other Access Control Models that maybe of interest.

Defining Roles#

There is a lot of discussion on Role Based Access Controls as to what it is and how to Defining Roles. Most of the discussion appears by vendors, either suppliers of IdM Products or supplies of IdM services. These discussions although maybe well intended, are attempts to make IdM sexy and exciting.

RBAC How are roles different from groups?#

RBAC How are roles different from groups?

More Information#

There might be more information for this subject on one of the following:
[#1] - http://csrc.nist.gov/rbac/