A role is a named collection of permissions that represents a job function or access responsibility. Rather than grant permissions directly to each principal, an organization assigns permissions to roles and roles to people. This indirection makes access easier to explain: an engineer, support lead, or finance approver receives the capabilities associated with that responsibility. section 4.3.2 section 5.2
Roles address a central weakness of access control lists (ACLs): an ACL can show that someone may act on a resource but not the business reason for that access. RBAC (Role-Based Access Control) ties permissions to responsibilities, creating a shared vocabulary for access decisions, onboarding, job changes, and audits. It is most effective when responsibilities are stable and align clearly with organizational boundaries. section 5.1.5 section 5.2.3
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.
Role assignment sits between users and permissions. Hierarchies can layer responsibilities: a senior role may inherit permissions from a base role while adding its own. section 5.2
An RBAC decision typically follows this path:
- Identify the requesting principal and its assigned roles. section 5.2.1
- Retrieve permissions attached to those roles, including inherited permissions. section 5.2.1
- Allow the requested action only when an assigned role grants the needed permission; otherwise deny it. section 5.2.1
- Apply separation-of-duty constraints when conflicting responsibilities must not be held together, such as payment initiator and payment approver. section 5.2.1
Job change without ACL cleanup
A new support representative can receive access by being assigned the customer-support role. When the person moves into a different job, changing the role assignment changes access without locating every resource-level ACL. In the same model, senior-engineer can inherit engineer permissions while retaining additional deployment permissions. section 5.2 section 5.2.1
A role should bundle permissions at a level people can understand, but it should not erase important distinctions in the underlying policy. A UI may offer a collaborator role while policies separately control viewing, editing, and sharing. Keeping fine-grained actions behind a broad role avoids granting every capability merely because it is convenient to display one label. section 10.1.4
Roles are a poor substitute for runtime context. Encoding region, customer, temporary assignment, device, or time into role names can produce an unmanageable number of narrowly scoped roles. RBAC does not natively evaluate conditions such as time of day or device posture, so dynamic or highly individualized access needs require more expressive policy approaches alongside roles. section 5.2.3 section 5.2.4
Roles can also be scoped to a project or tenant rather than a permanent employee identity. A tenant may issue a credential naming a participant as project owner, contributor, reviewer, or finance approver; authorization then evaluates the tenant, project, and role claims. Credential expiration, revocation, and reassignment allow the role life cycle to remain with the tenant. section 16.8.4
