Attribute-Based Access Control (ABAC)
Authorization model where decisions are based on attributes of the subject, resource, action, and environment — evaluated against policy rules at request time.
Attribute-Based Access Control (ABAC) is an authorization model where access decisions are based on evaluating policies against attributes at request time. Attributes come from four categories: subject (user), resource (data), action (operation), and environment (context).
How ABAC differs from RBAC
RBAC asks "what roles does this user have?" ABAC asks "do the attributes of this request satisfy the policy?" This makes ABAC more expressive — it can evaluate conditions like "user's region equals resource's region AND current time is business hours" — but also more complex.
When to use ABAC
- Access depends on runtime context (time, location, device posture)
- Resource ownership determines access (user must own the document)
- Data classification drives permissions (PII, confidential, public)
- Multi-dimensional rules need a single policy, not hundred of roles
WardenAuth's hybrid model
WardenAuth supports ABAC conditions on any permission. The RBAC core handles identity-based access; ABAC conditions add contextual refinement. See RBAC vs ABAC.
Related terms
Authorization that evaluates permissions at the individual resource or action level, rather than broadly by user type or role.
Role-Based Access Control (RBAC) grants permissions via roles. Attribute-Based Access Control (ABAC) evaluates arbitrary attributes (user, resource, environment) against policy rules.
Authorization model based on relationships between subjects and objects (e.g., owner, editor, viewer). Popularized by Google's Zanzibar paper. Access is resolved through graph traversal.