RBAC Role Explosion vs ABAC Policy Lab (Interactive)
Multiply enterprise context dimensions and watch RBAC roles explode while ABAC stays linear. Price branches x shifts x tiers as minted roles versus attribute rules, then run one live request through both engines including context-blind RBAC mistakes.
Role Explosion Lab: RBAC vs ABAC Policy Engine
Same request, two authorization models — watch role count explode multiplicatively while ABAC rules stay linear.
Enterprise context dimensions
RBAC roles needed
147
ABAC rules needed
22
Contextual rules are branches × shifts × tiers = 144 combinations. RBAC must pre-mint each as a named role (e.g. doctor_cardiology_activeshift); ABAC collapses them into 19 attribute clauses — a 85.0% reduction.
Live PDP request (the 4 ABAC tuples)
Engine A — RBAC (static role→permission set)
ALLOW · lookup users.role ∈ allowed_roles_for(action) → O(1), ~0.05ms
Engine B — ABAC via OPA sidecar (Rego rule evaluation)
ALLOW · decision = f(subject, resource, action, environment)
- ✓ subject.department (Cardiology) == resource.department (Cardiology)
- ✓ environment.on_shift == true
- ✓ environment.device.is_managed && is_encrypted
Cost paid: Rego eval < 1ms locally, but the PIP must aggregate attributes first — HR system (department), MDM (device posture), scheduling service (shift) ≈ 15–40ms on cold cache. Policy-as-code lives in Git; changing rules never redeploys the backend.
Where neither model fits: collaboration graphs. "Alice can edit doc:readme because she is a member of team:infra, which owns folder:eng" is a relationship, not a role or an attribute — that is ReBAC, Google Zanzibar's tuple store (doc#viewer@user:alice) evaluated as graph reachability at billions of checks/sec with sub-10ms p95 and Zookie causal-consistency tokens. Rule of thumb for interviews: RBAC for pricing tiers, ABAC for contextual compliance, ReBAC for sharing hierarchies.
How It Works Under the Hood
RBAC maps users to roles and roles to permissions: an O(1) set lookup that auditors understand and that covers most SaaS pricing tiers. Its failure mode arrives with context. Doctors viewing charts only on active shift, managers approving expenses only for their branch, engineers reaching staging only from managed laptops; expressing that statically multiplies dimensions into thousands of hyper-specific composite roles nobody can audit. ABAC replaces pre-minted combinations with one decision function over subject, resource, action, and environment attributes, evaluated by an OPA sidecar in under a millisecond after attribute aggregation from HR, MDM, and scheduling services. The lab shows the multiplicative-versus-linear count and exposes RBAC's dangerous silent-allow when environment context is missing. For sharing graphs, neither fits: that is ReBAC, the Google Zanzibar tuple model.
Core Architectural Principles
- RBAC role count = 3 + branches x shifts x tiers; ABAC rule clauses stay a linear sum.
- The RBAC engine ignores on_shift, device posture, and department match, producing context-blind allows.
- ABAC cost: sub-millisecond Rego evaluation plus 15-40 ms of PIP attribute aggregation on cold cache.
Define role explosion with a concrete triple (branch x shift x limit tier) before proposing ABAC's four attribute categories. Show the OPA/Rego policy-as-code story for rule changes without redeploying, and finish with Zanzibar ReBAC tuples for hierarchical sharing graphs. Naming all three models and when each fits is the senior signal.
RBAC is fast and auditable for static tiers; ABAC scales with context but adds aggregation latency and needs tested policy code.