Layered policy architecture

As explained in Authorization in Action

Layered authorization is an approach in which multiple domains or system components independently enforce their own policies.

Layered policy architecture organizes authorization policies by scope, ownership, and trust boundary. Rather than giving one team or component unrestricted authority, it lets platform, organizational, application, tenant, or resource domains enforce policies appropriate to their responsibilities. A request must satisfy the relevant layers, so local flexibility does not override broader security or governance constraints. section 13.5.6 section 4.7

A common division uses system policies for platform automation and operations, application or global policies for service-wide requirements such as tenant isolation and data residency, and tenant policies for collaboration inside an approved namespace. The layers are organized by scope, not simply as a chain of increasingly specific permissions. section 13.5.6

Figure 13.3 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.

The concentric view shows how system, application, and tenant policies occupy distinct scopes while protecting one shared platform. section 13.5.6

A layered design needs explicit rules for combining and operating policies:

• Assign each layer a clear owner. Platform and identity teams can govern system-wide constraints, while product teams or tenants control only their permitted domain. section 13.5.6
• Evaluate applicable policies as an effective policy set using shared request data. PDPs make decisions and PEPs enforce them near protected resources. section 13.6.5 section 15.4
• Define conflict semantics. With forbid-overrides-permit, a foundational security restriction defeats an application-level permit and missing required context fails closed. section 15.3.4
• Test interactions, not just isolated rules. A device-posture or authentication-freshness requirement can change the result of otherwise valid operational or application policies. section 15.4

Tenant collaboration within platform controls

A platform PDP first rejects requests that violate tenant isolation, routing, data residency, device compliance, or support-access rules. Only then does a tenant PDP apply relationship-based collaboration rules to decide whether someone may view, edit, share, or administer resources in that tenant. Tenant templates enable customization without granting authority over the platform boundary. section 13.4.1 section 13.6.5

The same pattern applies beyond multi-tenant services. Enterprise-wide security requirements, shared operational rules, and service-specific policies can be evaluated together for zero-trust access decisions. Across domains, a downstream finance system, database, or file server still enforces its own policy even when an upstream agent or mesh has already made a decision. section 15.4 section 18.7

Operationally, externalized policies, shared schemas, and decision logs make authority traceable across gateways, services, PDPs, and policy versions. The architecture reduces duplicated access logic and policy drift while preserving clear accountability at each boundary. section 13.6.5 section 15.4

How Authorization in Action covers it

How deep it goes

Explains ownership, scopes, PDP/PEP evaluation, conflict semantics, and interaction testing rather than policy-language internals.

Examples

Uses system, application, and tenant policies for backups, compliant support access, and verified-domain sharing.

What it assumes

Assumes authentication evidence for authorization decisions and introduces policy layers through concrete access scopes.

What you can do after

Design layered authorization with bounded customization, explicit overrides, shared evaluation data, and cross-layer tests.

How it connects

Connects authorization with PDPs, PEPs, zero trust, ABAC, ReBAC, tenant isolation, and policy templates.

liveBookmanning.com

Read Authorization in Action on liveBook Get the book at manning.com

Related concepts

• zero-trust networkingimplements · Zero-trust networking is a security architecture that grants no implicit trust based on network location or prior access and verifies and authorizes access requests explicitly.
• policy information pointhas part · A policy information point is a component that supplies attributes and contextual information needed to evaluate an authorization request.
• policy enforcement pointhas part · A policy enforcement point is an authorization component that receives access requests and applies authorization decisions.
• policy enginehas part · A policy engine is a software component that evaluates policies against requests, resources, actions, or other inputs and produces decisions or enforcement outcomes.
• policy administration pointhas part · A policy administration point is an authorization-system component through which authorization policies are created, updated, or managed.
• trust boundaryuses · A trust boundary is a separation across which assumptions about the trust, authority, control, or security of components, data, or actions change.

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.