generated from coulomb/repo-seed
47 lines
1.4 KiB
Markdown
47 lines
1.4 KiB
Markdown
# Pattern: Policy Decision Point / Policy Enforcement Point
|
|
|
|
Status: reviewed
|
|
Readiness target: RL3 production
|
|
Primary owners: flex-auth, NetKingdom
|
|
Genesis family: Identity and access
|
|
|
|
## Problem
|
|
|
|
Authorization becomes inconsistent when policy decisions live inside
|
|
many applications without a shared decision contract.
|
|
|
|
## Context
|
|
|
|
Use this pattern when product services, platform APIs, object-storage
|
|
brokers, admin tools, and agents need consistent allow or deny decisions
|
|
for protected resources.
|
|
|
|
## Forces
|
|
|
|
- Applications must enforce decisions at local boundaries.
|
|
- Policy needs central shape, testability, and audit.
|
|
- Tenant, resource, action, assurance, and context must be included.
|
|
- PDP outages must not become implicit allow.
|
|
|
|
## Solution
|
|
|
|
Separate policy decision from policy enforcement. flex-auth acts as the
|
|
canonical PDP boundary and may delegate to Topaz; applications and
|
|
gateways act as PEPs that enforce allow, deny, obligations, and reason
|
|
codes.
|
|
|
|
## Verification
|
|
|
|
- Decision requests include actor, tenant, resource, action, assurance,
|
|
and context.
|
|
- PEPs deny on explicit deny, malformed decision, or PDP outage.
|
|
- Decisions produce stable reason codes and audit correlation ids.
|
|
- Policy packages are tested before production use.
|
|
|
|
## Related Patterns
|
|
|
|
- Delegated Authorization.
|
|
- Role Composition.
|
|
- Object-Level Authorization Check.
|
|
- Policy-as-Code Admission Control.
|