infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-policy-decision-point-policy-enforcement-point.md

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.