Attribute-based access control vs RBAC

RBAC works well until a rule can't be expressed as a role — 'editors can edit their own drafts, but only during business hours, and only if the document isn't legally locked.' ABAC is what you reach for when the decision depends on context that roles alone can't encode.

Advanced

3 min read

Where RBAC's role model stops being enough

RBAC answers authorization questions with a fixed lookup: does this user's role include this permission? That works cleanly when permissions are stable and coarse-grained. It breaks down when the real rule depends on something a role can't hold — the relationship between the user and the specific resource, the time of day, the resource's current state, or the device the request is coming from. The usual symptom is role explosion: editor, editor-for-own-drafts, editor-during-business-hours, senior-editor-for-locked-docs — a combinatorial sprawl of roles that exist only to encode conditions RBAC has no other way to express.

ABAC: policies over attributes, not permissions over roles

Attribute-based access control evaluates a policy against attributes of the subject (user), the resource, the action, and the environment — at request time, rather than pre-computing a fixed role-to-permission table:

policy: allow "edit" on resource:document if
  subject.department == resource.department
  AND resource.owner_id == subject.id
  AND resource.status != "legally_locked"
  AND environment.time_of_day BETWEEN 09:00 AND 18:00

Nothing here needed a new role. Any of those attributes can change independently, and the policy stays a single readable rule instead of a new row in a role table. NIST's ABAC guidance (SP 800-162) formalizes this model as evaluating subject, object, action, and environment attributes against policy — it's the closest thing to an industry-standard definition of the pattern.

Modeling the same rule both ways

Take "an editor can delete their own draft posts." In RBAC, this needs either a coarse delete:post permission (too broad — lets editors delete anyone's posts) or a bespoke delete:own_post permission that only means anything once combined with an ownership check in code. In ABAC, ownership is just another attribute comparison, no special-cased permission required:

RBAC:  role.permissions.includes("delete:own_post")
       AND resource.owner_id == user.id   # ownership check still lives in app code

ABAC:  allow "delete" on resource:post if
         subject.id == resource.owner_id
         AND resource.status == "draft"

The RBAC version still ends up doing an attribute check in application code — it just doesn't call it that. ABAC makes that check a first-class, centrally defined part of the policy instead of scattered logic.

Combining them instead of choosing

In practice, mature systems use both: RBAC for the coarse first cut ("is this user an admin, an editor, or a viewer at all") and ABAC for the fine-grained conditions layered on top ("...and can this specific editor act on this specific resource, right now"). Treating it as ABAC-replaces-RBAC is usually a mistake — roles remain a useful, cheap way to express broad intent; attributes handle the exceptions and context that roles were never meant to carry.

The real cost of ABAC: policy testing and explainability

ABAC's flexibility has a price. A rule engine evaluating boolean expressions over arbitrary attributes is much harder to reason about at a glance than "alice has the editor role" — when access is denied, "which of these five attribute conditions failed" is a debugging problem RBAC rarely creates. Policies need their own test suite, the same way authorization frameworks do, and production ABAC systems (Open Policy Agent, AWS Cedar) invest heavily in explainability tooling — being able to show exactly which clause of a policy allowed or denied a specific request — precisely because "the policy said no" is not an acceptable answer to a support ticket.