book

Authorization in Action

Name: Authorization in Action
Author: Phillip Windley
ISBN: 9781633435179

by Phillip Windley

August 2026

Intermediate

464 pages

15h 9m

English

Manning Publications

Read now

Unlock full access

Authorization in Action
copyright
contents
foreword
preface
acknowledgments
about this book
about the author
about the cover illustration
1 Why authorization matters: Securing access in a digital world
1.1 Managing relationships through digital identity1.2 Challenges with traditional approaches to authorization1.2.1 Scalability1.2.2 Flexibility1.2.3 Maintainability1.2.4 Inefficiency1.2.5 Auditability1.2.6 Security1.2.7 Consistency and transparency1.2.8 Dynamic authorization addresses these challenges1.3 Authorization matters1.3.1 Software as a Service1.3.2 Zero-trust security models1.3.3 The Internet of Things1.3.4 Heightened regulatory environment1.3.5 Artificial intelligence1.4 Dynamic authorization: Policy as Code and Policy as Data1.4.1 Policy as Code: Defining access logic in a programmable way1.4.2 Policy as Data: Storing and managing access rules dynamically1.4.3 Dynamic authorization needs both1.5 The business case for dynamic authorization1.5.1 Reducing operational costs1.5.2 Enabling business agility and innovation1.5.3 Improving customer experience1.5.4 Strengthening security and compliance1.5.5 Competitive differentiation1.5.6 A business necessity1.6 The strategic imperative of dynamic authorization

2 Understanding digital identity
2.1 What is digital identity?2.2 The problems of digital identity2.2.1 The proximity problem2.2.2 The interoperability problem2.2.3 The flexibility problem2.2.4 The privacy problem2.2.5 The consent problem2.2.6 The scale problem2.2.7 How identity problems affect authorization2.3 Identity and digital relationships2.3.1 Types of digital relationships2.3.2 Digital relationship properties2.4 Naming and discovery2.4.1 The role of names in digital identity2.4.2 Tradeoffs in identity naming2.4.3 Namespaces and their role in identity2.5 Identity system models2.5.1 Centralized identity: Single authority, high control2.5.2 Federated identity: The backbone of modern identity systems2.5.3 Decentralized identity: Shifting control to users2.6 Trust and confidence2.6.1 The difference between trust and confidence2.6.2 Trust and confidence in digital relationships2.6.3 Technical confidence in identity systems2.6.4 The limits of technical confidence2.7 Privacy, authenticity, and confidentiality2.7.1 Distinguishing privacy from confidentiality2.7.2 Managing tradeoffs2.7.3 Functional privacy2.8 From identity to authentication
3 Authentication: Who are you?
3.1 Terminology3.2 Authentication preserves relationship integrity3.3 Digital relationship life cycles3.3.1 Enrollment (discover and co-create)3.3.2 Propagate3.3.3 Use3.3.4 Update3.3.5 Terminate3.4 Enrollment3.4.1 Self-service vs. admin-driven enrollment3.4.2 Identity proofing and assurance3.4.3 Relationship context and boundaries3.4.4 Risk-based boundaries, attribute lifetimes, and reproofing3.4.5 The role of credentials and authentication factors3.5 Authentication factors3.5.1 Primary factors3.5.2 Contextual factors3.5.3 Authentication factors3.6 Authentication methods3.6.1 Identifier only3.6.2 Token based3.6.3 Identifier with authentication factors3.6.4 Challenge–response3.7 Attack models for authentication3.7.1 Authentication assurance levels3.7.2 Authentication strength and usability3.8 Connecting authentication and authorization3.9 Relationship integrity
4 Authorization: What can you do?
4.1 Authorization deserves its own focus4.2 From relationships to access control4.3 Speaking authorization: Key concepts and terms4.3.1 The PARC model4.3.2 Understanding the language of access4.4 Authorization reference architecture4.4.1 How access decisions are made4.4.2 Where policies come from4.5 Architecture patterns in practice4.5.1 Embedded PEPs in applications and gateways4.5.2 Centralized PDPs4.5.3 Distributing authorization decisions4.5.4 Choosing the right pattern4.5.5 Why this separation matters4.6 From architecture to models
5 Static authorization models
5.1 Access Control Lists5.1.1 How ACLs work5.1.2 Mapping ACLs onto the authorization reference architecture5.1.3 Strengths and limitations of ACLs5.1.4 Where ACLs still make sense5.1.5 When ACLs fall short5.2 Role-Based Access Control5.2.1 How RBAC works5.2.2 Mapping RBAC onto the authorization reference architecture5.2.3 Strengths and limitations of RBAC5.2.4 Where RBAC still makes sense5.2.5 Where RBAC falls short5.3 Beyond static authorization
6 Dynamic authorization models
6.1 Relationship-based access control6.1.1 How ReBAC works6.1.2 Mapping ReBAC onto the authorization reference architecture6.1.3 Strengths and limitations of ReBAC6.1.4 Where ReBAC makes sense6.1.5 When ReBAC falls short6.2 Attribute-based access control6.2.1 How ABAC works6.2.2 Mapping ABAC onto the authorization reference architecture6.2.3 Strengths and limitations of ABAC6.2.4 Where ABAC makes sense6.2.5 When ABAC falls short6.3 A hybrid approach: Policy-based access control6.3.1 Policy as Data6.3.2 Policy as Code6.3.3 Beyond one-size-fits-all
7 The building blocks of policy
7.1 Introducing Cedar7.2 Policy structure: Effect, scope, and conditions7.2.1 Effect: What the policy does7.2.2 Scope: When the policy applies7.2.3 Conditions: Under what circumstances7.2.4 Putting it together7.3 The PARC model in Cedar: Understanding policy evaluation7.3.1 Cedar’s representation of PARC7.3.2 Evaluating policies7.3.3 Combining results from multiple policies7.3.4 PARC as the bridge7.4 Cedar’s unique design7.4.1 Strong data types7.4.2 Rich entity model7.4.3 Clear namespace and type safety7.4.4 What Cedar doesn’t include7.4.5 Minimal operators with maximum effect7.4.6 Safe and analyzable by design7.5 Cedar’s distinctive strengths
8 Policy languages and frameworks
8.1 XACML: The first policy language standard8.1.1 A XACML simple example8.1.2 Applying the PARC model to XACML8.1.3 Legacy and lessons8.2 OPA and Rego: Policy for cloud-native systems8.2.1 Rego policies example8.2.2 Comparing Rego with Cedar8.2.3 Applying the PARC model to OPA and Rego8.2.4 Strengths and limitations8.3 OpenFGA8.3.1 How OpenFGA works8.3.2 Document access example8.3.3 Applying the PARC model to OpenFGA8.4 AWS IAM8.4.1 How IAM works8.4.2 Example: Confidential document access8.4.3 Applying the PARC model to AWS IAM8.5 Comparing policy languages8.5.1 XACML8.5.2 OPA/Rego8.5.3 OpenFGA8.5.4 AWS IAM8.5.5 Cedar8.5.6 From strengths to selection
9 Implementing policies with Cedar
9.1 From primer to practice9.2 Modeling your schema first9.2.1 ACME’s core entities and actions9.2.2 How schema shapes policies9.2.3 Updating schema as your system evolves9.3 Authoring ACME’s core policies9.3.1 Permit view if on the right team9.3.2 Owner can do all9.3.3 Manager of owner can view and edit9.4 Where does Cedar find data about entities?9.5 Applying Cedar’s policy patterns9.5.1 Discretionary permissions9.5.2 Membership permissions9.5.3 Relationship permissions9.5.4 Mixing patterns for PBAC9.6 Layering global constraints9.7 Using policy templates and overrides9.7.1 Templates9.7.2 Overrides9.8 Mapping requests to Cedar evaluations9.9 From concept to policy
10 Policy as code: Effective authorization policies
10.1 Principles of effective authorization policies10.1.1 Clarity and consistency10.1.2 Least privilege10.1.3 Separation of policy and data10.1.4 Granularity and grouping10.1.5 Stability across change10.1.6 From principles to practice10.2 Policy as Code in practice10.2.1 Schemas and validation10.2.2 Versioning and review10.2.3 Operational considerations10.2.4 Continuous integration for policies10.3 Testing policies effectively10.4 Pulling it together
11 Authorization for APIs
11.1 Authorization in a microservices world11.1.1 Pattern 1: API gateway as enforcement point11.1.2 Pattern 2: Service mesh with sidecar enforcement11.1.3 Pattern 3: Per-service proxies11.1.4 Comparing enforcement patterns11.1.5 Other API authorization enforcement patterns11.2 Authorization for external access to APIs11.2.1 The OAuth protocol and roles11.2.2 OAuth scopes11.2.3 Acquiring OAuth tokens11.2.4 Using OAuth tokens11.3 From microservices to third parties: One policy story
12 Authorization context
12.1 Policy Information Points12.2 Entities: Principals and resources12.3 Signals and their delivery12.3.1 What the signals are12.3.2 How signals are delivered12.3.3 ACME’s delivery choices12.4 Freshness, caching, and revocation12.4.1 The freshness spectrum12.4.2 Caching strategies12.4.3 Revocation and signal updates12.4.4 ACME’s approach to freshness12.5 Transmission and integrity of signals12.5.1 How signals move12.5.2 Protecting signals in transit12.5.3 Limiting signal scope12.6 Authorization context normalization12.6.1 The normalization layer12.6.2 Benefits of normalization12.6.3 Extending SSF inside the organization12.6.4 The broader lesson12.7 Putting it all together
13 Using policy engines with existing systems
13.1 From internal tool to external service: ACME’s next chapter13.2 Understanding the starting point13.3 Identity and tenancy foundation for C³13.3.1 From project IDs to tenants13.3.2 Unified customer identity via OIDC13.3.3 Device posture for ACME employees13.4 Designing for externalized authorization13.4.1 Platform and tenant PDPs13.4.2 Deployment options for tenant PDPs13.4.3 Authorization request flow13.5 Policy enforcement points in the stack13.5.1 Global enforcement: The ACME gateway13.5.2 Tenant-level enforcement: Collaboration services13.5.3 UI and client-side enforcement13.5.4 Consistency through shared components13.5.5 Operational tradeoffs13.5.6 Three layers of policy13.5.7 Shared schema and type safety13.5.8 Policy life cycle and distribution13.5.9 Governance and safety13.5.10 Benefits of the layered model13.6 Case studies inside ACME13.6.1 Case 1: Cross-tenant legal review13.6.2 Case 2: Support escalation13.6.3 Case 3: Custom collaboration template13.6.4 Case 4: Automated backup verification13.6.5 Lessons from the pilots13.7 Putting lessons into practice
14 Policy governance
14.1 Why governance matters for authorization14.2 The policy management life cycle14.2.1 Create14.2.2 Review and approve14.2.3 Deploy and use14.2.4 Monitor14.2.5 Update14.2.6 Retire14.3 Governance frameworks for policy management14.3.1 The structure of governance14.3.2 Roles and responsibilities14.4 Identity Governance and Administration and policy governance14.5 Regulatory compliance and authorization14.6 Best practices for policy governance14.7 Getting started with policy governance14.8 Governance as the foundation of trust
15 Security, zero trust, and authorization
15.1 Rethinking security for the zero-trust era15.2 Authorization is the foundation of zero trust15.3 Policies for zero trust15.3.1 Foundational security policies15.3.2 Shared operational policies15.3.3 Application policies15.3.4 Putting the layers together15.4 Using policy to control access15.5 Measuring progress toward zero trust15.5.1 Policy coverage15.5.2 Signal quality15.5.3 Decision consistency15.5.4 Reduced perimeter reliance15.5.5 Decline in authorization exceptions15.6 Beyond security: The organizational payoff
16 Using verifiable credentials for authorization
16.1 Why authorization needs verifiable credentials16.2 How verifiable credentials work16.2.1 Credential presentation16.2.2 Example: Contractor access using verifiable credentials16.3 Trusting credential issuers16.3.1 Example: ACME onboards AuditsRUs as a trusted issuer16.3.2 Building and maintaining ACME’s trust store16.4 Credential freshness, revocation, and assurance16.5 Requesting verifiable credential presentations16.6 Using verifiable credentials with policies16.6.1 Allow access only to auditors from accredited firms16.6.2 Require current certification from an accredited authority16.7 Protocols and ecosystem integration16.8 Applying verifiable credentials across ACME’s products16.8.1 Supplier portal: Representing supplier authority across multi-tier relationships16.8.2 Clinic integration: Clinicians from external organizations16.8.3 Field technicians: Employer-issued scope-of-work credentials16.8.4 Customer Collaboration Cloud: Project-scoped roles in a multi-tenant platform16.9 Operational and governance considerations16.9.1 Deciding when to use verifiable credentials16.9.2 Failure modes and fallback paths16.9.3 Governance responsibilities16.9.4 Rolling out verifiable credentials incrementally
17 AI in policy practice
17.1 AI is not your policy engine17.2 Policy authoring and analysis with AI17.2.1 Explaining existing behavior17.2.2 Exploring alternative expressions of intent17.2.3 Using concrete requests to ground analysis17.2.4 Human judgment remains central17.3 What AI can tell you about your authorization policies17.3.1 Seeing what policies really do17.3.2 Identifying gaps and edge cases17.3.3 Asking better questions17.3.4 From observation to accountability17.4 Authorization before retrieval: Making RAG safe by construction17.4.1 A quick review of how RAG works17.4.2 Retrieval is the enforcement boundary17.4.3 From architectural principle to concrete flow17.4.4 Safe by construction, not safe by instruction17.5 From architecture to accountability17.6 Policy as practice
18 Authorization for AI agents
18.1 Why authorization is the hard problem in agentic AI18.2 How agents interact with external systems18.3 A policy-aware agent loop18.3.1 Authorization as part of the feedback loop18.3.2 Defining operational boundaries with policy18.3.3 From predefined workflows to governed behavior18.3.4 Practical implications18.4 Beyond denial: Guiding agent behavior with policy constraints18.4.1 From reactive enforcement to constraint-aware planning18.4.2 Integrating constraints into the planning loop18.4.3 Reducing trial and error18.4.4 Policy as a source of guidance18.4.5 From control to collaboration18.5 Childproofing the control plane18.6 Delegation and subagents18.6.1 Delegation as data18.6.2 Enforcing delegation at runtime18.6.3 Policies that enforce delegation18.6.4 Allowed and denied behavior18.6.5 Delegation as constrained authority18.6.6 Extending the policy-aware architecture18.7 Cross-domain delegation among agents
19 Authorization as strategy
19.1 When authorization became the hard problem19.2 The architecture ACME built19.3 When the CIO and CISO finally agreed19.4 What changed inside ACME19.5 Where most organizations are today19.6 A practical path forward19.7 The next era of digital trust19.8 Where ACME landed19.9 Deciding continuously
appendix A End-to-end example with Amazon Verified Permissions
A.1 PrerequisitesA.2 Create a policy storeA.3 Upload the Cedar schemaA.4 Uploading policies to AVPA.4.1 View policiesA.4.2 Owner can do everything policyA.4.3 Employees can share documents that are delegatableA.4.4 Forbid access from unmanaged devicesA.5 Defining entitiesA.5.1 EmployeesA.5.2 CustomersA.5.3 TeamsA.5.4 DocumentA.5.5 Using the entity definitionsA.6 Evaluating authorization requestsA.6.1 Owner actionsA.6.2 Customer viewingA.6.3 Employee sharingA.6.4 Unmanaged devicesA.7 Wrapping up the end-to-end example
appendix B Step-by-step AI-assisted policy authoring
B.1 Why AI assistance is useful in policy authoringB.2 Recap: The ACME policy environmentB.3 Getting set up: The companion repository and CursorB.4 Providing the right context to the AIB.5 A human-in-the-loop authoring workflowB.6 Steps for modifying a policy set to achieve a specific outcomeB.6.1 Step 1: Establish the current behaviorB.6.2 Step 2: State the desired outcome preciselyB.6.3 Step 3: Ask the AI to explore implementation optionsB.6.4 Step 4: Evaluate options as a human reviewerB.6.5 Step 5: Apply the change deliberatelyB.6.6 Step 6: Reflect on the changeB.6.7 Things to tryB.7 Guardrails and review checklistB.8 Key takeaways
appendix C Cedar authorization with OpenClaw agents
C.1 How these demos are structuredC.2 PrerequisitesC.3 Demo 1: Reactive authorizationC.3.1 Start the PDP, and verify it’s workingC.3.2 Run the live agentC.3.3 Observe denied behaviorC.3.4 Observe agent replanningC.3.5 What this demo showsC.4 Demo 2: Constraint-aware planningC.4.1 Start the PDP, and verify that query constraints are workingC.4.2 Run the agent with constraint awarenessC.4.3 How policy residuals guide the agentC.4.4 Compare with reactive behaviorC.5 Demo 3: Delegation as dataC.5.1 A delegation record in practiceC.5.2 Policies behind delegationC.5.3 Walk through the delegation notebookC.5.4 What to observeC.6 Wrapping up

Content preview from Authorization in Action

5 Static authorization models

This chapter covers

Static versus dynamic authorization models
Managing permissions with Access Control Lists (ACLs)
Assigning access through Role-Based Access Control (RBAC)
Mapping ACLs and RBAC to the reference architecture components
The strengths and limitations of static models
Where ACLs and RBAC still make sense in modern systems

When ACME Corp launched its first SaaS product, authorization was an afterthought. With a handful of developers and a few early customers, it was easy to hardcode access to the admin dashboard and restrict sensitive features to known team members. Everyone had access to staging environments, and customer data was stored in separate folders, protected more by convention than ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781633435179Publisher Support Other Publisher Website Purchase Link

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Authorization in Action

by Phillip Windley