4 Authorization: What can you do?

Authorization is presented as a distinct and critical layer of security that goes far beyond authentication. The chapter opens with the Ring incident to show that correctly verifying identity is not enough if the system cannot control what authenticated users are allowed to do. The main lesson is that authorization answers the harder question of whether a person, service, or device should be permitted to take a specific action on a specific resource under specific conditions, and that this question is continuous, contextual, and business-critical.

To make authorization understandable, the chapter introduces a shared vocabulary and the PARC model: principal, action, resource, and conditions. These concepts provide a practical way to describe access decisions, along with related terms such as roles, attributes, permissions, entitlements, policies, groups, and authorization requests and responses. The text emphasizes that access control is the broader discipline, while authorization is the enforcement mechanism that turns policy into runtime decisions based on identity and context.

The chapter then explains the reference architecture that underlies modern authorization systems, centered on the Policy Enforcement Point, Policy Decision Point, Policy Administration Point, and Policy Information Point. Using an ACME example, it shows how requests are intercepted, enriched with contextual data, evaluated against centrally managed policies, and then allowed or denied. It also compares deployment patterns such as embedding enforcement in applications, placing it in API gateways, or using sidecars and distributed authorization clients, arguing that the best choice depends on latency, availability, trust boundaries, and operational needs.

Relationships among key authorization terms. Principals, actions, and resources form the core of access decisions and are enriched with attributes, roles, and group memberships. All entities exist within namespaces and can be either principals or resources. The diagram also shows the legacy term subject as an older equivalent of principal and illustrates how actions operate on resources based on contextual and identity-based properties.

Authorization reference architecture showing how access decisions are made. The Policy Enforcement Point (PEP) intercepts Alice’s request to ACMEProject and sends it to the Policy Decision Point (PDP). The PDP evaluates the request using policies from the Policy Administration Point (PAP), managed by Carol, and retrieves context from the Policy Information Point (PIP), which sources attributes from systems such as identity providers, time servers, and network telemetry. The PDP returns a decision, which the PEP enforces in real time.

The Policy Enforcement Point (PEP) embedded in application code. In this model, the PEP is implemented directly within the ACMEProject backend, allowing it to evaluate access decisions with full visibility into the application’s internal state and context.

The Policy Enforcement Point (PEP) deployed in an API gateway. In this model, the PEP sits in front of ACMEProject, intercepting and evaluating access requests before they reach the application. This approach centralizes enforcement and simplifies policy updates across multiple services.

The Policy Enforcement Point (PEP) deployed as a sidecar. In this model, the PEP runs alongside the application, typically within the same container or virtual machine (VM). This approach ensures that policies are enforced locally at the service level without altering the core application architecture.

Centralized authorization architecture at ACME Corp. Multiple application-specific PEPs send access requests to a shared PDP, which evaluates them using policies Carol authored and manages in the PAP. This approach centralizes decision-making and simplifies policy updates, but it introduces potential availability concerns.

Distributed authorization architecture at ACME Corp. Each service includes an authorization client, a bundled component that contains the PEP, PDP, and an entity cache. The client may be deployed as a sidecar (ACMEFinance), as a library within application code (ACMEProject), or integrated into an API gateway (ACMEHR). Policies are authored and managed by Carol via the Policy Administration Point (PAP) and then distributed to each client. Contextual data is retrieved from shared PIPs, such as identity stores, time servers, and network telemetry, and is cached inside the client.

• Authorization defines what an authenticated principal can do, under which conditions, and with which resources. This discipline is separate from authentication and plays a crucial role in security, compliance, and user experience.
• Authorization not only protects resources but also governs interactions between entities based on the terms of their digital relationships.
• The PARC model—principal, action, resource, and conditions—offers a clear and flexible framework for describing access decisions.
• Terms such as policy, role, attribute, and entitlement form the foundation of modern authorization systems and foster a shared understanding across teams.
• The authorization reference architecture delineates the responsibilities of enforcement, decision-making, policy management, and context retrieval, thereby improving system maintainability, auditability, and security.
• Deployment patterns vary depending on system architecture. PEPs, PDPs, and entity caches can be embedded, centralized, or distributed based on performance, trust boundaries, and operational requirements.
• Separating concerns among PEPs, PDPs, PAPs, and PIPs allows systems to scale, maintain consistency, and respond flexibly to evolving business and regulatory needs.

FAQ