Advanced20 min

Policy Enforcement

Where the yes/no decision is made — PEP, PDP, and models like RBAC, ABAC, and ReBAC.

By the end of this lesson, design where and how authorization decisions are made and keep them consistent and auditable.

How deep?

How the pieces actually move.

Authorization is a decision: given a subject, an action, and a resource (plus context), is it allowed? The architecture separates the Policy Enforcement Point (PEP) — the code path that intercepts the request — from the Policy Decision Point (PDP) — the component that evaluates policy and answers yes/no.

First, the whole system

First, see the whole system. Then we’ll open it up.

PEP asks, PDP decides

The enforcement point intercepts the request and asks the decision point, passing subject, action, resource, and context.
The decision point returns permit or deny; the enforcement point allows or blocks.

flowchart LR
  req[Request] --> pep[PEP: enforcement point]
  pep -->|subject, action, resource, context| pdp[PDP: decision point]
  pdp -->|permit / deny| pep
  pep -->|permit| resource[Resource]
  pep -->|deny| block[403]

RBAC / ABAC / ReBAC: RBAC: permissions via roles. ABAC: decisions from attributes of subject/resource/context. ReBAC: decisions from relationships in a graph (e.g., 'is owner of', 'is member of team that owns'), as in Google Zanzibar.

Abstraction leak

This is where the abstraction starts leaking.

Authorization logic scattered as if (user.role === 'admin') across services is unmaintainable and drifts instantly. The moment you have more than a couple of services, you need policy as a first-class, centrally-defined thing — or every service will disagree about who can do what.

Stale authorization decision

Trigger: A revoked role or permission is still honored because a cached decision or token hasn't refreshed.
Symptom: A user keeps access after their permission was removed.
Blast radius: Continued access to resources during the staleness window.
Mitigation: Short decision-cache TTLs, revocation events, and re-evaluation on sensitive actions.

Deep dive: Stale Authorization

Consistency

Central PDP: consistent, auditable, but a hot dependency and a latency hop. Embedded/cached policy: fast and resilient, but risks divergence and staleness. Most enterprises centralize policy authoring and distribute a cached decision engine.

How it connects

Which model best expresses 'a user can edit a doc if they belong to a team that owns the doc'?

ReBAC — it's a relationship traversal in a graph, exactly what relationship-based access control is designed for.