A role hierarchy organizes authorization into layered responsibilities. A higher-level role inherits permissions from a lower-level role, so access can follow an organization’s structure without duplicating permissions. section 5.2
Within role-based access control (RBAC), permissions attach to roles, users receive roles, and the authorization decision resolves both directly assigned and inherited permissions. This separates identity from permission management and supports clearer audits. section 5.2 section 5.2.1
A hierarchy changes authorization evaluation in several ways:
- Identify the principal and retrieve assigned roles. section 5.2.1
- Resolve inherited roles and combine all relevant permissions before deciding. section 5.2.1
- Permit an action when any applicable role grants the requested permission; otherwise deny it. section 5.2.1
- Pair the hierarchy with separation-of-duty constraints when conflicting responsibilities must not belong to one person. section 5.2.1
Engineer and senior-engineer
Suppose the engineer role permits code-check-in approval, while senior-engineer permits production deployment and inherits engineer. Bob, assigned engineer, may approve code check-ins but cannot deploy. Alice, assigned senior-engineer, may do both because her role includes the inherited permission. section 5.2.1
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.
The diagram shows users assigned to roles such as engineer, senior-engineer, and support-lead, with inheritance layering access through organizational responsibility. section 5.2
Role hierarchies scale static authorization when responsibilities are stable and clearly bounded, but they do not express dynamic conditions such as time of day or device posture. section 5.2.1 section 5.4
