ABAC
Attribute-Based Access Control: grants permissions based on attributes (user department, resource type, time of day, IP range). More flexible but more complex than RBAC.
What is ABAC?
In short
ABAC (Attribute-Based Access Control) is an authorization model that decides whether to allow an action by evaluating attributes of the user, the resource, the action, and the environment against a set of policy rules, instead of relying on fixed roles. For example, a rule like "allow if user.department == resource.owningDepartment AND request.time is during business hours AND request.ip is in the corporate range" is evaluated at request time.
What ABAC actually is
Attribute-Based Access Control is a way to answer one question: should this subject be allowed to perform this action on this resource right now? Instead of looking up a role and a static permission table, ABAC looks at attributes (key-value facts) about four things and runs them through policy rules.
The four attribute categories are: subject attributes (the user's department, clearance level, team, employment status), resource attributes (the file's classification, owner, project, region), action attributes (read, write, delete, approve), and environment attributes (time of day, source IP, device posture, MFA status).
A policy is a rule that combines those attributes with boolean logic. A classic example: allow read if subject.clearance >= resource.classification AND subject.country == resource.dataResidency. Nothing is hardcoded to a named role, so the same engine can express very fine-grained decisions.
How it works under the hood
Most ABAC systems follow the XACML reference architecture, which splits the work into four parts. The Policy Enforcement Point (PEP) sits in front of the resource and intercepts the request. It packages up the attributes and asks the Policy Decision Point (PDP) for a verdict. The PDP loads the relevant rules from the Policy Administration Point (PAP) and pulls any missing attribute values from a Policy Information Point (PIP), such as an HR directory or a device-trust service.
The PDP returns Permit, Deny, or Not Applicable, plus optional obligations like log this access or require step-up MFA. The PEP enforces that verdict. Because the decision is computed per request from live attribute values, the same user can be permitted at 10am from the office and denied at midnight from an unknown IP, with zero change to their role.
Modern implementations express policies as code. AWS uses JSON IAM policies with Condition blocks and tags. Open Policy Agent (OPA) uses a language called Rego. Both evaluate in single-digit milliseconds, and teams cache attribute lookups so the PDP does not hammer the directory on every call.
When to use it and the trade-offs
Reach for ABAC when role explosion has set in. If you find yourself creating roles like editor-region-eu-project-x-readonly, that combinatorial blowup is exactly what attributes solve. ABAC also wins when decisions depend on context that changes per request: time, location, data sensitivity, or relationships like is this record assigned to me.
The trade-off is complexity. RBAC is easy to audit because you can list who has a role. With ABAC, a permission is the output of a rule plus live data, so answering who can access this resource means simulating policies against many attribute combinations. Bad attribute data (a stale department field) silently grants or blocks access, so attribute hygiene becomes a security control.
In practice teams blend the two. They keep coarse roles for the common cases and layer attribute conditions on top for the exceptions. This is sometimes called policy-based or hybrid access control, and it keeps day-to-day administration simple while still allowing fine-grained rules where they matter.
Where it is used in production
AWS IAM
Tag-based and condition-based policies are pure ABAC: a policy can allow access only when the resource tag Project matches the principal tag Project.
Open Policy Agent (OPA)
A general-purpose policy engine where Rego rules evaluate request attributes; widely used as the PDP for Kubernetes admission and microservice authorization.
Microsoft Entra ID
Conditional Access evaluates user, device, location, and risk attributes to permit, block, or require MFA on each sign-in.
Google Cloud IAM Conditions
Lets you attach attribute conditions like request time or resource name prefix to an IAM binding so a grant only applies in specific contexts.
Frequently asked questions
- What is the difference between ABAC and RBAC?
- RBAC grants permissions through named roles you assign to users, so access is decided by which role you hold. ABAC computes access at request time from attributes of the user, resource, action, and environment. RBAC is simpler to audit; ABAC is more flexible and avoids role explosion.
- Is ABAC more secure than RBAC?
- Not automatically. ABAC enables tighter, context-aware least-privilege rules, but it is only as good as its attribute data and policy logic. A stale or wrong attribute can silently grant access, so ABAC shifts some risk into data quality and policy testing.
- What is XACML and how does it relate to ABAC?
- XACML (eXtensible Access Control Markup Language) is the OASIS standard that defined the ABAC reference architecture: the PEP, PDP, PAP, and PIP components, plus an XML policy language. Most modern engines keep that architecture but use friendlier policy languages like Rego or JSON.
- Can I use ABAC and RBAC together?
- Yes, and most production systems do. A common pattern is to assign coarse roles for the bulk of permissions and add attribute conditions for the exceptions, for example allow the editor role only when resource.region equals user.region.
- Does ABAC hurt performance?
- Each request runs a policy evaluation, which is typically single-digit milliseconds. The real cost is fetching attributes from external sources like a directory, so teams cache attribute values and keep the policy decision point close to the application to stay fast.
Learn ABAC hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on ABAC as part of a larger topic.
See also
Related glossary terms you might want to look up next.
RBAC
Role-Based Access Control: assigns permissions to roles (admin, editor, viewer), then assigns roles to users. Simpler to manage than per-user permissions.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
SSL/TLS
Cryptographic protocols that encrypt data in transit between client and server. TLS is the modern successor to SSL. The 'S' in HTTPS.
CORS
Cross-Origin Resource Sharing: a security mechanism that controls which domains can access your API. The browser enforces it; the server configures it.