RBAC, or role-based access control, is an authorization model in which permissions are assigned to roles and users receive permissions only by being assigned to those roles. A role represents a job function, such as accountant, support agent or database administrator, and bundles exactly the operations that function needs.
In identity & access management, RBAC is the most widely deployed model for enterprise authorization. It is formalized in the NIST RBAC model, standardized as ANSI INCITS 359, and implemented in operating systems, databases, cloud platforms, Kubernetes and business applications. Its central promise is that access can be managed by changing a person’s roles rather than editing hundreds of individual permissions.
How RBAC structures authorization
RBAC separates authorization into three sets and two relations. Users are assigned to roles, roles are assigned permissions, and a permission is an approved operation on an object, such as read on a customer record or delete on a storage bucket. When a user acts, the system checks whether any active role of that user holds the required permission.
Authentication establishes who the user is; RBAC then decides what that identity may do. In federated setups, an identity provider often transmits group or role claims through SAML assertions or OpenID Connect tokens, and the application maps them to its internal roles.
The main building blocks are listed below.
| Element | Definition | Example |
|---|---|---|
| User | A person or service identity | j.novak, billing-service |
| Role | Named job function | Invoice approver |
| Permission | Operation on a protected object | Approve invoice |
| User assignment | Link between users and roles | j.novak is an invoice approver |
| Permission assignment | Link between roles and permissions | Invoice approver may approve invoice |
| Session | Set of roles a user activates | Approver role active during a login |
Levels of the NIST RBAC model
The NIST model defines RBAC in cumulative levels, so a product can claim support for a specific level. The distinction matters when comparing tools, because many systems implement only flat roles without constraints.
| Level | Adds | Practical meaning |
|---|---|---|
| Core RBAC | Users, roles, permissions, sessions | Basic role assignment |
| Hierarchical RBAC | Role inheritance | Senior roles include junior permissions |
| Static separation of duty | Conflicting roles cannot be assigned together | No one is both requester and approver |
| Dynamic separation of duty | Conflicting roles cannot be active together | User holds both, uses one per session |
Separation of duty is one of the strongest reasons auditors favor RBAC. Financial controls frequently require that the person who creates a payment cannot also approve it, and RBAC constraints express that rule once, centrally, instead of relying on manual reviews.
RBAC compared with other access control models
RBAC sits between simple per-user permissions and fully dynamic policies. Its strength is predictability and auditability; its weakness is limited expressiveness when decisions depend on context such as time, location or data attributes.
| Model | Decision based on | Strength | Weakness |
|---|---|---|---|
| ACL or DAC | Per-object lists set by owners | Simple, flexible | Hard to audit at scale |
| RBAC | Roles of the user | Clear, auditable, easy reviews | Role explosion with fine rules |
| ABAC | Attributes of user, resource, context | Very expressive | Complex policies, harder audits |
| ReBAC | Relationships between entities | Natural for sharing and hierarchies | Requires a relationship graph |
| MAC | System-enforced labels | Strong confidentiality | Rigid, specialized use |
Many real systems are hybrids. Cloud platforms combine roles with conditions on attributes, and applications often use RBAC for coarse feature access while checking ownership or tenancy on each record. OAuth scopes are related but different: a scope limits what a client application may do on a user’s behalf, while a role describes what the user is allowed to do in the first place.
Designing roles in practice
Good role design starts from job functions and tasks, not from existing permissions. Organizations either define roles top-down from process models or use role mining, which analyzes current permission assignments to find common clusters, and then review the proposals with business owners.
| Decision | Recommended approach | Reason |
|---|---|---|
| Role granularity | Few broad roles plus small add-on roles | Avoids role explosion |
| Naming | Business-readable names with scope | Reviewers understand what they approve |
| Privileged access | Separate admin roles, time-limited activation | Limits standing privilege |
| Service identities | Dedicated roles per workload | Least privilege for automation |
| Ownership | Each role has an accountable owner | Someone approves changes and reviews |
In Kubernetes, for example, a Role or ClusterRole lists allowed verbs on resources, and a RoleBinding attaches it to users, groups or service accounts within a namespace. The same pattern of defining roles once and binding them many times appears in most cloud identity systems.
Mature programs also add just-in-time elevation for sensitive roles: an administrator requests the role for a defined period, often one to eight hours, with approval and logging, and loses it automatically afterward. Combined with group-based assignment from an identity provider, this keeps standing privileges small while preserving the simple mental model that makes RBAC attractive.
Common RBAC pitfalls
Most RBAC failures are governance failures rather than technical ones. Roles accumulate permissions over time, users keep old roles when they change jobs, and nobody can explain why a role grants a particular right. Without clear ownership and regular recertification, a carefully designed role model degrades within a few years.
- Role explosion: creating a new role for every exception produces thousands of roles that no one can review.
- Privilege creep: movers keep previous roles; joiner, mover and leaver processes must remove them.
- Overbroad wildcard roles such as admin on everything defeat least privilege.
- No periodic access reviews: regulations and frameworks such as SOX and ISO 27001 expect recertification.
- Client-side checks only: hiding buttons is not authorization; every check must happen on the server.
A non-technical view
RBAC works like the badges in a hospital. A nurse badge opens the wards, a pharmacist badge opens the medicine room, and a cleaner badge opens storage. Access depends on the job, not on the person.
When someone changes jobs, the hospital simply swaps the badge. Nobody has to reprogram every door. That makes access easier to manage and easier to check.
A concrete example
A mid-sized insurance company replaces individually granted permissions in its claims system with RBAC. Analysts define 12 business roles, including claims handler, senior adjuster and payment approver, plus a few add-on roles for special regions. A separation-of-duty rule prevents anyone from holding both claims handler and payment approver at the same time.
Roles are assigned automatically from the HR system when people join or move departments. The first quarterly access review now takes two days instead of three weeks, and auditors find that 47 former employees and movers lost stale access that the old model had never removed.