IAM Chapter 6, Part 2: Deciding at the Door

Part of the IAM study series.

Part 1 ended on the limit of the role: a rule decided at grant time is blind at access time. ABAC moves the decision to the door, but that creates new problems. Where do the facts come from, and who evaluates the rule? Every answer has a cost.

1. ABAC: The Rule, Not the Grant

ABAC (Attribute-Based Access Control) decides at access time by evaluating a rule against facts, rather than looking up a stored grant. RBAC stores access; ABAC stores rules and decides fresh every time.

Skyline's export rule, "a restricted drawing may be opened only by someone with current clearance, from an approved country, on a project they are assigned to", would need 1,600 roles. In ABAC it's one policy:

PERMIT read ON drawing
  WHEN  resource.classification == "export-restricted"
  AND   subject.clearance.validUntil > now
  AND   environment.country IN approvedCountries
  AND   resource.project IN subject.projects

Nothing in it names John. It describes a situation, and anyone whose facts match passes.

An attribute is a single fact with a label and a value, and there are four kinds: subject (clearance, project), resource (classification, owner), action (read, export), and environment (time, country, device). Only subject attributes live anywhere near the identity. A drawing's classification lives in PLM, which is why the engine must ask several different systems, not just the directory.

Standing access and just-in-time

Standing access exists all the time once granted, whether or not it's being used. Every role assignment is standing access. JIT (just-in-time) access doesn't exist until it's needed and expires on its own: John asks for engine drawings, gets four hours, and it disappears.

They combine well: a JIT grant can still be checked by policy.

What ABAC costs

Attribute quality becomes the whole system. A stale attribute gives a wrong answer with confidence, and the policy rarely gets the blame. You also lose enumerability: "what can John access?" now depends on where he is and when you ask. And "why was I denied?" has no simple answer.

Almost nobody runs pure ABAC. RBAC gives the baseline (broad, stable, auditable), and ABAC gives the conditions. The role decides whether John may be near wing drawings at all; the policy decides whether he may open this one, right now.

2. The Four Pieces

Picture the door of Skyline's restricted archive. You could hand every guard a copy of the rulebook, but then 200 apps enforce 200 versions of it. Better: the guard radios a control room.

You already own PEPs: an API gateway, a reverse proxy, a service mesh sidecar. And you've seen the split in OAuth, where the authorization server issues permission and the resource server enforces it. The difference is timing: OAuth decides at token issue, while a PDP decides at the moment of access.

PIP. The PDP reads facts rather than storing its own copy, or it ends up with two versions of the truth. Each fact has one owner: clearance in HR, classification in PLM, device in endpoint management. Every PIP is a live dependency, so the policy answers only as well as its slowest, least accurate source. ABAC projects usually fail on the unglamorous question of who owns each attribute's freshness.

PAP. The business owns the rule, and IT runs the engine. If the control room could edit its own rulebook, operators could grant themselves anything and the audit log would look clean. Separate the two, and keep policy in version control with review and test cases. Decision-makers can't write Rego, so someone has to translate the intent, and testing against real scenarios with the business in the room is the only thing that catches a bad translation.

Standards and products: XACML defined this vocabulary, OPA (Rego), AWS Cedar, and OpenFGA are the modern engines, and Entra ID Conditional Access is a PDP for sign-in.

3. What the Architecture Costs

• Latency. Every access is now a network call, sometimes several. Mitigate by caching the decision, or by running a local PDP next to the PEP.
• Availability. If the control room doesn't answer, the guard must choose. Fail closed stays secure but stops work; fail open stays available and can leak export-controlled data. Decide per policy, before go-live, not during the outage.
• Freshness. Export control revokes John's clearance at 09:00, and the PDP has a 30-second cache. For up to 30 seconds he can still open restricted drawings, and every one is logged as a legitimate permit.

These trade against each other. Every fix for latency makes freshness worse, so you pick where to sit on that line and write down the number.

🔴 CHECKPOINT: Study Notes

← Previous: Who May Do What · Back to the series start · Next: The Whole Machine →