Fine-grained authorization isn’t just “which model do we like?” It’s an architecture question:
- Where does the decision happen? (Policy Decision Point — PDP)
- Where is it enforced? (Policy Enforcement Point — PEP)
- How do we keep decisions consistent across many services?
The canonical pattern
PDP (Policy Decision Point)
A PDP evaluates:
- Subject (who/what): user, workload identity, agent
- Object (what): resource and its identifiers
- Action:
read,write,approve,admin - Context: tenant, device posture, risk, network, time
…and returns allow/deny (often with obligations: “step-up MFA”, “mask fields”, etc.).
PEP (Policy Enforcement Point)
A PEP sits where requests flow:
- API gateway
- Service middleware
- Sidecar proxy
- Data access layer
It gathers inputs, calls the PDP (or evaluates locally), and enforces the result.
Common deployment shapes
1) Library-based enforcement (in each service)
Pros: low latency, local context.
Cons: policy drift, duplicated logic, hard to audit.
2) Centralized PDP service
Pros: consistent policy, centralized logging and testing.
Cons: PDP becomes critical infrastructure; needs caching and resilience.
3) Sidecar / service mesh enforcement
Pros: consistent enforcement layer, less app code.
Cons: still need to model resources correctly; can be opaque to developers.
Practical guidance
- Treat the PDP like an IdP: it needs HA, SLOs, monitoring, and change control.
- Prefer small, typed inputs: stable resource IDs + action names.
- Define obligations explicitly (step-up, approvals, redaction).
Pitfalls
- Making PDP calls synchronous with no caching (latency + outages become auth outages).
- Stuffing business logic into policy (hard to test and version).
- No story for “break glass” or incident response.
Where to go next
- /topic/authorization/fine-grained-authorization-zanzibar
- /category/identity-security
- IDPro Book of Knowledge (reference): https://bok.idpro.org/