An entitlement is the effective set of permissions a principal holds for a resource or action at a particular moment. It answers what someone can actually do, not merely which roles they have. section 4.3.2
Roles, attributes, and policies determine entitlements. Because conditions such as time, location, device trust, risk, or account status can change, an entitlement may be calculated during a request or precomputed for auditing and enforcement. section 4.3.2 section 12.3.1
Keep these distinctions clear:
- A permission is a specific right, such as editing an invoice, viewing a dashboard, or deleting a customer record. section 4.3.2
- A role bundles permissions and can provide inherited entitlements to anyone assigned that role. section 4.3.2
- An entitlement reflects the resulting access after current policies and conditions are applied; it is not automatically the union of assigned roles. section 4.3.2
A shift-sensitive entitlement
A call center agent with call_center_agent and senior_agent roles may normally read customer records, update ticket status, initiate refunds up to $500, and access call recordings. At 11 p.m., a policy removes the sensitive entitlements outside the assigned shift; at 9 a.m., they return without changing the roles. section 4.3.2
Figure 4.1 Relationships among key authorization terms. Principals, actions, and resources form the core of access decisions and are enriched with attributes, roles, and group memberships. All entities exist within namespaces and can be either principals or resources. The diagram also shows the legacy term subject as an older equivalent of principal and illustrates how actions operate on resources based on contextual and identity-based properties.
Use the relationship diagram to place entitlements among principals, actions, resources, roles, attributes, group memberships, and contextual access properties. section 4.3.2
