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.
The authorization model determines how exactly the system makes the access decision. In practice, teams combine several approaches: RBAC as a base layer, ABAC for context and exceptions, ReBAC for graph-shaped collaboration, 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 with an explicit owner rule.
Where it hurts: Large multi-tenant systems, where bulk access changes become too expensive.
Boundary: Use it as a local model next to the resource, not as 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: Contextual decisions by geography, time, or risk, plus per-object exceptions.
Boundary: A good base model for most systems. Strengthen it with ABAC predicates or resource-level exceptions.
ABAC
When suitable: Domains with compliance: finance, healthcare, govtech, where context and data classification are important.
Where it hurts: Teams without attribute governance or a testable policy lifecycle.
Boundary: Requires a strict attribute dictionary, audited policy changes, and explain/trace tooling for decisions.
ReBAC (Zanzibar)
When suitable: Collaborative products: documents, repositories, workspaces, complex shared graphs.
Where it hurts: Small systems where the relationship graph does not justify the infrastructural complexity.
Boundary: Justified when there are many relationship checks and a need for a consistent global authorization service.
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%
Required for incident investigations and clear answers on why access was granted or denied.
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 object-level enforcement, BOLA/IDOR risk remains even when AuthN is technically correct.
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
Create one all-powerful admin role and try to cover every access scenario with it.
Mix business attributes and security attributes without an owner or a data contract.
Build ReBAC without explainability: users cannot understand why access exists or is denied.
Leave rights in place after organizational changes, offboarding, or role changes without automatic revocation.
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 - Extends the topic with data classification, auditability and compliance requirements for access governance.