liveBook · Manning

What you will learn in Authorization in Action

Build policy-based access control for Zero Trust, APIs, SaaS, and AI agents

by Phil Windley
Foreword by Sarah Cecchetti

Chapter by chapter

Chapter 1: Why authorization matters: Securing access in a digital world

The introduction uses the Target breach and cloud applications to show why authorization is both a security boundary and an architectural capability.

1.1 Managing relationships through digital identity · 1.2 Challenges with traditional approaches to authorization · 1.2.1 Scalability · 1.2.2 Flexibility · 1.2.3 Maintainability · 1.2.4 Inefficiency · 1.2.5 Auditability · 1.2.6 Security · 1.2.7 Consistency and transparency · 1.2.8 Dynamic authorization addresses these challenges · 1.3 Authorization matters · 1.3.1 Software as a Service · 1.3.2 Zero-trust security models · 1.3.3 The Internet of Things · 1.3.4 Heightened regulatory environment · 1.3.5 Artificial intelligence · 1.4 Dynamic authorization: Policy as Code and Policy as Data · 1.4.1 Policy as Code: Defining access logic in a programmable way · 1.4.2 Policy as Data: Storing and managing access rules dynamically · 1.4.3 Dynamic authorization needs both · 1.5 The business case for dynamic authorization · 1.5.1 Reducing operational costs · 1.5.2 Enabling business agility and innovation · 1.5.3 Improving customer experience · 1.5.4 Strengthening security and compliance · 1.5.5 Competitive differentiation · 1.5.6 A business necessity · 1.6 The strategic imperative of dynamic authorization · 1.7 Summary

What you learn in chapter 1 →

Chapter 2: Understanding digital identity

The café-to-kiosk example introduces digital identity as a matter of recognition and relationships, not just accounts and credentials.

2.1 What is digital identity? · 2.2 The problems of digital identity · 2.2.1 The proximity problem · 2.2.2 The interoperability problem · 2.2.3 The flexibility problem · 2.2.4 The privacy problem · 2.2.5 The consent problem · 2.2.6 The scale problem · 2.2.7 How identity problems affect authorization · 2.3 Identity and digital relationships · 2.3.1 Types of digital relationships · 2.3.2 Digital relationship properties · 2.4 Naming and discovery · 2.4.1 The role of names in digital identity · 2.4.2 Tradeoffs in identity naming · 2.4.3 Namespaces and their role in identity · 2.5 Identity system models · 2.5.1 Centralized identity: Single authority, high control · 2.5.2 Federated identity: The backbone of modern identity systems · 2.5.3 Decentralized identity: Shifting control to users · 2.6 Trust and confidence · 2.6.1 The difference between trust and confidence · 2.6.2 Trust and confidence in digital relationships · 2.6.3 Technical confidence in identity systems · 2.6.4 The limits of technical confidence · 2.7 Privacy, authenticity, and confidentiality · 2.7.1 Distinguishing privacy from confidentiality · 2.7.2 Managing tradeoffs · 2.7.3 Functional privacy · 2.8 From identity to authentication · 2.9 Summary

What you learn in chapter 2 →

Chapter 3: Authentication: Who are you?

A Twitter account-hijacking case shows why authentication depends on people and governance as well as technology, and why failures damage the integrity of digital relationships.

3.1 Terminology · 3.2 Authentication preserves relationship integrity · 3.3 Digital relationship life cycles · 3.3.1 Enrollment (discover and co-create) · 3.3.2 Propagate · 3.3.3 Use · 3.3.4 Update · 3.3.5 Terminate · 3.4 Enrollment · 3.4.1 Self-service vs. admin-driven enrollment · 3.4.2 Identity proofing and assurance · 3.4.3 Relationship context and boundaries · 3.4.4 Risk-based boundaries, attribute lifetimes, and reproofing · 3.4.5 The role of credentials and authentication factors · 3.5 Authentication factors · 3.5.1 Primary factors · 3.5.2 Contextual factors · 3.5.3 Authentication factors · 3.6 Authentication methods · 3.6.1 Identifier only · 3.6.2 Token based · 3.6.3 Identifier with authentication factors · 3.6.4 Challenge–response · 3.7 Attack models for authentication · 3.7.1 Authentication assurance levels · 3.7.2 Authentication strength and usability · 3.8 Connecting authentication and authorization · 3.9 Relationship integrity · 3.10 Summary

What you learn in chapter 3 →

Chapter 4: Authorization: What can you do?

The Ring case shows why verifying a person’s identity is not enough to control what they may access.

4.1 Authorization deserves its own focus · 4.2 From relationships to access control · 4.3 Speaking authorization: Key concepts and terms · 4.3.1 The PARC model · 4.3.2 Understanding the language of access · 4.4 Authorization reference architecture · 4.4.1 How access decisions are made · 4.4.2 Where policies come from · 4.5 Architecture patterns in practice · 4.5.1 Embedded PEPs in applications and gateways · 4.5.2 Centralized PDPs · 4.5.3 Distributing authorization decisions · 4.5.4 Choosing the right pattern · 4.5.5 Why this separation matters · 4.6 From architecture to models · 4.7 Summary

What you learn in chapter 4 →

Chapter 5: Static authorization models

The chapter introduction explains why growing systems need structured authorization models, distinguishes static from dynamic models, and notes that organizations often use several models together.

5.1 Access Control Lists · 5.1.1 How ACLs work · 5.1.2 Mapping ACLs onto the authorization reference architecture · 5.1.3 Strengths and limitations of ACLs · 5.1.4 Where ACLs still make sense · 5.1.5 When ACLs fall short · 5.2 Role-Based Access Control · 5.2.1 How RBAC works · 5.2.2 Mapping RBAC onto the authorization reference architecture · 5.2.3 Strengths and limitations of RBAC · 5.2.4 Where RBAC still makes sense · 5.2.5 Where RBAC falls short · 5.3 Beyond static authorization · 5.4 Summary

What you learn in chapter 5 →

Chapter 6: Dynamic authorization models

ACME’s experience shows why static roles remain useful but need to be complemented by relationship- and attribute-based decisions, brought together through policies.

6.1 Relationship-based access control · 6.1.1 How ReBAC works · 6.1.2 Mapping ReBAC onto the authorization reference architecture · 6.1.3 Strengths and limitations of ReBAC · 6.1.4 Where ReBAC makes sense · 6.1.5 When ReBAC falls short · 6.2 Attribute-based access control · 6.2.1 How ABAC works · 6.2.2 Mapping ABAC onto the authorization reference architecture · 6.2.3 Strengths and limitations of ABAC · 6.2.4 Where ABAC makes sense · 6.2.5 When ABAC falls short · 6.3 A hybrid approach: Policy-based access control · 6.3.1 Policy as Data · 6.3.2 Policy as Code · 6.3.3 Beyond one-size-fits-all · 6.4 Summary

What you learn in chapter 6 →

Chapter 7: The building blocks of policy

The introduction uses ACME’s real-time access decisions to show why rules are needed and introduces Cedar as a language for expressing them.

7.1 Introducing Cedar · 7.2 Policy structure: Effect, scope, and conditions · 7.2.1 Effect: What the policy does · 7.2.2 Scope: When the policy applies · 7.2.3 Conditions: Under what circumstances · 7.2.4 Putting it together · 7.3 The PARC model in Cedar: Understanding policy evaluation · 7.3.1 Cedar’s representation of PARC · 7.3.2 Evaluating policies · 7.3.3 Combining results from multiple policies · 7.3.4 PARC as the bridge · 7.4 Cedar’s unique design · 7.4.1 Strong data types · 7.4.2 Rich entity model · 7.4.3 Clear namespace and type safety · 7.4.4 What Cedar doesn’t include · 7.4.5 Minimal operators with maximum effect · 7.4.6 Safe and analyzable by design · 7.5 Cedar’s distinctive strengths · 7.6 Summary

What you learn in chapter 7 →

Chapter 8: Policy languages and frameworks

ACME’s changing needs introduce four authorization approaches and show why PARC is useful for comparing their tradeoffs rather than declaring one winner.

8.1 XACML: The first policy language standard · 8.1.1 A XACML simple example · 8.1.2 Applying the PARC model to XACML · 8.1.3 Legacy and lessons · 8.2 OPA and Rego: Policy for cloud-native systems · 8.2.1 Rego policies example · 8.2.2 Comparing Rego with Cedar · 8.2.3 Applying the PARC model to OPA and Rego · 8.2.4 Strengths and limitations · 8.3 OpenFGA · 8.3.1 How OpenFGA works · 8.3.2 Document access example · 8.3.3 Applying the PARC model to OpenFGA · 8.4 AWS IAM · 8.4.1 How IAM works · 8.4.2 Example: Confidential document access · 8.4.3 Applying the PARC model to AWS IAM · 8.5 Comparing policy languages · 8.5.1 XACML · 8.5.2 OPA/Rego · 8.5.3 OpenFGA · 8.5.4 AWS IAM · 8.5.5 Cedar · 8.5.6 From strengths to selection · 8.6 Summary

What you learn in chapter 8 →

Chapter 9: Implementing policies with Cedar

The introduction presents ACME’s varied access requirements and explains why its identity team wants to express them as unified Cedar policies rather than scattered application checks.

9.1 From primer to practice · 9.2 Modeling your schema first · 9.2.1 ACME’s core entities and actions · 9.2.2 How schema shapes policies · 9.2.3 Updating schema as your system evolves · 9.3 Authoring ACME’s core policies · 9.3.1 Permit view if on the right team · 9.3.2 Owner can do all · 9.3.3 Manager of owner can view and edit · 9.4 Where does Cedar find data about entities? · 9.5 Applying Cedar’s policy patterns · 9.5.1 Discretionary permissions · 9.5.2 Membership permissions · 9.5.3 Relationship permissions · 9.5.4 Mixing patterns for PBAC · 9.6 Layering global constraints · 9.7 Using policy templates and overrides · 9.7.1 Templates · 9.7.2 Overrides · 9.8 Mapping requests to Cedar evaluations · 9.9 From concept to policy · 9.10 Summary

What you learn in chapter 9 →

Chapter 10: Policy as code: Effective authorization policies

The introduction explains why ACME needs authorization policies that remain effective as systems and requirements change, and frames dependable policy around design, management, and assurance.

10.1 Principles of effective authorization policies · 10.1.1 Clarity and consistency · 10.1.2 Least privilege · 10.1.3 Separation of policy and data · 10.1.4 Granularity and grouping · 10.1.5 Stability across change · 10.1.6 From principles to practice · 10.2 Policy as Code in practice · 10.2.1 Schemas and validation · 10.2.2 Versioning and review · 10.2.3 Operational considerations · 10.2.4 Continuous integration for policies · 10.3 Testing policies effectively · 10.4 Pulling it together · 10.5 Summary

What you learn in chapter 10 →

Chapter 11: Authorization for APIs

The introduction distinguishes internal API enforcement from external delegation and explains why ACME adopted complementary strategies for each.

11.1 Authorization in a microservices world · 11.1.1 Pattern 1: API gateway as enforcement point · 11.1.2 Pattern 2: Service mesh with sidecar enforcement · 11.1.3 Pattern 3: Per-service proxies · 11.1.4 Comparing enforcement patterns · 11.1.5 Other API authorization enforcement patterns · 11.2 Authorization for external access to APIs · 11.2.1 The OAuth protocol and roles · 11.2.2 OAuth scopes · 11.2.3 Acquiring OAuth tokens · 11.2.4 Using OAuth tokens · 11.3 From microservices to third parties: One policy story · 11.4 Summary

What you learn in chapter 11 →

Chapter 12: Authorization context

The introduction explains why authorization policies need trustworthy context and how signal choice, delivery, and freshness vary with each use case.

12.1 Policy Information Points · 12.2 Entities: Principals and resources · 12.3 Signals and their delivery · 12.3.1 What the signals are · 12.3.2 How signals are delivered · 12.3.3 ACME’s delivery choices · 12.4 Freshness, caching, and revocation · 12.4.1 The freshness spectrum · 12.4.2 Caching strategies · 12.4.3 Revocation and signal updates · 12.4.4 ACME’s approach to freshness · 12.5 Transmission and integrity of signals · 12.5.1 How signals move · 12.5.2 Protecting signals in transit · 12.5.3 Limiting signal scope · 12.6 Authorization context normalization · 12.6.1 The normalization layer · 12.6.2 Benefits of normalization · 12.6.3 Extending SSF inside the organization · 12.6.4 The broader lesson · 12.7 Putting it all together · 12.8 Summary

What you learn in chapter 12 →

Chapter 13: Using policy engines with existing systems

The introduction explains why ACME must modernize authorization as its internal collaboration platform becomes a multi-tenant SaaS service, while retaining its existing sharing model.

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 request flow · 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 tradeoffs · 13.5.6 Three layers of policy · 13.5.7 Shared schema and type safety · 13.5.8 Policy life cycle 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 · 13.6.5 Lessons from the pilots · 13.7 Putting lessons into practice · 13.8 Summary

What you learn in chapter 13 →

Chapter 14: Policy governance

ACME’s experience shows why deploying well-tested authorization policies is not enough without governance that keeps them accountable over time.

14.1 Why governance matters for authorization · 14.2 The policy management life cycle · 14.2.1 Create · 14.2.2 Review and approve · 14.2.3 Deploy and use · 14.2.4 Monitor · 14.2.5 Update · 14.2.6 Retire · 14.3 Governance frameworks for policy management · 14.3.1 The structure of governance · 14.3.2 Roles and responsibilities · 14.4 Identity Governance and Administration and policy governance · 14.5 Regulatory compliance and authorization · 14.6 Best practices for policy governance · 14.7 Getting started with policy governance · 14.8 Governance as the foundation of trust · 14.9 Summary

What you learn in chapter 14 →

Chapter 15: Security, zero trust, and authorization

ACME’s experience shows why zero trust depends on policy-based authorization of each access request rather than reliance on a network perimeter.

15.1 Rethinking security for the zero-trust era · 15.2 Authorization is the foundation of zero trust · 15.3 Policies for zero trust · 15.3.1 Foundational security policies · 15.3.2 Shared operational policies · 15.3.3 Application policies · 15.3.4 Putting the layers together · 15.4 Using policy to control access · 15.5 Measuring progress toward zero trust · 15.5.1 Policy coverage · 15.5.2 Signal quality · 15.5.3 Decision consistency · 15.5.4 Reduced perimeter reliance · 15.5.5 Decline in authorization exceptions · 15.6 Beyond security: The organizational payoff · 15.7 Summary

What you learn in chapter 15 →

Chapter 16: Using verifiable credentials for authorization

The introduction explains why ACME struggles to authorize people and attributes outside its identity systems and presents verifiable credentials as a way to use attestations from trusted external issuers.

16.1 Why authorization needs verifiable credentials · 16.2 How verifiable credentials work · 16.2.1 Credential presentation · 16.2.2 Example: Contractor access using verifiable credentials · 16.3 Trusting credential issuers · 16.3.1 Example: ACME onboards AuditsRUs as a trusted issuer · 16.3.2 Building and maintaining ACME’s trust store · 16.4 Credential freshness, revocation, and assurance · 16.5 Requesting verifiable credential presentations · 16.6 Using verifiable credentials with policies · 16.6.1 Allow access only to auditors from accredited firms · 16.6.2 Require current certification from an accredited authority · 16.7 Protocols and ecosystem integration · 16.8 Applying verifiable credentials across ACME’s products · 16.8.1 Supplier portal: Representing supplier authority across multi-tier relationships · 16.8.2 Clinic integration: Clinicians from external organizations · 16.8.3 Field technicians: Employer-issued scope-of-work credentials · 16.8.4 Customer Collaboration Cloud: Project-scoped roles in a multi-tenant platform · 16.9 Operational and governance considerations · 16.9.1 Deciding when to use verifiable credentials · 16.9.2 Failure modes and fallback paths · 16.9.3 Governance responsibilities · 16.9.4 Rolling out verifiable credentials incrementally · 16.10 Summary

What you learn in chapter 16 →

Chapter 17: AI in policy practice

The introduction explains why AI can help people work with authorization policies but should not make the final access decision.

17.1 AI is not your policy engine · 17.2 Policy authoring and analysis with AI · 17.2.1 Explaining existing behavior · 17.2.2 Exploring alternative expressions of intent · 17.2.3 Using concrete requests to ground analysis · 17.2.4 Human judgment remains central · 17.3 What AI can tell you about your authorization policies · 17.3.1 Seeing what policies really do · 17.3.2 Identifying gaps and edge cases · 17.3.3 Asking better questions · 17.3.4 From observation to accountability · 17.4 Authorization before retrieval: Making RAG safe by construction · 17.4.1 A quick review of how RAG works · 17.4.2 Retrieval is the enforcement boundary · 17.4.3 From architectural principle to concrete flow · 17.4.4 Safe by construction, not safe by instruction · 17.5 From architecture to accountability · 17.6 Policy as practice · 17.7 Summary

What you learn in chapter 17 →

Chapter 18: Authorization for AI agents

ACME’s experience shows why agents that choose and revise actions at runtime need explicit, ongoing authorization rather than access based merely on their ability to reach a tool.

18.1 Why authorization is the hard problem in agentic AI · 18.2 How agents interact with external systems · 18.3 A policy-aware agent loop · 18.3.1 Authorization as part of the feedback loop · 18.3.2 Defining operational boundaries with policy · 18.3.3 From predefined workflows to governed behavior · 18.3.4 Practical implications · 18.4 Beyond denial: Guiding agent behavior with policy constraints · 18.4.1 From reactive enforcement to constraint-aware planning · 18.4.2 Integrating constraints into the planning loop · 18.4.3 Reducing trial and error · 18.4.4 Policy as a source of guidance · 18.4.5 From control to collaboration · 18.5 Childproofing the control plane · 18.6 Delegation and subagents · 18.6.1 Delegation as data · 18.6.2 Enforcing delegation at runtime · 18.6.3 Policies that enforce delegation · 18.6.4 Allowed and denied behavior · 18.6.5 Delegation as constrained authority · 18.6.6 Extending the policy-aware architecture · 18.7 Cross-domain delegation among agents · 18.8 Summary

What you learn in chapter 18 →

Chapter 19: Authorization as strategy

ACME’s experience shows how authorization grew from a document-sharing concern into a capability the company needed to design deliberately to scale.

19.1 When authorization became the hard problem · 19.2 The architecture ACME built · 19.3 When the CIO and CISO finally agreed · 19.4 What changed inside ACME · 19.5 Where most organizations are today · 19.6 A practical path forward · 19.7 The next era of digital trust · 19.8 Where ACME landed · 19.9 Deciding continuously · 19.10 Summary

What you learn in chapter 19 →

Concepts explained in this book

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.