Skip to content

RBAC vs ABAC

1. Decision

Choose Role-Based Access Control (RBAC) for simple, static authorization models where permissions map directly to pre-defined user job roles (e.g. Admin, Manager, Editor); choose Attribute-Based Access Control (ABAC) for complex, dynamic, context-aware authorization policies requiring fine-grained rules based on user attributes, resource attributes, environmental context, and relationship graphs.

2. 30-Second Answer

Authorization models dictate how permissions are evaluated. Role-Based Access Control (RBAC) assigns permissions to static Roles (e.g., Admin, Viewer, BillingManager), and users are assigned one or more roles. It is simple, easy to audit, and widely supported by database frameworks, but suffers from Role Explosion when business rules require fine-grained conditions. Attribute-Based Access Control (ABAC) evaluates boolean policy logic dynamically against Attributes of the User (department, security clearance), Resource (classification, owner_id), Action (read, write), and Environment (time of day, user location, IP address). ABAC delivers fine-grained, dynamic access control, but requires a specialized Policy Decision Point (PDP) evaluation engine (e.g., Open Policy Agent / OPA).

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
RBAC (Role-Based Access Control) Standard enterprise applications, administrative backends, fixed organizational hierarchies, simple permission matrices Fine-grained contextual rules (e.g., "Allow access only if user is in EU, during business hours, and owns document") Ultra-Low (Fast string/array role matching e.g. user.hasRole('Admin')) Scales well for simple static role structures Static mapping via user-role tables Low
ABAC (Attribute-Based Access Control) Healthcare HIPAA compliance, financial data isolation, multi-tenant B2B SaaS, dynamic contextual policies Simple CRUD applications with static permissions (causes over-engineering) Low to Medium (Policy engine execution: OPA Rego rule evaluation) Extremely Scalable policy management (Avoids Role Explosion) Dynamic policy-driven evaluation Medium to High (Requires OPA / PDP engine)

4. Selection Rules

Requirement Best Choice Rationale / Example
Simple Static Job-Role Authorization RBAC Assign user role Editor; check if (roles.includes('Editor')) before action
Dynamic Contextual Policy ("Allow Access IF...") ABAC Allow doctor access to medical record ONLY IF doctor.dept == patient.dept AND time < 17:00
Prevent Role Explosion in Multi-Tenant SaaS ABAC Instead of creating 500 roles (TenantA_Admin, TenantB_Editor), evaluate user.tenant_id == resource.tenant_id
Decouple Policy Authorization Code (OPA) ABAC (Open Policy Agent) Export authorization policies to Open Policy Agent (OPA Rego) evaluated via sidecar API
Relationship-Based Authorization (Google Zanzibar) ReBAC (Relationship-Based) Model permissions via tuple graphs ("User A is a member of Team B which owns Document C")

5. Tradeoffs

  1. Static Simplicity vs Dynamic Granularity
  2. Gain (RBAC): Easy to understand, simple SQL queries (user_roles mapping tables), instant auditability.
  3. Lose (RBAC): Cannot evaluate environmental context (time, location) or resource ownership natively.
  4. Role Explosion Prevention vs Policy Engine Latency
  5. Gain (ABAC): A single ABAC policy ruleset replaces hundreds of dynamic custom roles.
  6. Lose (ABAC): Evaluating complex policy expressions adds 1-5ms policy decision latency.
  7. Centralized Policy Management vs Developer Overhead
  8. Gain (ABAC): Security teams update policies centrally in OPA/Rego without re-deploying application microservice code.
  9. Lose (ABAC): Higher learning curve mastering policy description languages (Rego / XACML).
  10. Database Filtering Performance
  11. Gain (RBAC): Simple WHERE role = 'Admin' SQL filtering.
  12. Lose (ABAC): Difficult to translate dynamic ABAC policies directly into efficient database SQL queries (requires partial evaluation).
  13. Auditing Clarity
  14. Gain (RBAC): Answering "What can User X access?" is a simple SQL query listing assigned roles.
  15. Lose (ABAC): Answering "What can User X access?" requires evaluating dynamic attribute policies across every resource.

6. Interview Counter Questions

  1. What is the Role Explosion problem in RBAC and how does ABAC solve it?
  2. How does Open Policy Agent (OPA) implement ABAC and Policy-as-Code (Rego)?
  3. What are the 4 attribute categories evaluated in ABAC (Subject, Resource, Action, Environment)?
  4. How do PDP (Policy Decision Point) and PEP (Policy Enforcement Point) work in authorization architectures?
  5. How does Google Zanzibar (ReBAC - Relationship-Based Access Control) differ from RBAC and ABAC?
  6. How do you pass user attributes securely from an API Gateway to a Policy Engine?
  7. Why is translating ABAC policies into SQL WHERE clauses for database pagination difficult?
  8. How do you implement fine-grained resource ownership checks ("User can edit only their own posts") in RBAC vs ABAC?
  9. What is XACML and why has it been largely replaced by Open Policy Agent (OPA / Rego)?
  10. How do you test and version-control ABAC policies in a CI/CD pipeline?

7. Gold Standard Answers

  1. Role Explosion occurs in RBAC when combining multiple dimensions (Role \(\times\) Department \(\times\) Location \(\times\) Tenant) forces creating thousands of custom roles (NY_Sales_Manager_Tier2). ABAC replaces these with 1 policy evaluating attributes dynamically.
  2. OPA is an open-source general-purpose policy engine. Microservices query OPA via HTTP/Wasm passing JSON inputs {"user": ..., "resource": ...}. OPA evaluates policies written in Rego language and returns {"allow": true}.
  3. Subject (User): Department, role, clearance. Resource: Owner ID, classification, tenant ID. Action: Read, write, delete. Environment: IP address, time of day, current threat level.
  4. PEP (Policy Enforcement Point): Microservice / API Gateway that intercepts requests and enforces decisions. PDP (Policy Decision Point): The OPA engine that evaluates attributes against policies and returns allow/deny.
  5. ReBAC models authorization as a graph of relationship tuples (e.g. doc:123#viewer@user:456). Used by Google Drive, Slack, and Carta (via Zanzibar/SpiceDB) to evaluate nested group inheritance efficiently.
  6. API Gateway verifies JWT token, extracts user claims/attributes, packages them into the request context header, and passes them to the PEP/PDP authorization layer.
  7. Filtering a paginated list of 1 million records via ABAC requires the DB to know which rows match policy attributes. Solved using OPA Partial Evaluation, which translates Rego policies into native SQL WHERE expressions.
  8. RBAC requires writing custom application code checks if (post.author_id == user.id). ABAC handles it natively inside the policy rule allow { input.user.id == input.resource.author_id }.
  9. XACML is an older, verbose XML-based authorization standard. OPA/Rego uses modern lightweight JSON inputs and declarative Datalog-based logic, making it developer-friendly and cloud-native.
  10. Store Rego policies in Git. Run unit tests using OPA CLI (opa test). Validate policies in CI/CD pipelines before bundling Wasm modules into production API sidecars.

8. Common Mistakes

  • Creating hundreds of hyper-specific static roles in RBAC (Manager_US_East_ReadOnly), leading to administrative Role Explosion.
  • Hardcoding complex ABAC attribute logic directly into microservice if/else statements instead of using a policy engine (OPA).
  • Failing to evaluate Environmental attributes (IP address, time) for high-security healthcare or financial applications.
  • Attempting to use ABAC for simple applications where basic 3-role RBAC (Admin, User, Guest) is completely sufficient.
  • Forgetting that evaluating dynamic ABAC policies on paginated list endpoints requires database-level predicate pushdown.

9. Keywords

RBAC, ABAC, ReBAC, Role Explosion, Attributes, Subject, Resource, Action, Environment, Open Policy Agent (OPA), Rego, PEP (Policy Enforcement Point), PDP (Policy Decision Point), Google Zanzibar, Policy-as-Code, XACML.

10. Cheat Sheet

  • RBAC: Static role assignment (User \(\rightarrow\) Roles \(\rightarrow\) Permissions). Simple, auditable, low ops. Best for standard admin apps.
  • ABAC: Dynamic policy logic evaluating Attributes (User, Resource, Action, Environment). Prevents Role Explosion. Best for multi-tenant B2B & HIPAA.
  • ReBAC: Relationship-Based Access Control (Google Zanzibar). Models permissions as a relationship tuple graph (doc#viewer@user).
  • Policy Engine: Use Open Policy Agent (OPA) with Rego language to manage policies as code outside app binaries.
  • Architecture: PEP (API Gateway/Microservice) intercepts request \(\rightarrow\) queries PDP (OPA) \(\rightarrow\) enforces Allow/Deny.
  • Rule of Thumb: \(<5\) fixed roles = RBAC; Complex contextual conditions & fine-grained tenant rules = ABAC / OPA.

11. Related Decisions