13 Using policy engines with existing systems
This chapter covers
- The evolution of ACME’s internal Customer Collaboration platform into the multi-tenant Customer Collaboration Cloud (C³)
- How a multi-layer authorization model differentiates between platform and tenant responsibilities
- Patterns for deploying policy enforcement points at the gateway, service, and UI levels.
- How the UI uses graph queries and partial evaluation to answer “who or what can access?” questions
- Using a multi-layered policy architecture to allow secure tenant customization
Authorization rarely starts from scratch. Most organizations already have applications, APIs, and data services with authorization embedded in their code or configuration. When organizations adopt a policy engine, the focus isn’t on how to start but rather on how to adapt without disrupting existing functions. Integration, rather than invention, presents the true challenge.
13.1 From internal tool to external service: ACME’s next chapter
13.2 Understanding the starting point
13.3 Identity and tenancy foundation for C³
13.3.1 From project IDs to tenants
13.3.2 Unified customer identity via OIDC
13.3.3 Device posture for ACME employees
13.4 Designing for externalized authorization
13.4.1 Platform and tenant PDPs
13.4.2 Deployment options for tenant PDPs
13.4.3 Authorization flow request
13.5 Policy enforcement points in the stack
13.5.1 Global enforcement: the ACME Gateway
13.5.2 Tenant-level enforcement: collaboration services
13.5.3 UI and client-side enforcement
13.5.4 Consistency through shared components
13.5.5 Operational trade-offs
13.5.6 Three layers of policy
13.5.7 Shared schema and type safety
13.5.8 Policy lifecycle and distribution
13.5.9 Governance and safety
13.5.10 Benefits of the layered model
13.6 Case studies inside ACME
13.6.1 Case 1: Cross-tenant legal review
13.6.2 Case 2: Support escalation
13.6.3 Case 3: Custom collaboration template
13.6.4 Case 4: Automated backup verification