What is ABAC in one sentence?

ABAC is an authorization model that allows or denies each request by evaluating a policy against attributes of the user, the resource, the action, and the environment, rather than against a fixed role.

How is ABAC different from RBAC?

RBAC grants access from a user's role. ABAC grants access from attributes evaluated at request time, so one policy can express rules like 'editors can edit documents in their own department during business hours' without minting a role per case.

What is a policy decision point?

A policy decision point, or PDP, is the component that evaluates the ABAC policy and returns allow or deny. The policy enforcement point, or PEP, sits in front of the resource and actually blocks or permits the request based on that decision.

XACML is an OASIS standard for expressing attribute-based access policies in XML, along with a reference architecture of decision, enforcement, and information points. Newer engines often use lighter languages like Rego instead.

Is ABAC better than RBAC?

Neither is strictly better. ABAC is more expressive and avoids role explosion, but policies are harder to audit and reason about. Many real systems use RBAC for coarse access and ABAC for the fine-grained, data-dependent rules.

Glossary · Security

What is Attribute-Based Access Control (ABAC)?

ABAC is an authorization model that decides every request by running a policy over attributes — who the user is, what the resource is, what action they want, and the surrounding context like time or location. Instead of asking "what role does this person have," it asks "do this user's attributes, this resource's attributes, and this moment's context satisfy the rule?"

Why it exists

Role-based access control is clean and auditable, but it struggles the moment access depends on data rather than job title. "A nurse can view a chart, but only for patients on their own ward" is awkward to express as roles — you would need a role per ward, then per shift, then per combination, and the catalog explodes. The US National Institute of Standards and Technology published SP 800-162 in 2014 to define ABAC precisely as the answer: model the rule directly, in terms of attributes, and let a policy engine evaluate it fresh on every request.

The four attribute categories

Every ABAC policy draws on four kinds of attributes. Subject attributes describe the user — department, clearance, employment status. Resource attributes describe the thing being accessed — owner, classification, project. Action attributes describe what is being attempted — read, write, delete, export. Environment attributes describe the context — time of day, source network, device posture, threat level. A policy is just a boolean expression over these four sets, and the engine returns allow or deny by evaluating it against the specific request in front of it.

Decision and enforcement points

ABAC's reference architecture separates the decision from the enforcement. The policy enforcement point sits in front of the resource and intercepts every request. It hands the request to a policy decision point, which gathers the relevant attributes from a policy information point, evaluates the policy, and returns allow or deny. Keeping the decision logic in one engine — rather than scattered across application code — is what makes ABAC powerful and what makes it hard: one wrong policy can silently open or close access everywhere at once.

ABAC vs RBAC, honestly

ABAC is strictly more expressive than RBAC — you can model a role as "user has attribute role=X," but you cannot model an arbitrary attribute rule as a role without explosion. The trade-off is auditability. With RBAC you can look at a role and know exactly what it permits; with ABAC, answering "who can access this record" may require evaluating policies against the entire attribute space. That is why most production systems are hybrids: RBAC for the coarse, stable buckets, and ABAC layered on top for the fine-grained, data-dependent rules that would otherwise cause role explosion.

At QUANT LAB

When a product's access rules genuinely depend on data — regional ownership, document classification, tenant boundaries — we reach for attribute-based policies rather than fighting role explosion. In our SaaS platform builds that often means a central policy engine evaluating tenant and ownership attributes on every request, wired into the same identity and access management layer. It also pairs naturally with a zero trust model, where device posture and context are first-class inputs to every authorization decision.

Making ABAC maintainable

ABAC's failure mode is policy sprawl: hundreds of rules that nobody fully understands, with subtle overlaps that allow or deny more than intended. The discipline that keeps it sane is treating policy as code — version-controlled, peer-reviewed, and tested against a suite of allow and deny cases before it ships. Keep the attribute vocabulary small and well-defined, prefer deny-by-default, and write automated tests that assert specific people can and cannot reach specific resources. Without that rigor, ABAC trades role explosion for an equally unmanageable policy explosion.

Long-form deep-dives that use this term

All posts

Related terms

Authorization rules getting complicated?

We design attribute-based policy engines for data-dependent access and test that they hold under pressure. Book a 30-minute call.

SaaS platform development