Chapter 4: Authorization: What can you do?

Introduction

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

• Authentication and authorization distinction: Explain why authenticating Ring employees and contractors did not justify their access to customer videos. Describe the separate authorization question of whether a particular person should view a particular video in a given context and at a given time.
  Why it matters: A system can identify every user correctly and still allow harmful access.

Key terms: authentication, authorization, contextual checks, policy-based enforcement

4.1 Authorization deserves its own focus

This section explains why authorization needs attention distinct from authentication: access decisions are contextual, distributed, and consequential for security and users.

• Authorization beyond authentication: Distinguish authentication’s question of who someone is from authorization’s question of what they should be allowed to do. Explain why authorization cannot be treated as merely a one-time step after authentication.
  Why it matters: Knowing who a user is does not, by itself, settle what that user may do.
• Complex and distributed access decisions: Describe why real-world authorization is difficult to keep consistent: policies can depend on many variables, while decisions occur across services, platforms, and APIs. Identify brittle roles, hardcoded rules, and scattered permissions as common current approaches.
  Why it matters: Scattered rules make it harder to maintain a consistent picture of who can access what.
• Security and user consequences: Explain how authorization design affects both security and the user experience. Describe how incorrect access controls can expose data or violate regulations, while also blocking legitimate work or shaping what the interface shows.
  Why it matters: Access decisions affect everyday functionality as well as exposure of sensitive resources.

Key terms: authentication, authorization, contextual, continuous, roles, hardcoded rules, permissions, policies, distributed, consistent authorization logic

4.2 From relationships to access control

The section explains how authorization turns an authenticated digital relationship into enforceable decisions about access.

• Relationships and access decisions: Distinguish digital identity, authentication, and authorization: identity establishes a relationship, authentication validates the interacting entity, and authorization determines what that entity can do, under what conditions, and with which resources.
  Why it matters: Being recognized by a system is different from being allowed to take a particular action.
• Context in authorization decisions: Explain how details of an authenticated entity’s relationship and circumstances can affect access, using the section’s role, shift-hours, and registered-device examples.
  Why it matters: The same authenticated person may be allowed or denied access depending on the action and relevant context.

Key terms: digital identity, authentication, authorization, access control, role, contextual data, policy, registered device

4.3 Speaking authorization: Key concepts and terms

This section distinguishes access control as the overall strategy from authorization as the mechanism that makes and enforces access decisions at runtime.

• Access control and authorization distinction: Distinguish access control from authorization, and explain why an access strategy must become reliable runtime decisions to protect resources.
  Why it matters: The distinction connects broad access rules to the decisions that actually protect a resource.

Key terms: access control, authorization, identity, attributes, policy, runtime decisions

4.3.1 The PARC model

This section introduces PARC as a four-part way to describe authorization decisions and explain how context shapes access.

• PARC request components: Describe PARC as principal, action, resource, and conditions, and identify the requester, operation, and target in an access request. Explain that this shared structure helps people analyze and discuss policies and requests consistently.
  Why it matters: PARC gives you a consistent way to describe what an authorization decision is about.
• Conditions and access context: Explain what conditions add to a PARC decision, giving examples of contextual factors and noting that they can depend on principal, resource, or environmental attributes.
  Why it matters: Conditions explain why the same requested action on a resource may be treated differently in different circumstances.

Key terms: PARC, principal, action, resource, attributes, conditions, context, workload identity

4.3.2 Understanding the language of access

This section defines the vocabulary used to describe participants, rules, requests, and outcomes in authorization decisions.

• Entities and access attributes: Describe entities as principals or resources that participate in policies, and explain how attributes of principals, resources, or the environment inform access decisions.
  Why it matters: These terms let you describe what a policy considers when deciding access.
• Subjects and qualified names: Distinguish the potentially ambiguous term subject from the more specific terms principal and resource, and explain why namespaces qualify entity types and actions.
  Why it matters: Precise names reduce ambiguity when people discuss or write access rules.
• Groups roles and permissions: Distinguish a group of entities, a role that collects permissions for a function, and a permission to perform an action on a resource.
  Why it matters: Keeping these terms separate makes it easier to describe how access is organized and assigned.
• Effective entitlements over time: Explain why a principal's entitlement is what they can actually do at a particular time, rather than simply the permissions associated with their roles.
  Why it matters: Assigned roles alone may not tell you what someone is allowed to do right now.
• Policies requests and responses: Describe what a policy expresses, what an authorization request asks, and what an authorization response returns.
  Why it matters: This vocabulary separates the access rule, the question asked of the system, and its answer.
• Matching versus decisive policies: Distinguish satisfied policies, whose conditions match a request, from determining policies, which directly influence its outcome.
  Why it matters: The distinction helps explain why a decision was made, not merely which rules matched.

Key terms: entity, principal, resource, attribute, subject, namespace, group, role, permission, entitlement

4.4 Authorization reference architecture

The section introduces the four-part authorization reference architecture inherited from XACML and explains why it remains a useful blueprint despite XACML’s limited adoption.

• Four authorization component roles: Describe the distinct responsibilities of the PEP, PDP, PAP, and PIP in the authorization reference architecture.
  Why it matters: These roles give you a common way to describe where an authorization system enforces access, decides, manages policies, and gets context.
• Reusable reference architecture blueprint: Explain what a reference architecture provides and why it can guide different authorization systems without prescribing one implementation.
  Why it matters: The blueprint lets teams discuss and compare authorization designs without assuming every system uses the same technology.
• XACML architectural legacy: Explain why XACML remains influential as an authorization architecture even though XACML itself has not been widely adopted in modern systems.
  Why it matters: It explains why the book uses XACML’s architectural vocabulary without requiring systems to adopt XACML.

Key terms: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Administration Point (PAP), Policy Information Point (PIP), reference architecture, abstract yet actionable, reusable across domains, XACML, separation of concerns

4.4.1 How access decisions are made

The section traces how ACMEProject turns Alice’s request to view a report into an explainable, policy-driven access decision.

• Access decision component roles: Trace Alice’s request through the Policy Enforcement Point, Policy Decision Point, and Policy Information Point, explaining what each contributes before access is enforced.
  Why it matters: Separating these roles makes an access decision easier to explain than a check hidden inside the application.
• Context behind Alice’s denial: Explain why Alice is denied the report despite being signed in, having the right role, and using a trusted device, and describe how the denial can be explained to her.
  Why it matters: A successful sign-in or matching role does not by itself settle whether a particular request is permitted.

Key terms: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP), principal, action, resource, conditions, deny decision

4.4.2 Where policies come from

This section explains how ACME creates and governs authorization policies in a Policy Administration Point before deploying them for Policy Decision Points to use.

• Policy Administration Point workflow: Describe how a security administrator turns an access rule into a declarative policy in the Policy Administration Point (PAP), then versions, reviews, tests, and deploys it rather than embedding the rule in application code.
  Why it matters: Managing the rule in the PAP makes an access change reviewable and testable before it affects users.
• Approved policy decision use: Trace what happens after a policy is approved: it is deployed for the PDP to use when evaluating real-time requests, with its effective time depending on the deployment model.
  Why it matters: A policy change governs requests only after the decision point is using the deployed policy.
• Visible policy change history: Explain why ACME keeps access rules as explicit, centrally managed policy artifacts with owners and histories instead of scattered permission checks.
  Why it matters: A visible policy history helps ACME account for access decisions and govern changes to them.

Key terms: Policy Administration Point (PAP), declarative, version control, Policy Decision Point (PDP), centralized PDP, distributed systems, cached policies, policy artifact, owner, history

4.5 Architecture patterns in practice

This section introduces the practical need to place authorization components in a system and identifies the factors that shape that choice.

• Authorization component placement: Explain that defining PEPs, PDPs, and PIPs is not enough: a working system must decide where components live. Describe the possible enforcement locations named for ACME and the factors that influence placement.
  Why it matters: The same authorization components can be deployed in different places to suit a system’s constraints.

Key terms: PEPs, PDPs, PIPs, enforcement, API gateway, sidecar

4.5.1 Embedded PEPs in applications and gateways

This section compares application, API gateway, and sidecar placements for policy enforcement points and explains how to choose among them.

• Application-embedded PEP tradeoffs: Explain how an application-embedded PEP enforces an access decision and why its access to request context is useful but harder to manage across services.
  Why it matters: Placing the check in the application can improve contextual decisions while increasing coordination work across services.
• API gateway PEP tradeoffs: Describe what an API gateway PEP can enforce centrally and the limitation of its perimeter position.
  Why it matters: A central gateway can standardize checks, but it cannot necessarily make decisions that require details held inside an application.
• Sidecar PEP tradeoffs: Explain how a sidecar PEP supports service-to-service authorization and what operational challenges accompany it.
  Why it matters: Sidecars extend enforcement to traffic between services, provided their operational and context needs can be met.
• PEP placement selection: Justify choosing or combining PEP placements based on the system’s enforcement needs and tradeoffs.
  Why it matters: The right enforcement design depends on where checks are needed and what each placement can realistically support.

Key terms: Policy Enforcement Point (PEP), Policy Decision Point (PDP), inline access check, API gateway, perimeter, sidecar, service mesh, inbound and outbound traffic, microservice-to-microservice authorization, trust boundaries

4.5.2 Centralized PDPs

This section explains how application-specific enforcement points use a shared decision point, and the management benefits and reliability tradeoff of that arrangement.

• Shared PDP request flow: Trace how ACME’s applications use a centralized PDP: each application’s PEP forwards an access request to the shared PDP, which evaluates it against policies.
  Why it matters: This distinction identifies where requests originate and where authorization decisions are made.
• Central policy management benefits: Explain how updating a policy through the PAP affects the shared PDP and why that arrangement helps management, consistency, logging, and auditing.
  Why it matters: One policy update can affect decisions across applications without managing separate decision logic in each one.
• Shared decision service dependency: Explain the tradeoff of having all application PEPs depend on one PDP, particularly when the decision service is slow or unavailable.
  Why it matters: The management advantages of a shared PDP must be weighed against the effect of a slow or unavailable decision service.

Key terms: Policy Decision Point (PDP), Policy Enforcement Point (PEP), centralized PDP, single source of truth, Policy Administration Point (PAP), policy management, logging and auditing, latency, decision service, availability

4.5.3 Distributing authorization decisions

This section explains how services make authorization decisions locally, how policies and context reach them, and what to weigh when choosing a distributed architecture.

• Local authorization clients: Describe how a distributed authorization client combines a PEP, PDP, and local entity cache so a service can intercept requests, evaluate policy, and enforce outcomes locally. Give an example of where the client can be deployed.
  Why it matters: It shows what moves into each service when decisions no longer depend on a central PDP at runtime.
• Policy distribution and local context: Explain how centrally authored policies reach local PDPs and why those PDPs also need contextual data from PIPs. Describe what the entity cache stores and why it is refreshed.
  Why it matters: Local decisions can be fast only if each PDP has both the applicable policy and the context it needs.
• Distributed decision tradeoffs: Explain why moving PDPs closer to services can improve latency, resilience, and scalability, and identify the operational responsibilities this creates.
  Why it matters: The performance and availability gains are only useful if distributed decisions remain dependable.
• Architecture selection questions: Apply the field guide’s questions to describe how to choose an authorization deployment: consider enforcement location, decision proximity, context delivery, policy deployment, audit logging, and outages or staleness. Explain why the choice depends on the system’s goals rather than one universal pattern.
  Why it matters: These questions turn the architecture comparison into a practical deployment choice.

Key terms: authorization client, PEP, PDP, entity cache, API gateway, sidecar, PAP, PIP, contextual data, versioned policy management workflow

4.5.4 Choosing the right pattern

This section explains how to choose authorization architecture components for a system while preserving the same basic decision-and-enforcement flow.

• Architecture choices and tradeoffs: Explain why ACME uses centralized PDPs for some applications and distributed PDPs for others, and how it chooses where to place PEPs.
  Why it matters: The right arrangement depends on what each system needs, rather than on a single prescribed design.
• Shared authorization flow: Describe the authorization flow that remains the same across centralized, distributed, embedded, and sidecar-based arrangements.
  Why it matters: Different component placements need not change the fundamental work authorization performs.

Key terms: centralized PDPs, distributed PDPs, PEPs, trust boundary, context, policy, enforce the decision

4.5.5 Why this separation matters

This section explains why separating authorization enforcement, decisions, policy management, and data sourcing is safer and easier to manage than embedding access checks in applications.

• Limits of embedded access checks: Explain why hardcoded role checks and access logic embedded in applications become liabilities as systems grow more distributed, dynamic, and regulated.
  Why it matters: It explains the problem the separated architecture is meant to solve.
• Benefits of separated authorization concerns: Explain how separating the PEP, PDP, PAP, and PIP lets teams manage policies apart from application code and apply and trace authorization more consistently.
  Why it matters: A rule can become something teams change and audit independently, rather than a check buried in an application.
• Scalability and security advantages: Describe the scalability and security benefits the section attributes to separated authorization concerns.
  Why it matters: The separation supports growth and reduces the security consequences of mistakes.

Key terms: access logic, hardcoded role checks, authorization rules, Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Administration Point (PAP), Policy Information Point (PIP), maintainability, consistency, PDPs

4.6 From architecture to models

This section distinguishes authentication from an access decision and explains why contextual, distributed authorization needs a consistent structure.

• Identity versus access decisions: Explain why authenticating Alice does not establish whether she may see Team Reports, and identify the request details on which authorization depends.
  Why it matters: Recognizing someone is not the same as deciding what they may do.
• Structure for distributed authorization: Justify the need for a common vocabulary, a consistent decision model, and separation among authorization responsibilities as decisions become more contextual and distributed.
  Why it matters: A consistent structure makes access rules easier to inspect, change, and rely on.

Key terms: authentication, authorization, relationship, action, resource, conditions, common vocabulary, consistent decision model, enforcement, policy evaluation

4.7 Summary