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 a UI can use 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 they adopt a policy engine, the challenge is adapting existing systems without breaking the workflows people already depend on.
ACME Corporation faced this problem when it transformed its internal Customer Collaboration platform into a commercial SaaS product: the Customer Collaboration Cloud (C³). The original system let engineers and account managers share project documents with trusted customers, but its authorization logic had grown organically. Some rules lived in controllers, others in stored procedures or service endpoints. Each team implemented its own version of who-can-see-what, and adding a new rule meant changing the application code in several places.