Tech_Interview_Prep

RBAC vs. ABAC Implementation

Assigning permissions via roles versus evaluating policies against attributes — the implementation tradeoffs of each.

What it is

RBAC and ABAC are two models for implementing authorization — RBAC grants permissions via assigned roles; ABAC evaluates a policy against attributes (of the user, resource, and context) at request time.

Key points

  • RBAC: simple to reason about and audit ("what can this role do") — but can suffer role explosion as an organization's access needs get more granular, since a new access pattern often means a new role.
  • ABAC: far more flexible — a policy like "allow if user.department == resource.department AND time is business hours" can express fine-grained rules RBAC can't cleanly capture — at the cost of policies being harder to audit at a glance.
  • Hybrid approaches are common in practice: roles provide the coarse-grained default, with attribute-based policies layered on top for exceptions and finer-grained cases.
  • The implementation choice affects more than security — it affects how easy the system is to audit for compliance, since "list everyone who can access X" is straightforward under RBAC and can require actual policy evaluation under ABAC.