Role-based access control (RBAC) is an authorization model that grants permissions to roles—named bundles reflecting job functions or responsibilities—and assigns principals to those roles. A support representative, engineer, or finance analyst receives access through the role rather than through separate per-resource entries. This indirection replaces scattered, undocumented checks with a shared structure for deciding who can do what and why. section 5.1.5 section 5.2
RBAC is most useful when responsibilities are stable and access aligns with organizational boundaries. Assigning a customer-support role can provision a new hire; changing or removing that role changes access without searching every access control list (ACL). Central role definitions also make permissions easier to review, communicate, and audit. section 5.2 section 5.2.4
Figure 5.2 Users are assigned to roles like engineer, senior-engineer, or support-lead, which define the permissions they receive. Some roles inherit from others, allowing access to be layered and managed through the organizational structure.
Follow the indirection: users receive permissions through assigned roles, while senior roles can inherit permissions from foundational roles. section 5.2
At request time, an RBAC decision typically follows these steps:
- Identify the requesting principal and retrieve that principal’s assigned roles. section 5.2.1
- Collect permissions attached to those roles, resolving any inherited roles. section 5.2.1
- Allow the requested action when a collected permission grants it; otherwise deny it. section 5.2.1
- Apply separation-of-duty constraints when conflicting roles must not be held together, such as payment initiator and payment approver. section 5.2.1
Layered engineering permissions
An engineer can approve a code check-in because the engineer role includes that permission. A senior engineer can also approve it through inheritance and can deploy to production through an additional direct permission. An engineer without that deployment permission is denied production deployment. The decision depends on role-derived permissions, not a direct user-to-resource mapping. section 5.2.1
RBAC can be implemented inside an application, API gateway, or middleware, or externalized through shared libraries, centralized services, and enterprise identity systems. In a reference architecture, the policy enforcement point (PEP) intercepts and enforces requests; the policy decision point (PDP) evaluates role permissions; the policy administration point (PAP) manages roles and assignments; and the policy information point (PIP) supplies role data. section 5.2.2
The model trades flexibility for clarity. It handles broad job responsibilities, onboarding, job changes, audits, and separation of duty well, but it does not natively express runtime conditions such as time of day, device posture, location, or network zone. It also becomes strained when access depends on ownership, sharing, a customer relationship, or highly individualized exceptions. section 5.2.3 section 5.2.5
A warning sign is role explosion: creating increasingly narrow roles to encode region, customer, temporary assignment, or workflow context. Such roles may initially satisfy exceptions but can make the role system harder to understand than the access problem. In these cases, RBAC can remain the foundation for broad responsibilities while attribute-based access control (ABAC), relationship-based access control (ReBAC), or policy-based access control (PBAC) handles contextual decisions. section 5.2.4 section 6.3.3
