We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Security Architecture
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers ABAC across a run of lessons, not one page. These 4 alone are about 65 minutes of step-by-step reading, every one with a quiz.
Making access decisions based on attributes of users, resources, and environment, the most flexible access control model.
Controlling what authenticated users are allowed to do: permissions, roles, and access policies.
Assigning permissions to roles instead of individuals, the most widely used access control model in production systems.
Defining access rules as declarative policies evaluated by a central decision engine, OPA, Cedar, and beyond.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Attribute-Based Access Control (ABAC)pay once,
yours for life
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.
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, Not Applicable, or Indeterminate (the rules could not be evaluated, for example because an attribute was missing), 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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "Attribute-Based Access Control (ABAC)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Attribute-Based Access Control (ABAC) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about ABAC in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
