12 Authorization context

Dynamic authorization depends on more than policies; it depends on trustworthy context. The chapter explains that every decision hinges on three linked choices: which signals matter, how those signals are delivered, and how fresh they must be when evaluated. Trust signals can describe identity, device posture, risk, location, session assurance, or operational status, and they become useful only when a policy engine can assemble them into a coherent view of who is acting, what they want, and whether the surrounding conditions are acceptable.

Using ACME as the example, the chapter shows that different systems require different mixes of token-based claims, API lookups, and event-driven updates. Customer workflows can often rely on longer-lived token data plus occasional database checks, while employee and engineering workflows need richer context such as HR status, finance limits, device trust, and on-call status. The Policy Information Point is therefore not a single box but an ecosystem of integrations that collects, verifies, and normalizes signals before the policy engine evaluates them.

The chapter also emphasizes that freshness, security, and normalization are essential to making authorization reliable at scale. Cached data and short-lived tokens improve performance, but only if revocation, updates, and provenance are handled carefully. ACME’s move to an enterprise PIP and shared normalization layer solved inconsistent schemas, reduced duplicated integration work, limited unnecessary data exposure, and made policy behavior consistent across platforms. The result is a reusable authorization context layer that turns raw signals into dependable input for enforcement.

Policy Information Points (PIPs): abstract vs. reality. Left: the abstract authorization architecture shows a single PIP feeding data to the Policy Decision Point (PDP). Right: in practice, the PIP represents many sources—including HR, Finance, authentication systems, device posture clients, external systems, and so on—all connected through APIs, tokens, and caches to deliver the trust signals that policies need.

 Inside the Policy Decision Point (PDP). The PDP includes more than just a policy engine. At ACME, a signal-processing layer collects data from various systems (HR, Finance, the Customer Authentication Service, device posture clients, and external services like PagerDuty) and organizes it into well-formed entities for evaluation by the Cedar engine. The PDP then provides a decision to the PEP after policies are assessed against the collected context.

ACME’s normalization architecture. Before normalization (top), each PDP integrated directly with HR, Finance, authentication, and operational systems (e.g., PagerDuty, ticketing), each with custom schemas and caches. After normalization (bottom), a shared signal-normalization layer aggregates and standardizes those feeds, delivering consistent context to all PDPs. Device posture arrives separately as a signed token attached to each access request and is verified alongside the normalized data. This hybrid model keeps tokens minimal (identifier plus scopes) while preserving rich, consistent context for authorization decisions.

• Policies are only as good as their signals; the three design dimensions are which signals are used, how they are delivered, and how fresh they are.
• Real-world PIPs use signals from multiple sources. PDPs feature lightweight processing before the policy engine.
• Token, query, and hybrid delivery each involve tradeoffs among latency, availability, and assurance.
• Freshness is a first-class design choice. Revocation and event-driven signal delivery reduce exposure windows.
• Transmission essentials: provenance, signatures, and scoped sharing foster confidence in authenticity, integrity, and confidentiality.
• Normalization (enterprise PIP plus shared schema) produces consistent decisions, safer transmission, quicker adoption, and reduced engineering costs.
• ACME’s final architecture uses a hybrid model: minimal tokens with device-based attestations plus normalized background context.

FAQ