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 one changes policy expressiveness, explainability, operational 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
Use guidance on ACL/RBAC/ABAC/ReBAC access-control models and their fit to define architectural security requirements before implementation starts.
Decision quality
Validate solutions through threat model, security invariants, and production control operability, not compliance checklists alone.
Interview articulation
Frame answers as threat -> control -> residual risk, linking business scenario to concrete protection mechanisms.
Trade-off framing
Make trade-offs explicit for ACL/RBAC/ABAC/ReBAC access-control models and their fit: UX friction, latency overhead, operational cost, and compliance constraints.
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 visualization of models
ACL
Rights are stored next to the resource as a list of subjects and permissions.
Comparison of models
| Criterion | ACL | RBAC | ABAC | ReBAC |
|---|---|---|---|---|
| Unit of Policy | Entry per resource | Role | Rule | Relation in the graph |
| Granularity | Very accurate, but local | Average | High | High on the graph |
| Access changes | Expensive on larger sets | Cheap via role mapping | Via Policy/Attributes | Through new relation tuples |
| Explainability | High | High | Average | Medium, need explain API |
| Platform complexity | Low | Low-medium | Medium-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 storage, file systems, small isolated domains with an explicit owner rule.
Where does it start to hurt: Large multi-tenant systems: mass rights changes are too expensive.
Border: Use it as an edge model next to a resource, but not as a single global policy for the entire company.
RBAC
When suitable: Internal platforms, B2B SaaS, mature org structures with clear job functions.
Where does it start to hurt: Contextual decisions (geo/time/risk) and object exceptions per item.
Border: Basic model for most systems. Strengthen with ABAC predicates or ACL exceptions.
ABAC
When suitable: Domains with compliance: finance, healthcare, govtech, where context and data classification are important.
Where does it start to hurt: Teams without governance for attributes and without a testable policy lifecycle.
Border: We need a strict dictionary of attributes, audit policy changes and tools to explain/trace solutions.
ReBAC (Zanzibar)
When suitable: Collaborative products: documents, repositories, workspaces, complex shared graphs.
Where does it start to hurt: Small systems where the relationship graph does not justify the infrastructural complexity.
Border: Justified when there are a large number of relationship checks and the need for a consistent global AuthZ service.
In 2026, a typical production approach: RBAC as a framework, ABAC as context conditions, ReBAC for shared objects, ACL as local override on a resource.
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 merge without an owner and tests, and return the change to the team backlog. |
| Distribution and versioning | Versioned policy bundles, canary rollout, signed artifacts and runtime integrity verification. | Stop rollout and automatically rollback 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 revoke until owner confirmation. |
| Emergency revoke | Unified break-glass process, mass revoke for tokens/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 user-facing answers on permit/deny decisions.
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 former-user access.
Object-level check coverage on high-risk API
Target: 100%
Without object-level enforcement, BOLA/IDOR risk remains even with formally correct AuthN.
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/context, ReBAC for shared objects and 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
Make one 'god-role admin' and try to close all access scenarios with it.
Mix business attributes and security attributes without owner and without data contract.
Build ReBAC without explainability: users do not understand why access is available or not.
Leave rights after org changes (offboarding/role change) without automatic revoke.
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 authorization controls.
- Data Governance & Compliance - Extends the topic with data classification, auditability and compliance requirements for access governance.