ABAC

How it works

ABAC (Attribute-Based Access Control) decides access by evaluating policies over attributes of the user, the resource, the action, and the environment, rather than by a fixed role. A policy reads like a rule: "allow if user.department equals resource.department and request.time is business hours and user.clearance is greater than or equal to resource.classification." Because any attribute can enter a policy, ABAC expresses fine-grained, contextual rules that RBAC cannot capture without an explosion of roles. It is often implemented with a policy engine and a policy language such as those used in modern authorization services.

When it matters

ABAC matters when access depends on context, not just identity: data residency rules, time-of-day restrictions, ownership, clearance levels, or multi-dimensional conditions. It is powerful for regulated and multi-tenant systems where roles alone become unmanageable. The tradeoff is that policies are harder to audit at a glance than a role list, so many teams start with RBAC and add ABAC-style rules only where they are needed. For relationship-driven access, compare ReBAC.

Common misconceptions

• "ABAC replaces RBAC." In practice they combine; roles are just one attribute. Many systems run RBAC with attribute-based refinements.
• "ABAC is always better because it is flexible." Flexibility costs auditability and performance. Use it where context genuinely drives access, not everywhere.
• "ABAC and ReBAC are the same." ABAC evaluates attributes; ReBAC evaluates relationships in a graph. Different models for different problems.