13 Using policy engines with existing systems

ACME’s Customer Collaboration platform started as an internal tool with authorization logic scattered across controllers, stored procedures, and service endpoints. As the company turned it into the multi-tenant Customer Collaboration Cloud, the old project-ID-based boundary was no longer enough: the system needed tenant isolation, federated identity, auditable decisions, and customer-specific customization without sacrificing ACME’s global controls. The chapter shows that adopting a policy engine is a gradual transformation, not a big-bang replacement, and that the core idea is to move decisions out of application code while preserving existing collaboration behavior.

The platform keeps its relationship-based access model for sharing documents, but surrounds it with a broader authorization architecture. A platform layer enforces ACME-wide rules such as tenant separation, data residency, support constraints, and device requirements for employees, while tenant-level policies continue to govern who can view, edit, share, or administer resources inside each tenant’s workspace. Identity and tenancy are formalized through tenant IDs, OIDC-based customer authentication, and separate treatment of ACME-managed employees versus tenant-managed users, with dynamic facts fetched at evaluation time rather than baked into tokens.

To make this work in existing systems, ACME inserts policy enforcement points at multiple places: the gateway for early rejection and global checks, services for fine-grained resource-aware decisions, and the UI for better visibility and usability. These enforcement points share a common schema, request-building logic, logging format, and policy life cycle so that decisions stay consistent, testable, and auditable across the stack. The chapter closes by showing how layered policies, partial evaluation for discovery queries, controlled tenant templates, and strict precedence rules let ACME offer flexibility to customers while keeping platform governance intact.

Evolution of the Customer Collaboration platform. The internal Customer Collaboration Platform (top) is compared with the multi-tenant Customer Collaboration Cloud (C³) (bottom).

C³ authorization flow through global and tenant PEP/PDP layers

Concentric policy layers in the C³ authorization model. Policies in C³ are organized by scope rather than hierarchy. System policies form the outermost layer, overseeing the entire platform and its automation. Inside this layer, application policies govern the Customer Collaboration Cloud service itself, managing multi-tenant governance, data residency, and compliance. At the core, tenant policies handle collaboration within each tenant’s workspace using ReBAC and approved templates.

• Converting an internal application into a multi-tenant service requires rethinking authorization boundaries and data isolation.
• A layered authorization model, including system, application, and tenant layers, clarifies ownership and separates trust domains.
• A consistent identity and tenancy foundation supports policy evaluation across both federated and hosted tenants.
• Requests pass through global and tenant PEP/PDP pairs, following the PARC model from enforcement to decision.
• Policy enforcement points can operate at different levels, such as gateway, service, and UI, with each enhancing security and usability.
• The UI uses graph traversal, partial evaluation, and batch PDP checks to efficiently address visibility questions.
• A layered policy architecture and template system enable tenants to customize collaboration securely within shared constraints.
• ACME’s internal case studies show the effectiveness of layered authorization in real-world operations.
• An integration checklist now guides new systems joining ACME’s policy engine architecture.

FAQ