An access-control model should not be chosen by whichever acronym sounds more modern, but by how roles, resources, context, and relationships actually work in the product.
The chapter compares ACL, RBAC, ABAC, and ReBAC as different ways to make access decisions and shows how each approach changes policy expressiveness, explainability, operating cost, and long-term system growth.
For design reviews, it is strong material for discussing access policy as part of the domain model rather than as a technical add-on that can be swapped out later without consequences.
Practical value of this chapter
Design in practice
Choose the access model from the domain shape: roles, resources, request context, and relationships between objects.
Decision quality
Validate not only policy expressiveness, but also decision explainability, change cost, and resistance to permission drift.
Interview articulation
Explain the choice through the scenario: who performs the action, on which resource, in what context, and why this model fits.
Trade-off framing
Make the cost of ACL, RBAC, ABAC, and ReBAC explicit: simplicity, flexibility, check latency, auditability, and operational complexity.
Primary
Zanzibar: Google's Consistent, Global Authorization System
The canonical source about ReBAC on a global scale and the tuple relationship model.
Choosing an authorization model is not about “who logged in” but about how exactly the system answers an access request — and the cost of getting it wrong is either a needless denial to a legitimate user or a leak of someone else’s data. A single pure model is rare in production: teams combine RBAC as a base layer, ABAC for context and exceptions, ReBAC for the relationship graph, and ACL as a local mechanism at the object level.
Canonical model visualizer
The same request may read a local list, a role catalog, contextual attributes, or a relationship graph. Switch models to see where the access decision is made.
Access list next to the resource
ACL works when the decision can be made from a local record on the object: who may read, change, or administer the resource.
1. Who asks
Subject
A user, group, or service arrives with an action such as read or write.
2. What is protected
Resource
A document, file, storage object, or record carries its own access list.
3. Lookup
Access list
The system searches the resource-local permissions for the subject or group.
4. Output
Allow or deny
If no matching entry exists, the safer default is to deny the action.
Where it fits
- Rights are easy to explain for a single object.
- Works well in small isolated domains.
- Bulk access changes become expensive quickly.
How to read it
Read ACL as a local check beside the resource: simple and transparent, but not a replacement for global access policy.
Comparison of models
| Criterion | ACL | RBAC | ABAC | ReBAC |
|---|---|---|---|---|
| Policy unit | Entry next to the resource | Role | Rule | Graph relationship |
| Granularity | Very precise, but local | Medium | High | High within the graph |
| Access changes | Expensive at large scale | Cheap via role mapping | Through policies and attributes | Through new relation tuples |
| Explainability | High | High | Medium | Medium, requires an explain API |
| Platform complexity | Low | Low to medium | Medium to high | High |
| Typical scale | Local systems | Enterprise/B2B | Regulated domains | Collaboration at scale |
ABAC
NIST SP 800-162
Practical recommendations on the policy model and attributes for ABAC.
Limits of applicability
ACL
When suitable: Object stores, file systems, and small isolated domains where every resource has an explicit owner.
Where it hurts: Large multi-tenant systems, where one org change turns into editing thousands of entries and bulk access changes get too expensive.
Boundary: Keep it as a local model next to the resource — do not stretch it into one global access policy for the whole company.
RBAC
When suitable: Internal platforms, B2B SaaS, and mature organizational structures with clear job functions.
Where it hurts: The model is blind to context by geography, time, or risk, and per-object exceptions quickly breed one-off “Frankenstein” roles.
Boundary: A sensible base for most systems. Do not let the role count explode — strengthen it with ABAC predicates or resource-level exceptions.
ABAC
When suitable: Compliance-heavy domains — finance, healthcare, govtech — where the decision depends on context and data classification.
Where it hurts: Teams without attribute governance or a testable policy lifecycle: attributes go stale quietly, access breaks loudly.
Boundary: The cost of entry is a strict attribute dictionary, audited policy changes, and a decision trace — otherwise “why was access granted” has no answer.
ReBAC (Zanzibar)
When suitable: Collaborative products — documents, repositories, workspaces — where access is naturally a graph of relationships.
Where it hurts: Small systems where the relationship graph does not justify the infrastructural cost of a separate service.
Boundary: Justified when relationship checks are many and you need a consistent global authorization service — otherwise you pay more for infrastructure than you save.
In 2026, a typical production approach is RBAC as the frame, ABAC for contextual conditions, ReBAC for shared objects, and ACL as a local resource override.
Access policy lifecycle controls
| Stage | Mandatory controls | Failure action |
|---|---|---|
| Policy design | Unified resource/action dictionary, owner for each policy zone, policy-as-code with code review. | Block policy merges without an owner and tests, then return the change to the team backlog. |
| Distribution and versioning | Versioned policy bundles, canary rollout, signed artifacts and runtime integrity verification. | Stop the rollout and automatically roll back to the last stable policy version. |
| Decision path | Fail-closed on critical endpoints, deny-by-default, object-level checks for sensitive operations. | Disable risky operations and raise a high-priority alert for the on-call engineer. |
| Review and recertification | Scheduled access reviews, role recertification, and orphan-access detection after org changes. | Automatically mark access as temporary and initiate revocation until owner confirmation. |
| Emergency revocation | Unified break-glass process, mass revocation for tokens and relations, impact verification via audit trail. | Switch the system to a restricted mode and force-close high-risk active sessions. |
Authorization operational metrics
P95 authorization check latency
Target: <= 20 ms
When checks are slow, teams bypass the policy layer and lose consistency of access control.
Share of decisions with explain trace
Target: >= 99%
Without it an incident review runs on guesswork: there is nothing to answer “why was access granted or denied” with.
MTTR for policy rollback
Target: < 10 minutes
Fast rollback is critical when a new policy breaks production traffic or legitimate access.
Expired accesses after offboarding
Target: 0
Shows identity lifecycle maturity and reduces the risk of unauthorized access by former users.
Object-level check coverage on high-risk API
Target: 100%
Without an “is this object even yours” check, a BOLA/IDOR hole remains — the user logs in fine, AuthN is correct, yet reads someone else’s data via a swapped identifier.
Access model rollout roadmap
Phase 1 (0-30 days)
Focus: Access and critical-resource inventory
Outcome: A map of subjects, roles, resources and current exceptions with assigned owners.
Phase 2 (30-60 days)
Focus: RBAC baseline and deny by default
Outcome: Unified role catalog, centralized policy-check middleware and baseline decision audit logs.
Phase 3 (60-90 days)
Focus: Context rules and relation graph
Outcome: ABAC predicates for risk and context, ReBAC for shared objects, and an explain API for access debugging.
Phase 4 (90+ days)
Focus: Governance and continuous verification
Outcome: Regular access reviews, policy quality gates in CI/CD and measurable SLOs for the authorization platform.
Typical antipatterns
Collapse everything into one all-powerful admin role — it covers any scenario, but becomes a single point of compromise.
Mix business attributes and security attributes without an owner or a data contract: a change in one system silently rewrites rights in another.
Build ReBAC without explainability — when neither the user nor support can say why access exists or is denied.
Leave rights in place after a reorg, offboarding, or role change without automatic revocation — that is how orphaned access piles up and former people keep using it.
References
Related chapters
- Identification, Authentication and Authorization (AuthN/AuthZ) - Provides the IAM foundation: an access model does not work in isolation from identity lifecycle and trust context.
- Zero Trust: a modern approach to architectural security - Shows how ACL/RBAC/ABAC/ReBAC fit into continuous policy enforcement and verify-every-request architecture.
- API Security Patterns - Maps access models to API execution: object-level checks, token policies and deny-by-default controls.
- Secrets Management Patterns - Connects service identities with secure secret delivery for policy engines and runtime controls.
- Data Governance & Compliance - Shows where the data classification and compliance requirements come from that access predicates and decision audits rely on.