System Design Cases
Authorization Models
Authorization Models concept page covering ACL, RBAC, ABAC, ReBAC (Google Zanzibar), Policy-as-Code (OPA Rego, Cedar), tenancy isolation, Postgres RLS, with tool comparison (SpiceDB, Permify, OpenFGA, Cerbos, Oso, Casbin). Includes 5 scenarios: RBAC role check, ABAC context-aware policy with time/location/MFA, ReBAC graph traversal Google Drive style, Postgres RLS tenant isolation, and tools comparison decision tree. Two ADRs on RBAC vs ABAC vs ReBAC choice and app-authz vs RLS defense in depth.
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.
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.
abac-decision — ABAC decision
ABAC evaluates subject, object, operation, and environment attributes against policy; stale or untrusted attributes cannot silently authorize.
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.
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.
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.
policy-outage — Policy outage fails closed
If a required decision cannot be obtained, the enforcement point does not turn infrastructure failure into privilege escalation.
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.
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.