What will I learn in chapter 8 of Authorization in Action?

ACME’s changing needs introduce four authorization approaches and show why PARC is useful for comparing their tradeoffs rather than declaring one winner. After reading it you should be able to: Explain why ACME used different authorization systems as its needs expanded, connecting XACML, OPA/Rego, OpenFGA, and AWS IAM to the settings described here. Explain how XACML offered a separate, declarative policy language when authorization rules were often embedded in applications or tied to specific products. Explain why XACML struggled to gain traction and which ideas nevertheless influenced later authorization approaches. Explain how the example rule permits access to a confidential document when the requester is in the same department as its owner, and distinguish the roles of the Target, Rule, and rule-combining algorithm. Explain why ALFA was introduced and how it relates to standard XACML policies. Describe how XACML represents each part of PARC in an access request and uses those attributes in policies. Explain why XACML’s attribute-based approach is expressive but leaves policy authors responsible for much of the domain model. Explain how XACML influenced later authorization approaches despite seldom being used in new systems: it separated enforcement from decision logic and helped shape attribute-based access control.

What does section 8.1, XACML: The first policy language standard, cover?

Introduces XACML as an early standard for separate authorization policies and decision architecture, while explaining why its practical adoption lagged despite its lasting influence. Explain how XACML offered a separate, declarative policy language when authorization rules were often embedded in applications or tied to specific products. Describe XACML’s contribution beyond policy syntax: an architecture for evaluating and enforcing authorization decisions that included PDPs and PEPs. Explain why XACML struggled to gain traction and which ideas nevertheless influenced later authorization approaches.

What does section 8.1.1, A XACML simple example, cover?

This section uses a confidential-document example to explain basic XACML policy structure and evaluation, then shows how ALFA makes XACML policies easier to write without changing their meaning. Explain how the example rule permits access to a confidential document when the requester is in the same department as its owner, and distinguish the roles of the Target, Rule, and rule-combining algorithm. Describe what the PEP sends to the PDP to evaluate the example, and state what the shown policies leave unresolved for nonconfidential documents. Explain why ALFA was introduced and how it relates to standard XACML policies.

What does section 8.1.2, Applying the PARC model to XACML, cover?

The section maps XACML onto PARC and explains the strengths, modeling costs, and developer-experience limits of its attribute-based approach. Describe how XACML represents each part of PARC in an access request and uses those attributes in policies. Explain why XACML’s attribute-based approach is expressive but leaves policy authors responsible for much of the domain model. Explain why developer experience, rather than the attribute model alone, was the biggest barrier to XACML adoption.

What does section 8.1.3, Legacy and lessons, cover?

This section explains XACML’s lasting influence and the usability lesson ACME drew from its legacy deployment. Explain how XACML influenced later authorization approaches despite seldom being used in new systems: it separated enforcement from decision logic and helped shape attribute-based access control. Explain why ACME left its XACML document-archive policies largely untouched and what that taught it about centralized policy.

What does section 8.2, OPA and Rego: Policy for cloud-native systems, cover?

This section introduces OPA as a flexible policy engine for distributed systems and Rego as the language it evaluates. Explain why ACME turned to OPA and how its embeddable decision engine supports policies across cloud-native systems beyond access control. Describe Rego’s relationship to OPA, what its rules express, what inputs they use, and the tradeoff noted for its code-like style.

What does section 8.2.1, Rego policies example, cover?

The section illustrates a Rego rule for confidential-document access and explains why its Cedar equivalent has nearly the same logic. Explain that the example Rego policy allows access only when the document is confidential and the requesting principal is in the same department as its owner. Explain why the equivalent Cedar policy has almost the same logic as the Rego example: Cedar’s scoping features are not used, so the condition block fully determines the access decision.

What does section 8.2.2, Comparing Rego with Cedar, cover?

This section contrasts how Rego and Cedar express policy scope and explains why Cedar’s structural scoping helps evaluation and auditing. Distinguish how Rego and Cedar express constraints on principals, actions, and resources. Explain that Cedar places scope in the policy structure, while Rego expresses those constraints as conditions in the rule body. Explain how Cedar uses declared scope to narrow the policies evaluated for a request, and describe the resulting benefits identified in this section.

What does section 8.2.3, Applying the PARC model to OPA and Rego, cover?

This section maps the PARC model onto OPA and Rego’s user-defined inputs and explains the benefits and costs of that flexibility. Describe how Rego policies represent principals, actions, resources, and context, including what the policy author must define. Explain why Rego’s general-purpose flexibility is useful and why it requires careful policy writing and testing for detailed authorization.

What does section 8.2.4, Strengths and limitations, cover?

This section weighs OPA and Rego’s usefulness for infrastructure policy against the complexity and maintainability concerns some teams encounter when using them for access control. Explain why OPA and Rego suited ACME’s DevOps team: their policies were portable, testable, and independent of the applications they protected, while Rego could express logic over arbitrary data. Explain why expanding OPA use raised concerns: Rego’s logic programming model can be hard to learn and can produce correct but hard-to-maintain policies; without structure or types, validation, analysis, and testing become critical. Describe why some access-control teams consequently preferred a language expressly designed for authorization.

What does section 8.3, OpenFGA, cover?

This section introduces OpenFGA as a relationship-based way to handle ACME’s dynamic document-sharing permissions. Explain how OpenFGA represents and evaluates permissions using relationships among entities. Justify why relationship-based permissions suited ACME’s Customer Collaboration platform better than roles or attributes alone.

What does section 8.3.1, How OpenFGA works, cover?

The section explains how OpenFGA defines permissions through a schema and stored relationships, then checks access by applying the schema’s rules to a relationship graph. Explain how OpenFGA represents access policy as relationships rather than complex policy code, and describe the schema’s types, relations, and permissions. Trace how stored relationship tuples are used to answer a permission request. Distinguish OpenFGA’s relationship-based checks from evaluation of conditional logic or request attributes, and state where the section says this approach is useful.

What does section 8.3.2, Document access example, cover?

The section uses a document-access example to show how OpenFGA follows stored relationships to decide access and adapts when those relationships change. Explain how OpenFGA defines document access using viewer, owner, and manager relationships, including what owner->manager means. Trace why Carol’s access check for doc1 returns true using the stored facts about Alice and Carol. Explain why changing the relationship graph can change access without changing the access rule.

What should I know before reading chapter 8?

Beyond one-size-fits-all (chapter 6): Builds on the idea that authorization needs do not have a one-size-fits-all solution.; The PARC model (chapter 4): Assumes the previously introduced PARC model as a way to describe authorization.; Authorization reference architecture (chapter 4): The authorization reference architecture introduced earlier.; Policy structure: Effect, scope, and conditions (chapter 7): Assumes familiarity with policy scope and conditions.; How access decisions are made (chapter 4): Assumes the roles of the PEP and PDP in an access decision.; Cedar’s representation of PARC (chapter 7): Uses the PARC categories for describing an authorization request.; How ABAC works (chapter 6): Introduces attribute-based access control as an authorization model.; Attribute-based access control (chapter 6): Introduces attribute-based access control.

Chapter 8: Policy languages and frameworks

What you will learn in chapter 8 of Authorization in Action

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

After this chapter you will be able to

Authorization approaches for different needs. Explain why ACME used different authorization systems as its needs expanded, connecting XACML, OPA/Rego, OpenFGA, and AWS IAM to the settings described here.
XACML policy standardization. Explain how XACML offered a separate, declarative policy language when authorization rules were often embedded in applications or tied to specific products.
Adoption barriers and legacy. Explain why XACML struggled to gain traction and which ideas nevertheless influenced later authorization approaches.
XACML policy structure. Explain how the example rule permits access to a confidential document when the requester is in the same department as its owner, and distinguish the roles of the Target, Rule, and rule-combining algorithm.
ALFA as XACML syntax. Explain why ALFA was introduced and how it relates to standard XACML policies.
XACML’s PARC attribute mapping. Describe how XACML represents each part of PARC in an access request and uses those attributes in policies.
Expressiveness and modeling costs. Explain why XACML’s attribute-based approach is expressive but leaves policy authors responsible for much of the domain model.
XACML’s lasting influence. Explain how XACML influenced later authorization approaches despite seldom being used in new systems: it separated enforcement from decision logic and helped shape attribute-based access control.
ACME’s centralized policy lesson. Explain why ACME left its XACML document-archive policies largely untouched and what that taught it about centralized policy.
OPA’s distributed policy role. Explain why ACME turned to OPA and how its embeddable decision engine supports policies across cloud-native systems beyond access control.
Rego rules and inputs. Describe Rego’s relationship to OPA, what its rules express, what inputs they use, and the tradeoff noted for its code-like style.
Confidential document access rule. Explain that the example Rego policy allows access only when the document is confidential and the requesting principal is in the same department as its owner.
Rego and Cedar policy scope. Distinguish how Rego and Cedar express constraints on principals, actions, and resources. Explain that Cedar places scope in the policy structure, while Rego expresses those constraints as conditions in the rule body.
Cedar structural filtering benefits. Explain how Cedar uses declared scope to narrow the policies evaluated for a request, and describe the resulting benefits identified in this section.
PARC in Rego inputs. Describe how Rego policies represent principals, actions, resources, and context, including what the policy author must define.
Flexibility and correctness tradeoff. Explain why Rego’s general-purpose flexibility is useful and why it requires careful policy writing and testing for detailed authorization.
Portable infrastructure policies. Explain why OPA and Rego suited ACME’s DevOps team: their policies were portable, testable, and independent of the applications they protected, while Rego could express logic over arbitrary data.
Rego complexity and fit. Explain why expanding OPA use raised concerns: Rego’s logic programming model can be hard to learn and can produce correct but hard-to-maintain policies; without structure or types, validation, analysis, and testing become critical. Describe why some access-control teams consequently preferred a language expressly designed for authorization.
Relationship graph permissions. Explain how OpenFGA represents and evaluates permissions using relationships among entities.
Relationships as policy data. Explain how OpenFGA represents access policy as relationships rather than complex policy code, and describe the schema’s types, relations, and permissions.
Tuple graph access checks. Trace how stored relationship tuples are used to answer a permission request.
Document access relationship rule. Explain how OpenFGA defines document access using viewer, owner, and manager relationships, including what owner->manager means.
Tuple-based access check. Trace why Carol’s access check for doc1 returns true using the stored facts about Alice and Carol.
OpenFGA relationship-based PARC mapping. Explain how OpenFGA represents principals and resources as typed objects connected by relationship tuples, and treats actions as named permission checks defined over those relationships.
OpenFGA context and suitability. Describe how OpenFGA handles contextual factors and explain when its relationship-centered approach is a good fit.
AWS IAM scope and reach. Describe IAM as the system developers use to manage access to AWS services, and explain why many developers encounter it as a policy language despite its AWS-only scope.
IAM request evaluation. Explain that AWS considers all relevant IAM policies before allowing or denying a request, and that deny rules override allow rules.
AWS-specific permission elements. Describe how IAM policies refer to principals, actions, resources, and context using AWS-specific identities, API calls, ARNs, and request information.
Confidential document access condition. Explain when ACME’s IAM policy grants read access to a confidential document and how IAM compares the requester’s department with the document’s owner-department tag.
AWS IAM PARC mapping. Describe how IAM represents each PARC element: AWS identities as principals, service API operations as actions, ARN-identified AWS objects as resources, and condition keys as context.
AWS specificity and portability. Explain why IAM’s AWS-specific PARC model gives precise, integrated control but is less portable, using ACME’s S3 document access as an example.
Contextual authorization system choice. Explain why the right authorization system depends on the problem being addressed, the working environment, and the implementing team’s skills.
XACML’s attribute-based PARC representation. Describe how XACML represents the principal, action, resource, and context using attributes, including what it lacks for identities and resources.
XACML strengths and tradeoffs. Explain why XACML can suit compliance-focused environments yet has seen limited developer adoption in modern development.
Flexibility and maintenance tradeoff. Explain why Rego is useful across cloud-native infrastructure and why that flexibility can make authorization policies harder to manage.
Relationship-Based Access Model. Explain how OpenFGA represents access through relationships among principals, groups, resources, and permissions, and identify the kinds of access decisions this suits.
AWS IAM PARC mapping. Describe how AWS IAM represents principals, actions, resources, and context: users, roles, or federated identities; service-specific API operations; AWS objects identified by ARNs; and global or service-specific condition keys.
AWS integration and boundary. Explain that IAM offers fine-grained, context-aware authorization with mature tooling and large-scale AWS integration, but is not applicable outside AWS.
Cedar capabilities and tradeoff. Explain how Cedar combines typed principals, actions, and resources with structural policy scoping and support for attributes, relationships, and context. Describe its portability and embeddability, while noting that its newer ecosystem has fewer integrations than OPA.
AuthZEN decision interface. Distinguish AuthZEN from a policy language or engine: explain that it standardizes how a PEP asks a PDP about a principal, action, resource, and context and receives a decision. Describe why a common decision API can work with different engines.
Problem-led framework selection. Explain how to narrow a policy language or framework choice by starting with the authorization problems an organization faces, then considering its model, enforcement setting, portability needs, policy authors, complexity tolerance, performance requirements, and developer experience. Describe how the PARC model and strength map help turn those considerations into a practical choice.

liveBook manning.com

Read chapter 8 on liveBook Get the book at manning.com

What it builds on

Beyond one-size-fits-all (chapter 6) · Builds on the idea that authorization needs do not have a one-size-fits-all solution.
The PARC model (chapter 4) · Assumes the previously introduced PARC model as a way to describe authorization.
Authorization reference architecture (chapter 4) · The authorization reference architecture introduced earlier.
Policy structure: Effect, scope, and conditions (chapter 7) · Assumes familiarity with policy scope and conditions.
How access decisions are made (chapter 4) · Assumes the roles of the PEP and PDP in an access decision.
Cedar’s representation of PARC (chapter 7) · Uses the PARC categories for describing an authorization request.
How ABAC works (chapter 6) · Introduces attribute-based access control as an authorization model.
Attribute-based access control (chapter 6) · Introduces attribute-based access control.

Section by section

Introduction

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

Authorization approaches for different needs: Explain why ACME used different authorization systems as its needs expanded, connecting XACML, OPA/Rego, OpenFGA, and AWS IAM to the settings described here.
Why it matters: The right policy approach depends on the system’s requirements and the structure the team needs to manage.
PARC as a comparison lens: Explain the purpose of using PARC to compare these policy approaches without treating the comparison as a search for a single winner.
Why it matters: A common lens makes unlike policy systems easier to compare while keeping their different purposes in view.

Key terms: XACML, OPA, Rego, OpenFGA, AWS IAM, relationship graph, PARC, externalize authorization logic, tradeoffs

8.1 XACML: The first policy language standard

Introduces XACML as an early standard for separate authorization policies and decision architecture, while explaining why its practical adoption lagged despite its lasting influence.

XACML policy standardization: Explain how XACML offered a separate, declarative policy language when authorization rules were often embedded in applications or tied to specific products.
Why it matters: This explains the problem XACML was designed to address.
XACML decision architecture: Describe XACML’s contribution beyond policy syntax: an architecture for evaluating and enforcing authorization decisions that included PDPs and PEPs.
Why it matters: XACML’s influence extends beyond its policy language to the architecture used to discuss authorization.
Adoption barriers and legacy: Explain why XACML struggled to gain traction and which ideas nevertheless influenced later authorization approaches.
Why it matters: It distinguishes XACML’s limited practical uptake from the lasting value of its ideas.

Key terms: XACML, declarative language, authorization policy, authorization reference architecture, Policy Decision Points (PDPs), Policy Enforcement Points (PEPs), XML syntax, centralized policy evaluation, structured decision logic, separation of enforcement and decision

8.1.1 A XACML simple example

This section uses a confidential-document example to explain basic XACML policy structure and evaluation, then shows how ALFA makes XACML policies easier to write without changing their meaning.

XACML policy structure: Explain how the example rule permits access to a confidential document when the requester is in the same department as its owner, and distinguish the roles of the Target, Rule, and rule-combining algorithm.
Why it matters: These parts let you read what an XACML policy applies to and how it reaches a result.
XACML evaluation request and boundary: Describe what the PEP sends to the PDP to evaluate the example, and state what the shown policies leave unresolved for nonconfidential documents.
Why it matters: The example only makes sense when you distinguish the information sent for evaluation from decisions the shown policies do not cover.
ALFA as XACML syntax: Explain why ALFA was introduced and how it relates to standard XACML policies.
Why it matters: ALFA offers easier policy authoring without requiring organizations to abandon XACML-compatible engines.

Key terms: XACML, <Target/>, <Rule/>, RuleCombiningAlgId, PEP, PDP, subject, resource, action, environment conditions

8.1.2 Applying the PARC model to XACML

The section maps XACML onto PARC and explains the strengths, modeling costs, and developer-experience limits of its attribute-based approach.

XACML’s PARC attribute mapping: Describe how XACML represents each part of PARC in an access request and uses those attributes in policies.
Why it matters: This mapping lets you recognize what an XACML policy is evaluating when it makes an access decision.
Expressiveness and modeling costs: Explain why XACML’s attribute-based approach is expressive but leaves policy authors responsible for much of the domain model.
Why it matters: It explains both why XACML can express varied access rules and why managing those rules can become difficult.
Developer experience adoption barrier: Explain why developer experience, rather than the attribute model alone, was the biggest barrier to XACML adoption.
Why it matters: It shows why a capable policy language may still be hard for development teams to adopt.

Key terms: PARC, subject, action:id, resource:id, environment, <Target/>, attribute-based access control, typed object models, relationships, profiles

8.1.3 Legacy and lessons

This section explains XACML’s lasting influence and the usability lesson ACME drew from its legacy deployment.

XACML’s lasting influence: Explain how XACML influenced later authorization approaches despite seldom being used in new systems: it separated enforcement from decision logic and helped shape attribute-based access control.
Why it matters: XACML’s ideas can remain useful even when its language is not the choice for a new system.
ACME’s centralized policy lesson: Explain why ACME left its XACML document-archive policies largely untouched and what that taught it about centralized policy.
Why it matters: Centralizing policy is not enough if developers cannot safely maintain it.

Key terms: XACML, enforcement, decision logic, ABAC, ACME, centralized policy, accessible, flexible

8.2 OPA and Rego: Policy for cloud-native systems

This section introduces OPA as a flexible policy engine for distributed systems and Rego as the language it evaluates.

OPA’s distributed policy role: Explain why ACME turned to OPA and how its embeddable decision engine supports policies across cloud-native systems beyond access control.
Why it matters: OPA’s broader scope explains why it appealed to ACME as its systems became more distributed.
Rego rules and inputs: Describe Rego’s relationship to OPA, what its rules express, what inputs they use, and the tradeoff noted for its code-like style.
Why it matters: Distinguishing the engine from its language makes the upcoming policy examples easier to follow.

Key terms: Open Policy Agent, OPA, decision engine, cloud-native applications, Rego, declarative, logic-based, JSON data structures

8.2.1 Rego policies example

The section illustrates a Rego rule for confidential-document access and explains why its Cedar equivalent has nearly the same logic.

Confidential document access rule: Explain that the example Rego policy allows access only when the document is confidential and the requesting principal is in the same department as its owner.
Why it matters: The example shows how the policy’s conditions determine whether access is allowed.
Rego and Cedar condition logic: Explain why the equivalent Cedar policy has almost the same logic as the Rego example: Cedar’s scoping features are not used, so the condition block fully determines the access decision.
Why it matters: It identifies why these two examples look similar without implying that Rego and Cedar always work the same way.

Key terms: Rego policy, confidential, requesting principal, department, Cedar, scoping features, condition block

8.2.2 Comparing Rego with Cedar

This section contrasts how Rego and Cedar express policy scope and explains why Cedar’s structural scoping helps evaluation and auditing.

Rego and Cedar policy scope: Distinguish how Rego and Cedar express constraints on principals, actions, and resources. Explain that Cedar places scope in the policy structure, while Rego expresses those constraints as conditions in the rule body.
Why it matters: The distinction helps you read what a policy applies to, not just the conditions it checks.
Cedar structural filtering benefits: Explain how Cedar uses declared scope to narrow the policies evaluated for a request, and describe the resulting benefits identified in this section.
Why it matters: Filtering by scope matters most when a system has many different policies to evaluate.

Key terms: Rego, Cedar, policy scope, rule body, policy head, structural filtering, prefilter, condition logic

8.2.3 Applying the PARC model to OPA and Rego

This section maps the PARC model onto OPA and Rego’s user-defined inputs and explains the benefits and costs of that flexibility.

PARC in Rego inputs: Describe how Rego policies represent principals, actions, resources, and context, including what the policy author must define.
Why it matters: This mapping helps you recognize where access-decision data comes from in a Rego policy.
Flexibility and correctness tradeoff: Explain why Rego’s general-purpose flexibility is useful and why it requires careful policy writing and testing for detailed authorization.
Why it matters: The same freedom that suits complex infrastructure decisions can make authorization mistakes easier to introduce.

Key terms: PARC, input.principal, input.action, input.resource, context, general-purpose, schema enforcement, scoping, rule bodies, infrastructure policy

8.2.4 Strengths and limitations

This section weighs OPA and Rego’s usefulness for infrastructure policy against the complexity and maintainability concerns some teams encounter when using them for access control.

Portable infrastructure policies: Explain why OPA and Rego suited ACME’s DevOps team: their policies were portable, testable, and independent of the applications they protected, while Rego could express logic over arbitrary data.
Why it matters: These strengths explain why ACME’s DevOps team found OPA useful for infrastructure policy.
Rego complexity and fit: Explain why expanding OPA use raised concerns: Rego’s logic programming model can be hard to learn and can produce correct but hard-to-maintain policies; without structure or types, validation, analysis, and testing become critical. Describe why some access-control teams consequently preferred a language expressly designed for authorization.
Why it matters: A policy language can be powerful yet still be a difficult fit for a team’s access-control work.

Key terms: OPA, Rego, infrastructure policy, portable, testable, logic programming model, structure, types, validation, analysis

8.3 OpenFGA

This section introduces OpenFGA as a relationship-based way to handle ACME’s dynamic document-sharing permissions.

Relationship graph permissions: Explain how OpenFGA represents and evaluates permissions using relationships among entities.
Why it matters: This is the basic idea behind OpenFGA’s approach to access decisions.
ACME’s relationship modeling need: Justify why relationship-based permissions suited ACME’s Customer Collaboration platform better than roles or attributes alone.
Why it matters: ACME’s example shows why modeling connections can be more useful than hard-coding complex sharing logic.

Key terms: OpenFGA, relationship-based access control (ReBAC), schema, relationship graph, Customer Collaboration platform, fine-grained sharing, relationships

8.3.1 How OpenFGA works

The section explains how OpenFGA defines permissions through a schema and stored relationships, then checks access by applying the schema’s rules to a relationship graph.

Relationships as policy data: Explain how OpenFGA represents access policy as relationships rather than complex policy code, and describe the schema’s types, relations, and permissions.
Why it matters: This is the basic model behind an OpenFGA access decision.
Tuple graph access checks: Trace how stored relationship tuples are used to answer a permission request.
Why it matters: It connects a concrete relationship fact to the access answer OpenFGA returns.
Relationship logic boundary: Distinguish OpenFGA’s relationship-based checks from evaluation of conditional logic or request attributes, and state where the section says this approach is useful.
Why it matters: This boundary helps explain when OpenFGA’s approach fits an application.

Key terms: policy as data, schema, types, relations, permissions, tuples, directed graph, schema rules, requested permission, conditional logic

8.3.2 Document access example

The section uses a document-access example to show how OpenFGA follows stored relationships to decide access and adapts when those relationships change.

Document access relationship rule: Explain how OpenFGA defines document access using viewer, owner, and manager relationships, including what owner->manager means.
Why it matters: This is the rule OpenFGA evaluates instead of imperative access-checking code.
Tuple-based access check: Trace why Carol’s access check for doc1 returns true using the stored facts about Alice and Carol.
Why it matters: The example makes the relationship path behind a concrete access decision visible.
Access through updated relationships: Explain why changing the relationship graph can change access without changing the access rule.
Why it matters: Keeping relationship facts current lets the same rule handle changes in who manages whom.

Key terms: can_access, viewer, owner, manager, owner->manager, tuple, permission check, relationship graph, delegation, ACLs

8.3.3 Applying the PARC model to OpenFGA

Maps OpenFGA’s relationship-based authorization to PARC, explains its limits with contextual conditions, and introduces Topaz as a way to combine relationships with Rego policies.

OpenFGA relationship-based PARC mapping: Explain how OpenFGA represents principals and resources as typed objects connected by relationship tuples, and treats actions as named permission checks defined over those relationships.
Why it matters: This mapping shows what an OpenFGA access check actually depends on.
OpenFGA context and suitability: Describe how OpenFGA handles contextual factors and explain when its relationship-centered approach is a good fit.
Why it matters: It helps distinguish access rules OpenFGA can express directly from conditions an application must handle elsewhere.
Topaz combined authorization model: Explain how Topaz combines Rego policy evaluation with a relationship directory to support both context-rich rules and relationship-based access.
Why it matters: It illustrates one way to address the gap between relationship checks and context-rich policy rules.

Key terms: PARC, principal, action, resource, relationship tuples, schema, context, relationships, time-based access, security posture

8.4 AWS IAM

Introduces AWS IAM as an AWS-specific authorization system notable for its widespread use and scale.

AWS IAM scope and reach: Describe IAM as the system developers use to manage access to AWS services, and explain why many developers encounter it as a policy language despite its AWS-only scope.
Why it matters: IAM’s reach makes it an important policy language to recognize, even though it applies to just one cloud.

Key terms: AWS Identity and Access Management, IAM, policy language

8.4.1 How IAM works

This section explains how AWS IAM represents permissions, evaluates requests, and trades portability for close integration with AWS.

IAM request evaluation: Explain that AWS considers all relevant IAM policies before allowing or denying a request, and that deny rules override allow rules.
Why it matters: A permission in one policy alone does not establish that a request will be allowed.
AWS-specific permission elements: Describe how IAM policies refer to principals, actions, resources, and context using AWS-specific identities, API calls, ARNs, and request information.
Why it matters: These mappings make an IAM permission concrete in terms of an AWS request.
AWS integration tradeoff: Explain why IAM's close alignment with AWS enables fine-grained, relatively unambiguous permissions while limiting IAM to the AWS environment.
Why it matters: The benefit and limitation come from the same close fit to AWS.

Key terms: identity-based policies, resource-based policies, service control policies (SCPs), session policies, permission boundaries, deny rules, principals, actions, AWS API calls, resources

8.4.2 Example: Confidential document access

ACME’s example shows how AWS IAM uses identity and S3 object tags to control access to confidential documents by department.

Principal and document tag sources: Trace how ACME obtains the department tag on a requester’s AWS session and the owner-department and confidential tags on an uploaded S3 object.
Why it matters: The access rule depends on having comparable department values on the requester and the document.
Confidential document access condition: Explain when ACME’s IAM policy grants read access to a confidential document and how IAM compares the requester’s department with the document’s owner-department tag.
Why it matters: This shows how an IAM policy can enforce a fine-grained access rule using attributes without listing individual users or documents.

Key terms: Identity Center, corporate directory, principal tag, owner-department, confidential, s3:GetObject, Condition block, aws:PrincipalTag/department, ${s3:ExistingObjectTag/owner-department}, policy variable

8.4.3 Applying the PARC model to AWS IAM

This section maps the PARC model to AWS IAM and explains how IAM’s AWS-specific design enables precise access control while limiting portability.

AWS IAM PARC mapping: Describe how IAM represents each PARC element: AWS identities as principals, service API operations as actions, ARN-identified AWS objects as resources, and condition keys as context.
Why it matters: The PARC mapping makes an IAM policy easier to interpret as an access decision.
AWS specificity and portability: Explain why IAM’s AWS-specific PARC model gives precise, integrated control but is less portable, using ACME’s S3 document access as an example.
Why it matters: This tradeoff helps explain when AWS-native authorization is useful and what it cannot readily carry to another environment.

Key terms: Principal, Action, Resource, Context, ARNs, condition keys, domain-specific design, attribute-based access, principal and resource tags, portability

8.5 Comparing policy languages

The section frames the comparison of policy languages around choosing an authorization system that fits the situation.

Contextual authorization system choice: Explain why the right authorization system depends on the problem being addressed, the working environment, and the implementing team’s skills.
Why it matters: These factors give you a basis for comparing approaches rather than looking for a universal winner.

Key terms: authorization system, policy

8.5.1 XACML

This subsection compares XACML’s attribute-based representation of access requests with its strengths and limitations as a policy language.

XACML’s attribute-based PARC representation: Describe how XACML represents the principal, action, resource, and context using attributes, including what it lacks for identities and resources.
Why it matters: This gives you a common way to compare XACML with the other policy languages in the chapter.
XACML strengths and tradeoffs: Explain why XACML can suit compliance-focused environments yet has seen limited developer adoption in modern development.
Why it matters: These tradeoffs help explain when XACML is a reasonable choice and why teams may consider alternatives.

Key terms: Principal, Action, Resource, Context, attributes, ABAC, externalized authorization, XML, PDP/PEP architecture, compliance-focused environments

8.5.2 OPA/Rego

This section compares OPA/Rego’s flexibility across infrastructure with the work and complexity of defining authorization concepts yourself.

Flexibility and maintenance tradeoff: Explain why Rego is useful across cloud-native infrastructure and why that flexibility can make authorization policies harder to manage.
Why it matters: The same flexibility that makes Rego useful in many settings affects the effort needed to author and maintain its policies.
Rego authorization inputs: Describe how principals, actions, resources, and context are represented in the section’s OPA/Rego comparison.
Why it matters: These representations show concretely what Rego’s flexibility means for an authorization request.

Key terms: Rego, general-purpose policy language, manual scoping, principal, action, resource, context, input, data

8.5.3 OpenFGA

This subsection compares OpenFGA’s relationship-based model with approaches that depend on attributes or runtime context.

Relationship-Based Access Model: Explain how OpenFGA represents access through relationships among principals, groups, resources, and permissions, and identify the kinds of access decisions this suits.
Why it matters: This helps you recognize when a relationship-based policy system matches an application’s access needs.
Contextual Decision Limits: Distinguish OpenFGA’s strength in relationship-rich applications from its limitations for runtime-context or fine-grained attribute-based decisions.
Why it matters: The distinction prevents a good fit for sharing and delegation from being mistaken for a complete solution to every access decision.

Key terms: OpenFGA, relationship-based authorization, relationship tuples, named permissions, typed objects, context, fine-grained, attribute-based authorization decisions, contextual decisions

8.5.4 AWS IAM

This subsection maps AWS IAM to the PARC model and summarizes its strengths and AWS-only limitation.

AWS IAM PARC mapping: Describe how AWS IAM represents principals, actions, resources, and context: users, roles, or federated identities; service-specific API operations; AWS objects identified by ARNs; and global or service-specific condition keys.
Why it matters: The PARC mapping makes IAM comparable with the other policy languages in this chapter.
AWS integration and boundary: Explain that IAM offers fine-grained, context-aware authorization with mature tooling and large-scale AWS integration, but is not applicable outside AWS.
Why it matters: IAM’s capabilities and platform boundary both matter when choosing an authorization approach.

Key terms: Principal, Action, Resource, Context, ARNs, condition keys, AWS IAM, fine-grained, context-aware, AWS-specific

8.5.5 Cedar

Compares Cedar’s capabilities and tradeoff with other policy systems, then explains how AuthZEN standardizes authorization requests independently of the policy engine.

Cedar capabilities and tradeoff: Explain how Cedar combines typed principals, actions, and resources with structural policy scoping and support for attributes, relationships, and context. Describe its portability and embeddability, while noting that its newer ecosystem has fewer integrations than OPA.
Why it matters: These distinctions help you judge where Cedar fits among the chapter’s policy systems.
AuthZEN decision interface: Distinguish AuthZEN from a policy language or engine: explain that it standardizes how a PEP asks a PDP about a principal, action, resource, and context and receives a decision. Describe why a common decision API can work with different engines.
Why it matters: A standard decision interface lets enforcement points ask for authorization without depending on one engine’s request format.

Key terms: Cedar, schema-based type checking, structural policy scoping, portable runtime, AuthZEN, Policy Enforcement Point (PEP), Policy Decision Point (PDP), PARC model, decision API

8.5.6 From strengths to selection

This section turns a comparison of policy languages and frameworks into a practical, problem-led way to select one.

Problem-led framework selection: Explain how to narrow a policy language or framework choice by starting with the authorization problems an organization faces, then considering its model, enforcement setting, portability needs, policy authors, complexity tolerance, performance requirements, and developer experience. Describe how the PARC model and strength map help turn those considerations into a practical choice.
Why it matters: A selection method grounded in your actual needs is more useful than picking the framework with the longest feature list.
Framework fit examples: Describe the section’s examples of matching particular needs to IAM, OpenFGA, Cedar, OPA/Rego, or ALFA with XACML.
Why it matters: These examples show what it means to match a framework’s strengths to a concrete authorization problem.

Key terms: PARC model, strength map, authorization models, portability, developer experience, AWS IAM, OpenFGA, Cedar, OPA/Rego, ALFA

8.6 Summary

Where this is used later

From primer to practice (chapter 9) · The comparison of policy-language strengths when selecting a language.

Concepts explained in this chapter

RegoRego is a declarative policy language used to express rules evaluated by policy engines such as Open Policy Agent.
XACMLXACML is an OASIS standard for representing authorization policies and defining a model for evaluating access-control decisions.
OpenFGAOpenFGA is an open-source authorization system for evaluating permissions through relationships among users and resources.
contextContext is the current information and attributes surrounding an access request that can affect an authorization decision.
relationship-based access controlA relationship permission is an access rule or authorization pattern in which permission depends on an authorization-relevant relationship between entities.
graphA relationship graph is a graph representation of entities and the relationships connecting them, including authorization-relevant relationships.
AWS Identity and Access ManagementAWS Identity and Access Management is a managed AWS service for controlling access to AWS resources through identities, policies, and conditions.
Open Policy AgentOpen Policy Agent is an open-source policy engine that evaluates declarative policies to make authorization and other policy decisions.
attribute-based access controlAttribute-based access control (ABAC) is an authorization approach that makes decisions by evaluating attributes of subjects, resources, actions, and contextual conditions against rules.
relationship tupleA relationship tuple is a structured record identifying a relationship between a subject and a typed object in a relationship-based authorization system.
conditionA condition is a contextual requirement that determines whether an authorization request is permitted or denied.
CedarCedar is a policy language designed specifically for expressing authorization policies and evaluating access-control logic.
policy languageA policy language is a formal language whose syntax and semantics allow authorization policies to be represented and processed by software.
PARC modelThe PARC model is an authorization framework that describes an access decision using a principal, action, resource, and conditions or context.
actionAn action is an operation that a principal attempts to perform on a resource.
schemaA schema is a formal description of the structure, types, and constraints of data stored or exchanged by a system, including Cedar entity types, attributes, actions, and context.
authorizationAuthorization is the process of determining and enforcing what an authenticated identity is permitted to access or do.
attributeAn identity attribute is a piece of information describing an entity in a digital identity system.
authorization requestAn authorization request is a structured query asking whether a principal may perform an action on a resource under specified conditions.
subjectA subject is the entity referred to in an account, policy, or authorization decision, potentially referring to a principal or resource.
ZanzibarZanzibar is Google's globally scalable authorization system that evaluates access through a graph of relationships among users, resources, and other entities.
edgeA relationship edge is a graph connection that records an association between entities or between an entity and a resource.
resource-based access controlA resource-based policy is an authorization policy attached to a resource that specifies which principals may access it and under what conditions.
principalA principal is an entity, such as a person, machine, or process, that can initiate an action in an authorization system.
policy enforcement pointAn enforcement point is a system component or boundary at which an authorization decision is applied to allow or prevent an operation.
scopeA scope is the policy element that identifies the principals, actions, and resources to which a policy applies.
authorization modelAn authorization model is a conceptual scheme for representing authority and determining how permissions are assigned or evaluated.
policyAn authorization policy is a declarative rule or set of rules that determines which subjects may perform which actions on which resources under specified conditions.
delegationDelegation is an authorization in which one entity grants another authority to act on its behalf within a defined scope.
policy checkPolicy evaluation is the process of determining whether a request satisfies the rules and conditions in an authorization policy.
schema validationSchema validation is the process of checking data or configuration against the structure, types, and constraints defined by a schema.
static analysisStatic analysis is the examination of programs or policies without executing them to identify properties, errors, or behavioral consequences.
policy-based access controlPolicy-based authorization determines access from explicitly defined rules or policies evaluated against identities, resources, actions, and conditions.
authorization decisionAn authorization decision is the determination of whether a principal is allowed to perform an action on a resource.

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.