Role-based access control (RBAC)

RBAC was formalised in a 1992 paper by David Ferraiolo and Richard Kuhn of NIST and extended by Sandhu and colleagues in the RBAC96 family of models. NIST's unified model was adopted as ANSI INCITS 359-2004 in February 2004.The standard defines four components. Core RBAC consists of the sets USERS, ROLES, operations (OPS) and objects (OBS), permissions as operation-object pairs, a user-assignment relation UA between users and roles, a permission-assignment relation PA between permissions and roles, and sessions in which a user activates a subset of assigned roles. Hierarchical RBAC adds inheritance, where a senior role acquires the permissions of junior roles, in general or limited (tree-shaped) forms. Static separation of duty constrains assignment, so that no user may hold both "create supplier" and "approve payment", while dynamic separation of duty constrains which roles may be active together in one session.

Implementations vary in how faithfully they follow the model. Active Directory security groups are commonly used as roles, although strictly a group is a collection of users and a role a collection of permissions; the AGDLP pattern (accounts into global groups, global groups into domain-local groups, permissions on domain-local groups) approximates that split. Kubernetes RBAC binds Roles or ClusterRoles to subjects through RoleBindings or ClusterRoleBindings; rules are purely additive with no deny, and the escalate and bind verbs, or any binding to cluster-admin, are effectively privilege grants to watch. Azure RBAC combines role definitions with assignments at management-group, subscription, resource-group or resource scope and inherits downward. Databases, ERP systems such as SAP and SaaS applications all have their own role layers.

The recurring failure is role explosion: when context such as department, site, project and data sensitivity is encoded in role names, the number of roles approaches the number of users and the model loses its point. Role engineering tries to prevent that, top-down from job functions or bottom-up through role mining on existing entitlements. RBAC also cannot natively express rules like "only your own patients" or "only during a shift"; those need attributes or relationships, which is why ABAC (NIST SP 800-162) and ReBAC are often layered on top, with the role treated as one attribute among several.

Operationally, RBAC makes access reviews tractable: auditors certify each role's permission set once and then review who holds which roles, and separation-of-duty rules detect toxic combinations. It supports least privilege only if roles are kept narrow and personal exceptions are resisted; a few broad "power user" roles quietly undo the benefit.