When authorization logic is embedded in applications, duplication makes updates slow and inconsistent. Policy management externalizes authorization rules as precise, reviewable code that systems can enforce reliably. section 10.0
Treat policy as a controlled lifecycle rather than a collection of static access rules:
- Create and author policies in a policy administration point, with clear ownership and review responsibilities. section 14.9
- Review and approve changes, recording design reasoning in architectural decision records for traceability. section 14.9
- Deploy versioned policies to decision points, then monitor, update, and retire them in a controlled, auditable workflow. section 14.9 section 4.5.3
- Support rollback and operational response when incidents, audits, or system changes require policy adaptation. section 10.0 section 14.9
Versioned distribution to local decision points
A central authoring point distributes versioned policies to local policy decision points deployed in an API gateway, application library, or sidecar. Local clients evaluate requests with cached identity and resource attributes, reducing latency while making synchronization and cache freshness operational responsibilities. section 4.5.3
Figure 4.7 Distributed authorization architecture at ACME Corp. Each service includes an authorization client, a bundled component that contains the PEP, PDP, and an entity cache. The client may be deployed as a sidecar (ACMEFinance), as a library within application code (ACMEProject), or integrated into an API gateway (ACMEHR). Policies are authored and managed by Carol via the Policy Administration Point (PAP) and then distributed to each client. Contextual data is retrieved from shared PIPs, such as identity stores, time servers, and network telemetry, and is cached inside the client.
Use the architecture diagram to compare gateway, library, and sidecar deployment models and trace policy and contextual-data distribution. section 4.5.3
