Security
Part 3 of 6 · AuthorizationABAC — Attributes, Policies, PDP & PEP
Attribute-based policies with PDP/PEP separation for env and resource attributes.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
One policy vs a role per condition
Prefer
Attributes in a shared PDP
Clearance, region, and risk are inputs. One export policy covers the matrix you would otherwise encode as role names.
- Subject, resource, action, and environment stay explicit.
- Many services call the same decision function.
- Missing or stale attributes deny. They do not default to allow.
Alternative
editor_after_hours_eu as a role
Every new condition mints a role. The check is still a string compare, and the environment is frozen into the name.
- Role explosion from the previous lesson, with a longer name.
- Policy bugs hide in scattered if statements.
- A stale department claim looks like a fresh decision.
PEP calls PDP
The middleware does not contain the rule. It builds context and obeys the answer.
- 1
Request hits the PEP
Gateway plugin, service middleware, or the data-access layer. Pick at least the service for anything instance-specific. - 2
Assemble attributes
Subject from the already-established identity. Resource from metadata. Action from a verb catalog. Environment from the edge. - 3
PIP fills gaps
A policy information point may fetch HR or inventory. If it fails, do not evaluate on a hole. - 4
PDP returns an effect
Allow, deny, or error. Allow can carry obligations: mask a field, step-up, extra audit. - 5
PEP enforces
Continue only on allow, and actually perform the obligations. Error and deny both fail closed.
Overview
Attribute-based access control decides allow or deny from attributes of the subject, the resource, the action, and the environment. A PDP evaluates. A PEP enforces. One policy can replace a pile of brittle roles such as "editor, after hours, in the EU."
The cost is attribute quality, policy complexity, and a written failure mode when the PDP is unreachable. Interviews like this split because it forces enforcement and decision apart. Production likes it when compliance says "only matching region and clearance, and only under a risk threshold" without a role per country and hour.
Identity issuance remains in OAuth & OIDC. ABAC consumes the subject id and claims as attributes. It does not re-issue them.
Attribute categories
| Category | Examples | Notes |
|---|---|---|
| Subject | sub, roles, clearance, department, tenant ids | From the identity layer; keep them fresh |
| Resource | owner_id, classification, region, type | From the database or a metadata service |
| Action | read, export, approve | Normalize a verb catalog |
| Environment | IP, time, device posture, risk score | Often from gateway context |
Bad attributes produce bad AuthZ. A stale department claim is a common breach path. Long-lived credentials that freeze attributes have the same bug: the decision is only as fresh as the claim. Refresh and revoke stay on the identity cluster; this page only refuses to treat a stale claim as truth.
Flow
- 1
1. Request hits the PEP
- next2. Build attribute context
- 2
2. Build attribute context
- next3. PEP calls the PDP
- 3
3. PEP calls the PDP
- next4. Evaluate policies
- 4
4. Evaluate policies
- next5. Allow plus obligations
- next6. Deny or PDP error
- 5
5. Allow plus obligations
- 6
6. Deny or PDP error
- next7. Fail closed
- 7
7. Fail closed
Lesson map
ABAC — Attributes, Policies, PDP & PEP
Attribute-based policies with PDP/PEP separation for env and resource attributes.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["1. Request hits the PEP"] b["2. Build attribute context"] c["3. PEP calls the PDP"] d["4. Evaluate policies"] a -->|1. Request hits the PEP| b b -->|2. Build attribute context| c c -->|3. PEP calls the PDP| d
- PEP — API middleware, a gateway plugin, or the data-access layer.
- PDP — OPA, a Cedar engine, a small in-process evaluator, or cloud IAM.
- PIP — optional policy information point that fetches attributes the request did not carry.
- Obligation — "allow but mask," "allow and audit harder," "allow only after step-up." The PEP implements it. Ignoring an obligation is an allow you did not decide.
Where ABAC sits next to other models
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| RBAC only | Simple audits of personas | Coarse; explosion | Stable job functions |
| ABAC policies | Expressive and centralized | Policy bugs; freshness | Dynamic conditions |
| Hard-coded conditionals | Fast to ship | Scattered, untestable, drift | Prototypes you plan to delete |
| RBAC plus ABAC | Roles remain readable subject attributes | You must say which layer wins | Most real systems |
Roles fit ABAC as subject attributes: roles contains editor. ABAC can subsume RBAC. Many systems keep the role catalog as the readable layer and put conditions in policy.
Sketch, not a language yet: allow export when subject clearance dominates resource classification, regions match, and risk is under the threshold. Otherwise deny. Default deny is mandatory. Language choice is the policy engines lesson.
Sandbox: a tiny PDP and the PEP that calls it
Any matching policy allows. No match denies. A thrown attribute error denies. That last branch is the production one people forget.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
The second call is a region mismatch. The PEP returns 403. It does not "continue and let the query filter later" unless that filter is an explicit, tested obligation.
Interview Q&A
Define ABAC.
Answer
Authorization where policies evaluate attributes of subject, resource, action, and environment to produce allow or deny, plus optional obligations.
PEP vs PDP?
Answer
The PEP enforces on the request path. The PDP decides. Separating them lets many services share one policy and one test suite. A PIP, if you have one, only fetches attributes.
What breaks ABAC in production?
Answer
Stale or missing attributes, inconsistent names across services (dept versus department), PDP latency without a fail-closed plan, and policy changes nobody reviewed.
How do roles fit ABAC?
Answer
Roles become subject attributes. A policy can say the roles include editor and the resource owner matches. You do not need a second hard-coded ladder beside the policy.
What is an obligation?
Answer
A side requirement attached to an allow: mask fields, step-up, extra audit. The PEP must perform it. Dropping it on the floor is a different decision than the one the PDP returned.
Default allow or deny?
Answer
Default deny. Explicit allows only. Fail closed on PDP errors and on incomplete context for sensitive paths. A cached decision needs a policy version in the key; that mechanic is on the enforcement page.
ABAC vs ReBAC?
Answer
ABAC fits properties and environment. ReBAC fits a path in a relationship graph. Hybrids are normal: a tuple check, then an attribute constraint such as region or time.
What is a PIP for?
Answer
The request rarely carries every attribute you need. A policy information point loads department, device posture, or classification. If that lookup fails, the PDP should not treat the missing key as "no constraint."
Why do attribute keys need a catalog?
Answer
Two services that spell department differently evaluate different policies while operators think they shipped one rule. The catalog is the schema for decisions, the same way a permission catalog is the schema for RBAC.
Pitfalls
One sentence for allow: clearance, region, and risk. Then list the three denies: risk too high, region mismatch, and a missing risk attribute. Say what the PEP does with an "allow and mask" obligation if the handler only knows 200 and 403.