Authorization models: RBAC, ABAC, ReBAC, and decision consistency

Authorization evaluates whether an authenticated subject may perform an action on a resource under current policy. RBAC, ABAC, and relationship-based rules are different policy inputs, not substitutes for request-time enforcement.

Security invariants

• AUTHZ-C1: Authorization evaluates subject, object, operation, and policy context after authentication; identity alone is not permission.
• AUTHZ-C2: RBAC assigns permissions through roles and supports role activation, hierarchy, and separation-of-duty constraints.
• AUTHZ-C3: ABAC evaluates subject, object, requested operation, and optionally environment attributes against policy.
• AUTHZ-C4: Relationship-based authorization can derive access through stored relations and must define consistency when ACLs change.
• AUTHZ-C5: Every request and object is authorized in tenant scope, with default deny and no client-supplied role or object trust.
• AUTHZ-C6: Decision caching and check-then-use flows require bounded freshness and binding to the exact resource operation.

Trust-boundary map

Component	Responsibility
subject	Authenticated Subject
policy-enforcement	Policy Enforcement Point
policy-decision	Policy Decision Point
role-store	Roles and Permissions
attribute-store	Subject, Object, and Environment Attributes
relationship-store	Relationship Tuples
resource	Protected Resource
audit-log	Decision Audit Log
policy-admin	Policy Administration
attacker	Cross-Tenant Caller

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

deny-by-default — Deny by default at the enforcement point

A missing rule, unknown attribute, or evaluation error is not an allow; every protected operation reaches a complete policy check.

▶Walkthrough: deny-by-default (not found)

rbac-decision — RBAC decision

Roles collect permissions and can simplify stable job-function policy, but tenant and resource context still belong in the enforcement decision.

▶Walkthrough: rbac-decision (not found)

abac-decision — ABAC decision

ABAC evaluates subject, object, operation, and environment attributes against policy; stale or untrusted attributes cannot silently authorize.

▶Walkthrough: abac-decision (not found)

rebac-decision — Relationship-based decision

A relationship graph answers questions such as viewer-of document through group membership while preserving tuple namespace and consistency requirements.

▶Walkthrough: rebac-decision (not found)

cross-tenant-denial — Tenant context is part of every decision

A valid user or role in one tenant does not authorize the same object identifier in another tenant.

▶Walkthrough: cross-tenant-denial (not found)

revocation-consistency — Revocation requires bounded decision staleness

Distributed authorization caches define freshness semantics so a revoked grant is not indefinitely accepted after the protected content changes.

▶Walkthrough: revocation-consistency (not found)

policy-outage — Policy outage fails closed

If a required decision cannot be obtained, the enforcement point does not turn infrastructure failure into privilege escalation.

▶Walkthrough: policy-outage (not found)

check-and-use — Bind authorization to the protected operation

A decision on one object version cannot be reused after an attacker swaps the target; enforcement loads or locks the authoritative resource identity.

▶Walkthrough: check-and-use (not found)

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

[CONCEPT]rbac-implementation-patterns [CONCEPT]authn-models [CONCEPT]api-security [CONCEPT]zero-trust

Authoritative sources

1. NIST SP 800-162: Guide to Attribute Based Access Control
2. NIST Role Based Access Control FAQ and standard summary
3. Google Research: Zanzibar, a Consistent Global Authorization System
4. OWASP Authorization Cheat Sheet