Stackbook Logo
security-complianceestablished · medium operational burden

RBAC vs ABAC Authorization

Also known as: role-based-access-control, attribute-based-access-control, policy-based-authorization

Intent

Choose and implement an authorization model that grants access by role for simplicity or by attributes and context for fine-grained control.

Problem

Hard-coded permission checks scatter across services and drift from business rules. Pure roles explode in number as requirements grow, while ad hoc conditions become unauditable.

Forces

  • •Auditors need to answer who can access what
  • •Rules depend on resource owner, tenant or time
  • •Decisions sit on the hot path of every request
  • •Policies change faster than deployments

Solution

Overview

RBAC answers whether a user holds a role that carries a permission. ABAC answers whether the attributes of the subject, resource, action and environment satisfy a policy. Most production systems use roles for coarse access and attributes for the exceptions.

A pragmatic path is to model permissions as verbs on resource types, bundle them into a handful of roles, and add attribute conditions only for tenant, ownership and sensitivity rules. Run decision logs in shadow mode when changing policies so you can compare old and new outcomes before enforcing.

How it works

PEP (service) -> PDP: { subject: {id, roles, dept},
                        action: "read",
                        resource: {type: "invoice", owner: "u7", tenant: "t1"},
                        env: {ip, time} }
PDP evaluates policy:
  allow if "finance" in subject.roles
       and resource.tenant == subject.tenant
PDP -> PEP: allow | deny (+ reason for audit log)

The enforcement point is called in every service; the decision logic lives in versioned policy files evaluated locally or by a sidecar.

Pitfalls

  • Checking roles in code (is admin) rather than permissions, which blocks later change.
  • Failing open when the policy service is unreachable. Default to deny.
  • Forgetting tenant checks, producing cross-tenant data leaks.
  • Trusting client-supplied attributes.
  • Skipping policy unit tests and decision logging.

Key takeaways

  • Begin with RBAC; add attributes only where roles explode.
  • Separate enforcement from decision logic and default to deny.
  • Source attributes from trusted systems and keep them fresh.
  • Test policies like code and log every decision.

✓ When to Use

  • •Multi-tenant SaaS with ownership rules
  • •Regulated data needing auditable access decisions
  • •Growing role counts that are hard to manage

✗ When Not to Use

  • •Tiny apps with two or three static roles
  • •Relationship-heavy sharing like documents (consider ReBAC)
  • •Teams unable to maintain policy test suites

Pros

  • +RBAC is simple to explain and audit
  • +ABAC expresses contextual rules without role explosion
  • +Central policies change without redeploying services

Cons

  • −ABAC policies are harder to reason about
  • −Attribute sourcing adds latency and coupling
  • −Role sprawl degrades RBAC over time

Cost Profile

Infrastructure

Low to medium — policy engine sidecar or service

Operational

Medium — policy lifecycle and testing

Cognitive

Medium to high

Failure Modes

  • Stale attributes grant access after a user changes teams

  • Policy engine outage causes fail-open or global denial

  • Role explosion makes least privilege unreviewable

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      security compliancerequirements constraints