ABAC Authorization Model: Mermaid Flowchart

ABAC Authorization Model flowchart diagram

About Source

Attribute-Based Access Control (ABAC) is an authorization model that makes access decisions by evaluating policies against the attributes of the subject (user), the resource being accessed, and the environment (context). Where RBAC Authorization Model asks "does this role have this permission?", ABAC asks "given all relevant attributes, does this policy allow this action?"

ABAC centers on four attribute categories. Subject attributes describe the requester: user.role, user.department, user.clearance_level, user.location. Resource attributes describe the object being accessed: document.owner, document.classification, document.department, document.status. Action attributes describe what's being done: read, write, delete, approve. Environment attributes describe contextual conditions: time.hour, request.ip, request.mfa_verified.

A policy is a boolean expression over these attributes. For example: "A user can write a document if user.department == document.department AND document.status != 'published'." Or: "A user can approve a budget if user.role == 'manager' AND document.amount < user.approval_limit AND time.hour is between 9 and 17."

The policy engine (often called a PDP — Policy Decision Point) receives an authorization request containing the attributes, evaluates all applicable policies, and returns permit or deny. The enforcing component (the PEP — Policy Enforcement Point, your API middleware) acts on that decision.

ABAC's power is its expressiveness and its ability to handle fine-grained, context-sensitive rules. The cost is complexity: policies can be hard to audit and debug, and every access decision requires evaluating potentially many attributes. Many systems use a hybrid approach — RBAC for coarse-grained role checks, ABAC-style policy rules for ownership and contextual constraints. The runtime decision process is shown in Access Control Decision Flow.

Frequently asked questions

ABAC is an authorization model where access decisions are made by evaluating policies against the attributes of the subject (user), the resource being accessed, and the environment (context). Rather than "does this role have this permission?", ABAC asks "given all relevant attributes, does this policy allow this action?" — enabling fine-grained, context-aware authorization rules.

The Policy Enforcement Point (PEP) — typically API middleware — intercepts each request and collects subject, resource, and environment attributes. It forwards these to the Policy Decision Point (PDP), which evaluates all applicable policies and returns `permit` or `deny`. The PEP enforces that decision by allowing or rejecting the request. The PDP may be an in-process library or a dedicated external service.

ABAC can express ownership rules ("users can edit their own documents"), time-of-day restrictions ("approvals only allowed 09:00–17:00"), value-based rules ("managers can approve expenses up to their approval limit"), and cross-attribute comparisons ("users can access documents in their own department"). These contextual conditions cannot be expressed as static role-permission mappings.

Policy management complexity is the main challenge: with many attributes and policies, it becomes hard to predict the outcome of any given request and to audit who can do what. Policy testing and debugging require dedicated tooling. Performance can also be a concern if the PDP must evaluate many policies per request. Most teams mitigate this by starting with RBAC and layering ABAC rules only where the additional expressiveness is needed.

ABAC is an authorization model concept; Open Policy Agent (OPA) is a concrete policy-as-code engine that implements ABAC-style evaluation using the Rego language. OPA separates policy definition from application logic, allows policies to be tested and version-controlled independently, and can serve authorization decisions as a sidecar or external service. It is the most common way to implement ABAC in modern cloud-native applications.

mermaid

flowchart TD
    REQ([Access Request]) --> PEP[Policy Enforcement Point]
    PEP --> COLLECT[Collect attributes]

    COLLECT --> SA[Subject Attributes\nuser.role, user.dept\nuser.clearance]
    COLLECT --> RA[Resource Attributes\ndoc.owner, doc.classification\ndoc.status]
    COLLECT --> AA[Action: read / write / delete]
    COLLECT --> EA[Environment Attributes\ntime.hour, request.ip\nmfa_verified]

    SA --> PDP[Policy Decision Point]
    RA --> PDP
    AA --> PDP
    EA --> PDP

    PDP --> PE[Evaluate applicable policies]
    PE --> RESULT{Decision}
    RESULT -- Permit --> ALLOW([Allow access to resource])
    RESULT -- Deny --> DENY([403 Forbidden])
    RESULT -- Not applicable --> DEFAULT{Default policy}
    DEFAULT -- Deny by default --> DENY