Role-Based Access Control (RBAC).

Role-Based Access Control assigns permissions to abstract roles (for example, "billing-admin" or "read-only auditor") and grants users access by adding them to those roles. This indirection simplifies administration, supports separation of duties, and makes audits straightforward because permissions are documented per role rather than per user. RBAC is the dominant model in enterprise IAM, cloud platforms (AWS IAM, Azure RBAC, Kubernetes RBAC), and ERP systems.

RBAC was formalised by David Ferraiolo and Rick Kuhn of NIST in their 1992 paper "Role-Based Access Controls," then unified with the Sandhu et al. framework and standardised as ANSI/INCITS 359-2004 (revised as INCITS 359-2012). The standard defines four cumulative components: core RBAC (users–roles–permissions), hierarchical RBAC (roles inherit from senior roles), and two forms of constrained RBAC — Static and Dynamic Separation of Duty (SSD/DSD) — that block toxic permission combinations such as one user both creating and approving a payment.

Its main weakness is role explosion: in large organisations, encoding every fine-grained business need as a distinct role produces thousands of near-duplicate roles that become unmanageable. This pushes teams toward hybrid ABAC/RBAC designs, where roles set a coarse baseline and attributes (department, time, resource tag) refine each decision — the pattern behind AWS IAM condition keys and Kubernetes' RBAC-plus-admission-webhook model.

flowchart LR
  U["User: Alice"] -->|assigned to| R1["Role: billing-admin"]
  U -->|assigned to| R2["Role: auditor"]
  R1 -->|inherits| R3["Role: billing-viewer"]
  R1 -->|grants| P1["Perm: create invoice"]
  R3 -->|grants| P2["Perm: read invoice"]
  R2 -->|grants| P3["Perm: export logs"]
  P1 --> RES[("Billing system")]
  P2 --> RES
  P3 --> RES
  SSD["SSD constraint:<br/>cannot hold approver + creator"] -. blocks .-> R1