Externalized authorization keeps access-decision logic and supporting identity information outside the protected application. Instead of duplicating checks across controllers, stored procedures, and services, applications evaluate shared policies through policy decision points (PDPs), then enforce results near protected resources. section 13.0
A practical design separates concerns across layers. Platform policies enforce global requirements such as tenant isolation, device posture, residency, and operational authority; tenant policies govern collaboration, often using relationship-based access control (ReBAC). Policy enforcement points (PEPs) gather and normalize identity signals, PDPs evaluate policies, and shared schemas and logs connect decisions across the system. section 13.0 section 13.6.5
Adoption works as an incremental integration practice:
- Map system, application, and tenant boundaries before assigning policy ownership. section 13.7
- Standardize principals, tenants, resources, and signals so every PDP reasons about the same entities. section 13.7
- Move allow/deny decisions from application code into policies, then place PEPs at gateways and services. section 13.7
- Keep credential verification in trust stores and signal platforms; send normalized attributes to policies instead of issuer-specific formats. section 16.6.2
Sensitive-document access
A policy permits viewing a sensitive document only when the principal has the required certification, its issuer belongs to the trusted certification bodies, and the credential remains unexpired. Adding an accredited issuer changes trust-store mappings rather than access policies. section 16.6.2
Table 13.4 Integration checklist for adopting a policy engine
| Step |
What to establish |
Why it matters |
|---|---|---|
| 1. Map boundaries. |
Identify system, application, and tenant scopes. |
Clarifies which policies run where and who owns them |
| 2. Define the identity model. |
Standardize how principals, tenants, and resources are represented. |
Ensures every PDP can reason over the same entities |
| 3. Externalize decisions. |
Move allow/deny logic from code to policy evaluation. |
Enables consistency and auditability |
| 4. Place enforcement points. |
Insert PEPs at gateways, services, and (optionally) the UI. |
Keeps policy evaluation close to data while preserving performance |
| 5. Establish the schema. |
Create a shared Cedar schema for all policy layers. |
Guarantees type safety and cross-layer compatibility |
| 6. Support partial evaluation. |
Precompute scopes for fast UI search and discovery. |
Improves responsiveness without compromising correctness |
| 7. Implement logging and versioning. |
Record every decision, and track policy versions. |
Enables rollback, audit, and long-term governance |
Use the integration checklist to sequence boundary mapping, identity modeling, decision externalization, enforcement placement, schema design, and partial evaluation. section 13.7
