Attribute-Based Access Control (ABAC): access follows the context

Forty-two roles for one rule

The compliance team sends Sara a new requirement for the support platform: support agents may read a customer’s account only if the account is in the agent’s own region, only while the agent has an open ticket for that customer, and only during their working hours. The administrator who runs the platform’s roles does the arithmetic out loud. Fourteen regions, three shifts: that’s forty-two roles before anyone even thinks about the ticket condition, which no role can express at all, because whether a ticket is open changes every few minutes.

The previous article left RBAC at exactly this edge. Roles capture what your job is, but they can’t capture the situation: the region a resource belongs to, whether you own it, the time of day, the health of your device, a live risk score. When access depends on a condition rather than a fixed assignment, RBAC’s only move is another role per combination, and the combinations explode. What’s needed is a model that evaluates the facts of the request itself, at the moment it happens. That model is attribute-based access control (ABAC).

ABAC changes the question. RBAC asks what roles you hold. ABAC asks: given who you are, what you’re touching, what you’re trying to do, and the conditions right now, does policy allow this? Each of those is a bucket of attributes, and an ABAC policy is a set of rules over them. Because attributes are read at request time, ABAC can express exactly the dynamic, contextual conditions that broke RBAC, and it can do so without creating anything in advance, because one rule saying “your region matches the resource’s region” covers every region at once. Sara’s forty-two roles become one rule.

ABAC is standardized in NIST SP 800-162, the reference guide to the model, and it’s the conceptual engine inside modern policy languages and cloud authorization. The intuition is old. Bell-LaPadula compared a clearance attribute with a classification attribute in the 1970s, so in a sense MAC was a rigid, two-attribute ancestor of ABAC. As a general model, though, ABAC matured with XACML, the eXtensible Access Control Markup Language standardized by OASIS in the 2000s, which gave attribute policies a formal request and response structure and a policy language. NIST published SP 800-162 in 2014, presenting ABAC as the way to scale access control to large, dynamic environments spanning organizations, where setting up every relationship in advance is impossible. The timing wasn’t a coincidence: ABAC went mainstream just as cloud, SaaS, and federation made access inherently contextual and roles alone stopped being enough.

The four kinds of attribute

An attribute is just a named property with a value: department = "support", classification = "confidential", time = 14:30. NIST SP 800-162 sorts them into four categories, and learning to sort a requirement into these buckets is most of the skill of thinking in ABAC.

Subject attributes describe the requester: department, job title, clearance, manager, team, certifications, type of employment. Resource attributes describe the object being accessed: owner, classification, region, project, sensitivity, creation date. Action attributes describe the operation, read, write, approve, delete, and sometimes qualifiers such as a transaction’s amount, which lets one rule tell “approve a small refund” from “approve a large one” without inventing separate actions. Environment attributes describe the context independent of who and what: the current time, the day of the week, the source location or network, device posture, how strongly the user authenticated, the current threat level. They’re what make access change over time, so the same subject and resource can get a different answer at 3 a.m. than at noon.

Sort the compliance rule into these buckets and it falls apart neatly. The agent’s region is a subject attribute and the account’s region is a resource attribute, so the rule compares them. The open ticket is a relationship between this agent and this customer, captured as an attribute. And working hours are an environment attribute. No new roles; one policy covers every agent, region, and customer.

Two points about those categories. Attributes don’t have to be stored; some are derived or computed on demand. isManagerOf(subject, resource.owner) or ticketOpen(agent, customer) aren’t fields sitting in a database; they’re questions answered by calling another system at decision time. That’s powerful, because policies can reason about live relationships and calculations, and risky, because each derived attribute is another dependency that can be slow, wrong, or unavailable. And environment attributes are the ones RBAC can’t touch at all, because a role is assigned once and can’t know the current time, place, or risk. The moment a requirement contains the word “when” or “where,” you’re almost certainly looking at an environment attribute, and almost certainly beyond RBAC.

A policy is rules over attributes

An ABAC policy is a set of rules, each evaluating attributes to a decision, permit or deny. Written as plain pseudo-policy, the compliance rule looks like this:

permit if
  action == "read"
  and subject.role == "support_agent"
  and resource.type == "customer_account"
  and subject.region == resource.region
  and ticketOpen(subject.id, resource.customer_id)
  and environment.time in business_hours

Every clause compares attributes. Change “read” to “close_account” and require subject.role == "supervisor" and you have a second rule. The full policy is the set of such rules plus a way of combining them, which we’ll come to. Notice what’s missing: there’s no list of which agents may touch which accounts. That list is computed from attributes on each request, which is why ABAC scales to situations RBAC would need millions of grants to cover, and also why, as we’ll see, answering “who can touch this account?” becomes genuinely hard.

flowchart LR
  accTitle: Attribute-Based Access Control decision flow
  accDescr: A subject issues a request to perform an action on a resource. That request goes to a policy engine in the center. Four attribute sources feed the engine: subject attributes such as department and region, resource attributes such as owner and classification, action attributes such as read or approve, and environment attributes such as time and location. The engine evaluates its policy rules against all the gathered attributes and returns a decision of permit or deny to the enforcement point in front of the resource.
  REQ[Subject requests action on resource] --> ENG{Policy engine}
  SUB[Subject attributes<br/>department, region] --> ENG
  RES[Resource attributes<br/>owner, classification] --> ENG
  ACT[Action attributes<br/>read, approve] --> ENG
  ENV[Environment attributes<br/>time, location, risk] --> ENG
  ENG -->|permit / deny| PEP[Enforcement point]
  PEP --> RESOURCE[(Resource)]

Where the attributes come from

A policy is only as good as the attributes it reads, and those have to come from somewhere authoritative. Subject attributes usually flow from the HR system and the identity provider, such as department, title, and manager, often carried in the tokens from the earlier articles. Resource attributes come from the systems that own the data: a tagging scheme, a data classification service, a configuration database. Environment attributes come from the runtime: the clock, the network, and the device-posture and risk signals that the trust algorithm in Zero Trust also uses.

This is the quiet heart of ABAC’s difficulty. Every attribute needs an authoritative source, an agreed meaning, and a process that keeps it fresh. If an account’s region is wrong, or a user’s department is a year out of date, the policy makes confident, wrong decisions. And unlike a bad role assignment, which someone might notice in a review, a bad attribute is invisible until it produces a bad decision. ABAC doesn’t remove the governance burden RBAC carries; it moves it from managing roles to managing attributes and their sources. Organizations that adopt ABAC without a program for governing attributes trade role sprawl for silent, data-driven mistakes.

There’s a subtler problem than staleness: meaning. When a policy compares subject.region with resource.region, both sides have to mean the same thing, with the same vocabulary, granularity, and encoding. If HR records the region as "EMEA" and the resource tagger writes "Europe", the rule quietly never matches, and a policy that looks right denies or permits for the wrong reason. Multiply that across dozens of attributes flowing from HR, the identity provider, a configuration database, and a dozen application teams, and semantic drift becomes a leading cause of authorization bugs. Mature ABAC programs therefore invest in an attribute schema, a governed catalog defining each attribute’s name, type, allowed values, and authoritative source, so that “region” means one thing everywhere. It’s unglamorous data-governance work, and it’s the difference between an ABAC deployment that holds together and one that quietly rots.

The usual failure in ABAC isn’t a wrong policy; it’s a right policy fed wrong attributes. A correct rule that reads a stale clearance, a mistyped region, or a device-trust signal that defaults to “trusted” when its feed is down will confidently authorize the wrong thing. Before trusting an attribute in a policy, know its source of truth, how quickly it updates, and how it behaves when it fails.

When rules disagree

Real policies have many rules, and two can reach opposite conclusions about the same request. A combining algorithm settles the conflict deterministically. The common ones are deny-overrides, where any deny wins, the safe default; permit-overrides, where any permit wins; first-applicable, where the first matching rule decides; and only-one-applicable. The choice is a security decision. Deny-overrides is conservative and usually right, but you have to know which algorithm your engine uses, because the same rules produce different answers under different combiners. A team that assumes deny-overrides while running an engine that defaults to permit-overrides has effectively inverted the safety of every conflict in its policy without knowing it.

There’s also the question of what to do when a needed attribute is simply missing, because a feed is down or a token lacks a claim. A well-designed policy is explicit: treat missing attributes as a denial for sensitive actions, failing closed, and never let “attribute not present” accidentally satisfy a condition. These combining and default rules are exactly what formal policy languages such as XACML, Rego, and Cedar make rigorous.

Because these interactions are subtle, testing stops being optional once policies get rich. A set of a dozen overlapping rules plus a combining algorithm is effectively a small program, and like any program it needs a test suite: representative requests with known expected decisions, run every time the policy changes, so adding one rule doesn’t silently flip an unrelated decision. That’s why the industry moved toward policy as code, expressing policy in a language you can version, review, and unit-test. Treating an ABAC policy as untested configuration is how a “more precise” model ends up behaving less predictably than the roles it replaced.

The reverse-query problem

ABAC’s expressiveness has a precise cost that surprises people. RBAC makes “who can access this resource?” trivial: read the list of roles that grant it. ABAC makes that question genuinely hard, because access isn’t stored; it’s computed. To answer “who can read this account?” you’d have to evaluate the policy for every possible subject under every relevant condition, because there’s no list to read, only a rule that gives an answer once you supply a concrete subject and moment.

This is the reverse-query problem, also called resource-centric review, and it’s the flip side of ABAC’s power. It complicates access reviews, audits, and questions like “does anyone outside Finance have a path to payroll?”, which auditors ask routinely and a pure ABAC system can’t answer by inspection. Regulations and audits are overwhelmingly resource-centric: prove who can access cardholder data, attest everyone with access to this system. A system that can only answer the forward question, “can this person do this thing right now?”, is awkward to audit by structure. That isn’t a reason to avoid ABAC, whose expressiveness is often indispensable, but it is a reason to design for auditability from the start: keep a readable role layer for the coarse grants, log every decision along with the attributes that drove it, and invest in tooling that enumerates or simulates decisions before the first audit rather than during it.

What ABAC gives you

ABAC earns its complexity where access really is conditional. It’s dynamic: decisions reflect the state of the world at request time, so access tightens automatically when risk rises or a ticket closes, with no administrator involved. It’s fine-grained: a rule can gate one field of one record on a precise combination of conditions. It scales in expressiveness: one policy covers every region, tenant, or customer, replacing what would otherwise be a combinatorial pile of roles. And it externalizes authorization, keeping policies in one place instead of scattering them as if statements through application code.

The multi-tenant case shows where ABAC becomes essential. A SaaS platform with ten thousand customer tenants can’t create roles per tenant; that’s role explosion by definition. A single ABAC rule, “a user may access a record only if record.tenant == subject.tenant,” enforces tenant isolation for all ten thousand at once, and keeps working for the ten-thousand-and-first with no change. That pattern quietly underpins a large share of the SaaS you use, and it can’t be expressed in pure RBAC. When people say ABAC scales, this is what they mean: the policy stays the same size as the number of subjects and resources grows without limit.

What ABAC costs

The costs are just as real. Governing attributes, as above, is the biggest. Auditability suffers because of the reverse-query problem. Reasoning gets harder, because a rich policy can have subtle interactions and it’s easy to write rules that overlap or contradict in ways nobody intended. Performance has to be engineered, since reading fresh attributes and evaluating policy on every request adds latency. And there’s a real risk of policy explosion, the ABAC counterpart of role explosion, where an unstructured heap of rules becomes as unmaintainable as an unstructured heap of roles. ABAC moves the complexity; it doesn’t abolish it.

ABAC doesn’t automatically escape the trap it was invented to solve. Role explosion came from encoding every condition as a new role; policy explosion comes from encoding every special case as a new rule, and an ABAC system with a thousand ad hoc, overlapping rules is no more governable than a thousand roles, arguably less, because rules interact in ways roles don’t. The way out is structure, not a different model: group rules by resource type, factor shared conditions into reusable predicates, name and assign an owner to each policy, and test the whole set. Organizations that succeed with ABAC treat policy as a designed, maintained codebase. Those that fail treat it as a place to bolt on exceptions until nobody can predict what it does.

So ABAC isn’t automatically more secure than RBAC. A complex policy nobody fully understands isn’t safer than a simple role model everyone does. The flexibility that lets you write a precise least-privilege rule also lets you write a sprawling, contradictory one whose behavior nobody can predict, and without testing, governance, and review tooling it can produce decisions that are wrong in ways much harder to see than an overly broad role.

ABAC is the engine of Zero Trust

If ABAC feels abstract, you’ve already met it under another name. The trust algorithm in Zero Trust, the logic inside the policy decision point that weighs identity, device posture, location, and risk on every request, is an attribute policy. “Grant access only if the user is authenticated, the device is compliant, the location isn’t unusual, and the risk score is low” is a rule over subject, environment, and resource attributes, evaluated continuously. Continuous adaptive trust is ABAC’s “re-read the attributes at request time” applied to a whole session: when a device falls out of compliance or risk jumps, the same policy that allowed access now denies it, with no administrator involved. Zero Trust is the strategy, and ABAC is the formal name for how its decisions are made.

Reading fresh attributes and evaluating a policy on every request sounds expensive, and done naively it is. A decision may need attributes from the token, a resource tag store, and a live risk feed, network hops that add latency to every action a user takes. Real ABAC systems engineer around this. Slow-changing attributes such as department and classification are cached with sensible lifetimes; attributes that must be current, such as risk and device posture, are read live or pushed as events. Decisions for identical repeated requests are sometimes cached, carefully, so a revocation isn’t ignored. And policy evaluation is kept close to the enforcement point to avoid round trips. These are the same trade-offs between latency and freshness you saw with sessions and token revocation. “Evaluate everything at request time” is a design commitment with a performance bill attached.

The hybrid: roles and attributes together

In practice “RBAC or ABAC” is a false choice; the mature answer is both, and the cleanest way to see it is that a role is just one subject attribute. Keep roles for the coarse, stable, auditable decision, “is this person a support agent at all?”, and layer attribute rules on for the conditional, dynamic part, “and is this the right region, ticket, and time?” You get RBAC’s legibility for the baseline and ABAC’s flexibility for the conditions, avoiding both role explosion and policy chaos. Notice that Sara’s rule already did this: its second line checks subject.role.

That’s exactly what the major platforms ship. AWS pairs IAM roles with condition keys and resource tags, so a role grants a class of action and conditions narrow it by matching tags, a pattern AWS itself calls attribute-based access control. In an IAM policy, the tag-matching idiom reads like an attribute comparison:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/region": "${aws:PrincipalTag/region}"
    }
  }
}

That statement says “allow reading any object whose region tag equals the principal’s own region tag,” one rule covering every region, exactly the ABAC move that would need a role per region under pure RBAC. Azure adds ABAC conditions to role assignments in the same spirit, and policy engines such as OPA and Cedar treat roles and attributes alike as inputs. The lesson of the last three articles is consistent: each model answers something the previous one couldn’t, and real systems combine them instead of crowning a winner.

The roadmap, solved, and the next edge

Return to Sara’s roadmap from the earlier articles. The rule that defeated RBAC, a support agent may read the roadmap only for their region, only while they hold an open ticket that refers to it, and only during working hours, is a single ABAC policy: match subject.region with resource.region, check the ticketOpen relationship, and test environment.time. It covers every agent and region, needs no per-region roles, and tightens automatically the moment a ticket closes or the working day ends, because the attributes are read again on the next request. The problem that forced role explosion is now one readable rule.

And a new edge appears right on cue. The rule leaned on ticketOpen(subject.id, resource.customer_id), a relationship between the subject and this specific resource. ABAC can use that as an attribute if something computes and supplies it, but expressing access mainly in terms of relationships between entities, “you can edit the document because you’re a member of the team that owns the folder it’s in,” is awkward to model as flat attributes and expensive to evaluate. That’s where relationship-based access control takes over. Each model hands over to the one that solves its leftover hard case.

Recap

Attribute-based access control makes access a function of context, evaluated at request time. Access follows the situation: policies decide from attributes of the subject, resource, action, and environment, as set out in NIST SP 800-162, read when the request happens, so access can depend on region, ownership, time, device, and risk. A policy is rules over attributes, and one rule covers every subject and resource, which is how ABAC expresses what RBAC would need a combinatorial number of roles for. Governing attributes is the real work, because the model is only as correct as its attributes’ sources, meanings, and freshness. Expressiveness has costs: the reverse-query problem makes “who can access this?” hard to answer, combining algorithms and defaults for missing attributes have to be understood, and policy explosion is a real failure. And the answer is a hybrid: a role is one attribute, and mature systems use roles for the coarse, auditable baseline and attribute rules for the dynamic conditions, as AWS and Azure both do.

Three questions to test yourself

1. Take the rule “a manager may approve an expense only for their own reports, only up to their approval limit, and only if the expense falls in an open reporting period.” Sort every condition into subject, resource, action, or environment attributes, and explain why RBAC alone can’t express it.
2. Your auditor asks, “Who can read customer records in the EU region?” Explain why this is easy under RBAC and hard under pure ABAC, name the problem, and describe two ways a real ABAC deployment makes the question answerable.
3. A team proposes replacing every role with attribute policies. Give two concrete advantages and two concrete risks, and make the case for a hybrid, including exactly which decisions you’d keep role-based and which you’d make attribute-based.

Hands-on exercises

1. Write a policy in pseudo-rules. Pick a real access rule from a system you know and write it as an ABAC rule, labeling the attribute category of each clause. Then identify, for each attribute, its authoritative source and how out of date it might be.
2. Find ABAC in your cloud. In AWS or Azure, find a policy that uses a condition: an IAM policy with a Condition block comparing tags, or an Azure role assignment with an ABAC condition. Read exactly which subject and resource attributes it compares, and predict how the decision changes if one tag is wrong.
3. Try the reverse query. For one attribute policy, try to answer “who can access resource X?” by hand. Notice that you have to enumerate subjects and conditions instead of reading a list. Sketch what a tool would need to do to answer it automatically; that’s the design problem the fine-grained authorization article picks up.