IDSync — identity software buyer platform
Run Stack Finder

Authorization

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) decides whether a user can take an action by evaluating attributes of the user, the resource, the action, and the environment against a policy — instead of relying solely on group or role membership.

Last reviewed 5/30/2026

Key points

  • ABAC evaluates attributes at request time (user.department, resource.classification, time, IP, device posture).
  • Policies are typically expressed as rules or in a policy language (Rego/OPA, Cedar, XACML).
  • ABAC scales better than RBAC for fine-grained, context-aware access — but is harder to audit if policies aren't centralized.
  • Modern implementations: AWS IAM conditions, Google Cloud IAM conditions, Open Policy Agent (OPA), Amazon Verified Permissions (Cedar), Permit.io, Oso, Styra.
  • Most real systems are hybrid: RBAC for coarse-grained roles, ABAC for conditions that refine those roles.

What is ABAC?

Attribute-Based Access Control (ABAC) makes access decisions by evaluating attributes — properties of the user (department, clearance, manager), the resource (owner, classification, project), the action (read, write, delete), and the environment (time of day, network, device posture) — against a policy.

Where RBAC says "members of the 'Finance' role can read invoices," ABAC says "users whose 'department' = 'Finance' AND 'clearance' >= 'Confidential' can read invoices owned by their cost center, from a managed device, during business hours."

How it works

A standard ABAC request flows through four logical components (originally from XACML, but the pattern is universal):

  1. PEP (Policy Enforcement Point) — the app/proxy/sidecar that intercepts the request.
  2. PDP (Policy Decision Point) — evaluates the policy against the input.
  3. PIP (Policy Information Point) — fetches missing attributes (HR data, device posture, resource metadata).
  4. PAP (Policy Administration Point) — where humans author and version policies.

Modern stacks usually collapse this into a policy engine like Open Policy Agent (Rego), Cedar (AWS / Permit.io), or Oso Cloud, with attributes pushed in as JSON.

When buyers care

  • Fine-grained, multi-tenant SaaS — "user X can edit document Y if they're in workspace W and the doc isn't locked."
  • Data access governance — column- and row-level policies in Snowflake, Databricks, BigQuery.
  • Cloud infrastructure — AWS IAM conditions, Google Cloud IAM conditions, and CIEM tools all rely on attributes.
  • Compliance — separation of duties, least privilege, and "need to know" map naturally to attribute rules.

Common misconceptions

  • "ABAC replaces RBAC." Almost never. Real systems use RBAC for the coarse layer and ABAC for the conditional refinements.
  • "ABAC is just IF statements in code." Hardcoding attribute checks in app code is the anti-pattern ABAC is meant to fix — externalize policy into a dedicated engine so security can audit and update it without redeploying.
  • "Attributes always come from the IdP." They come from anywhere: HRIS, CMDB, device management, the resource itself.

ABAC vs RBAC vs ReBAC

| Model | Decision unit | Best for | | --- | --- | --- | | RBAC | Role → permission | Workforce apps, predictable job functions | | ABAC | Attributes + policy | Context-aware access, regulated data, cloud IAM | | ReBAC | Relationships in a graph | Multi-tenant SaaS, document/file sharing (Google Docs model) |

Editorial note

If a vendor pitches ABAC, ask where policies live, how attributes are fetched at decision time, and what the latency budget is. A great policy engine that takes 300ms to answer is unusable on a hot API path.

Standards & references