Chapter 9: Implementing policies with Cedar

Introduction

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.

• ACME’s varied access requirements: Describe how ACME’s access requirements differ across design documents, legal contracts, marketing materials, and critical resources.
  Why it matters: These examples show why one simple access rule would not cover ACME’s needs.
• Unified Cedar policy rationale: Explain why ACME’s identity team wants clear, testable Cedar policies evaluated at runtime instead of exceptions embedded in application code or scattered across services.
  Why it matters: A unified policy approach helps ACME change access rules without hunting through application-specific checks.

Key terms: owners, managers, legal team, external collaborators, company-managed devices, Cedar policies, evaluated at runtime, exceptions, ad hoc checks

9.1 From primer to practice

This section explains why ACME chose Cedar as a single policy language for varied access rules and identifies a zero-trust constraint those rules must respect.

• One language for access patterns: Explain why ACME chose Cedar for its Customer Collaboration platform: it needed one policy layer that could express team membership, ownership and management relationships, and attribute-based conditions.
  Why it matters: ACME’s choice of Cedar follows from the different kinds of access rules its platform must express.
• Critical resource access constraint: State ACME’s zero-trust constraint for critical resources and the additional consideration outside business hours.
  Why it matters: The device and time constraints show that ACME’s access rules extend beyond a person’s relationship to a resource.

Key terms: Cedar, RBAC-style team membership, ReBAC-style ownership and management relationships, ABAC-style conditions, zero-trust policy, critical resources, company-managed devices, business hours

9.2 Modeling your schema first

This section explains why ACME defines a Cedar schema before writing policies and how the schema helps keep policies valid and consistent.

• Schema as policy contract: Explain what a Cedar schema defines and how it constrains policies: it specifies the entities, actions, and context policies may reference, and a policy using an undeclared attribute, action, or entity type will not compile.
  Why it matters: Defining the schema first lets the team catch invalid policy references before deployment.
• Benefits of schema first: Justify developing the schema before policies by describing how it catches mistakes before deployment, establishes consistent names, and supports validation in IDEs and CI/CD pipelines.
  Why it matters: A shared, checkable vocabulary helps policy changes remain dependable as the system evolves.

Key terms: Cedar schema, entities, actions, context, compiler, type safety, precise vocabulary, tooling support, IDEs, CI/CD pipelines

9.2.1 ACME’s core entities and actions

The section identifies the entities and actions in ACME’s initial Cedar schema and explains why that schema provides a foundation for its policies.

• ACME’s initial authorization schema: Describe the employees, customers, documents, and teams represented in ACME’s Customer Collaboration platform, the doc:view, doc:edit, and doc:share actions, and why defining them in a Cedar schema matters.
  Why it matters: The schema establishes what ACME’s policies can refer to consistently.

Key terms: Cedar schema, Employees, Customers, Documents, Teams, doc:view

9.2.2 How schema shapes policies

This subsection shows how ACME’s Cedar schema constrains policies and supplies a consistent request attribute for conditions.

• Schema constraints on policies: Explain how the schema limits what ACME policies can reference: a Document owner must be an Employee, and the schema prevents a policy from allowing a customer to doc:edit.
  Why it matters: The schema helps keep policies consistent with the access rules ACME intends.
• Consistent managed-device context: Describe how including context.device.managed in every request enables ABAC-style conditions without repeating its structure in each policy.
  Why it matters: A consistently available request attribute makes device-based conditions easier to express.

Key terms: schema, owner, Document, Employee, doc:edit, policy drift, context.device.managed, ABAC-style conditions

9.2.3 Updating schema as your system evolves

This section explains how to evolve a Cedar schema safely and avoid design mistakes that make policies unsafe or hard to maintain.

• Schema-first change sequence: Explain why ACME updates its schema before writing and testing policies when its system changes.
  Why it matters: The order of changes helps prevent new policies from outpacing the model they rely on.
• Narrow action typing: Explain the access risk of using Any for an action’s principal or resource, and describe the narrower alternative.
  Why it matters: Precise action types help prevent accidental access grants as the entity model expands.
• Separate typed attributes: Describe why combining distinct concepts in one attribute makes policies fragile and how to model them instead.
  Why it matters: Separating concepts makes policy conditions easier to read, maintain, and test.
• Consistent schema naming: Explain how consistent names for entity types, attributes, and actions help policy authors avoid errors.
  Why it matters: Consistent names make policies easier to author and reduce hard-to-spot typos.
• Declared request context: Explain why request-time attributes should be declared in the schema rather than left outside it.
  Why it matters: Schema-declared context supports policy checks and realistic tests without application-specific workarounds.

Key terms: schema, Folder entity, policies, principal: Any, resource: Any, appliesTo, forbid, overloading attributes, typed attributes, related entities

9.3 Authoring ACME’s core policies

The section explains how ACME’s schema safeguards policy authoring and identifies the stable, relationship-based rules that form its core policies.

• Schema validation guardrail: Explain how ACME’s schema helps the identity team write safe policies: policies are validated against the schema during compilation so rules cannot accidentally target the wrong type of principal or resource.
  Why it matters: The schema helps catch type mistakes before a policy is used.
• Core relationship access rules: Describe core policies as basic, relatively stable rules that underpin decisions across ACME’s Customer Collaboration platform, and state the three rules introduced here: readers-team members may view, owners may do all, and a principal who manages an owner may do all.
  Why it matters: These basic rules establish the access relationships the subsequent Cedar policies express.

Key terms: schema, validated, compilation, principal, resource, core policies, decision set, employee or customer document readers team, owner, manager of an owner

9.3.1 Permit view if on the right team

This section explains how ACME grants document viewing through ownership or reader-team membership and why it uses separate Cedar policies for employees and customers.

• Document viewing and team membership: Explain who can view a document and how the customer readers team is represented for Cedar’s membership check.
  Why it matters: The reader-team check depends on entity-store membership, not a customer list embedded in the document.
• Separate employee and customer policies: Justify using separate employee and customer policies instead of one combined permit policy.
  Why it matters: Type-specific scopes make these access rules easier to review and less likely to become accidentally too broad or too narrow.

Key terms: document owners, customer_readers_team, Team entity, entity store, entity hierarchy, policy scope, principal is ACME::Employee, principal is ACME::Customer, when clause

9.3.2 Owner can do all

This subsection explains that document owners can view, edit, and share their documents, while the schema limits those rights to specified actions.

• Owner permissions and action limits: Explain that owners can view, edit, and share their own documents, but adding a new action does not automatically grant it to them.
  Why it matters: Broad owner access does not have to expand silently when the application adds an action.

Key terms: owner, schema, action list, doc:delete

9.3.3 Manager of owner can view and edit

This subsection shows how a Cedar policy grants a document owner’s manager view and edit access, then explains Cedar’s deny-by-default behavior and overriding forbid rules.

• Manager access through owner: Explain that a document owner’s manager can be permitted to view and edit the document, and why the policy can follow the relationship from the document’s owner to that manager.
  Why it matters: The schema makes the supervisory relationship available for an access rule.
• Default denial and forbids: Explain when Cedar permits a request and how explicit forbid rules differ from implicit denial.
  Why it matters: This distinction lets you allow intended access while enforcing requirements that must override it.

Key terms: resource.owner, manager, Employee attribute, deny-by-default, permit policy, forbid policy, guardrails

9.4 Where does Cedar find data about entities?

This section explains how Cedar gets entity data for policy evaluation, how ACME models that data, and how relationship modeling affects access decisions.

• Entity store as policy data: Explain what Cedar obtains from an entity store and why its design matters to policy evaluation.
  Why it matters: A policy can only make decisions using the entity data made available to it.
• PDP decision context assembly: Describe how the PDP brings entity data, policies, and request context together for a Cedar decision without owning the underlying business data.
  Why it matters: The PDP gives each decision a consistent view of the relevant data instead of relying on scattered application checks.
• ACME graph driven access changes: Trace how ACME represents its entities and relationships and changes access when organizational data changes.
  Why it matters: Keeping changing organizational facts in the graph avoids rewriting policies for each personnel or roster change.
• Membership edges versus entity sets: Justify using relationship edges for group membership rather than large sets embedded in team entities, while identifying the limited use for sets.
  Why it matters: The membership representation affects evaluation speed, update effort, and how simply policies can be expressed.
• Transitive hierarchy reach and risk: Explain how entity-store hierarchies affect Cedar’s transitive relationship checks and why their reach must be considered.
  Why it matters: A hierarchy can simplify policies while granting a relationship check a wider reach than a direct link alone.

Key terms: entity store, principals, resources, attributes, relationships, Policy Decision Point (PDP), decision context, scoped snapshot, Cedar evaluation engine, relationship graph

9.5 Applying Cedar’s policy patterns

Introduces Cedar’s flexibility in combining authorization patterns within one policy set for ACME’s Customer Collaboration platform.

• Combining Cedar authorization patterns: Explain that Cedar can combine discretionary, membership, and relationship permissions in one policy set, allowing ACME to address varied business requirements without overly complex policies.
  Why it matters: This gives you the reason ACME uses a mix of permission patterns rather than trying to fit every requirement into one.

Key terms: Cedar, discretionary permissions, membership permissions, relationship permissions, policy set

9.5.1 Discretionary permissions

This section shows how ACME gives document owners control over readers through team membership while keeping sharing rights separate from reading rights.

• Document-specific discretionary access: Explain how ACME document owners give employees or customers viewing access through readers teams, and why changing team membership does not require a policy change.
  Why it matters: You can change access to an individual document without rewriting or redeploying its policies.
• Reading versus sharing rights: Distinguish an owner's discretionary choice of readers from permission for someone else to share a document, using ACME's delegatable document example.
  Why it matters: Keeping viewing and sharing separate prevents someone from assuming that opening a document gives them authority to grant access to others.

Key terms: discretionary permissions, DAC, employee_readers_team, customer_readers_team, entity store, discretionary, delegatable, delegatable: Bool, readers team

9.5.2 Membership permissions

This section shows how ACME uses a Cedar membership permission for its legal team and keeps document classification in entity metadata rather than hard-coding it into the policy.

• Legal team membership permission: Explain how ACME’s RBAC-style membership permission grants legal-team members permission to view and edit legal-classified documents. Describe why scoping the principal to the legal team makes a separate membership condition in a when clause unnecessary.
  Why it matters: Principal scope makes the team-based permission easier to read without repeating membership logic in a condition.
• Document classification as entity metadata: Explain where a document’s Legal classification is stored and how changing it can change which policies apply without editing policy text. Distinguish that document metadata from the entity store’s legal-team membership check.
  Why it matters: A document’s classification can change the applicable permissions without requiring a policy rewrite.
• Single entity membership syntax: Distinguish the allowed expression `principal in ACME::Team::"team:legal"` from the disallowed `principal in […]` construction.
  Why it matters: This distinction prevents an invalid Cedar expression when writing a membership permission.

Key terms: membership permissions, RBAC-style rules, principal, ACME::Team::"team:legal", when clause, Legal classification, metadata, Document entity, entity store, principal in

9.5.3 Relationship permissions

This section illustrates relationship-based permissions through ACME’s manager-of-owner rule.

• Relationship-Based Access Decisions: Explain that relationship permissions grant access based on connections between principals and resources, using ACME’s manager-of-owner rule as an example.
  Why it matters: It shows how access can follow a relationship rather than a team assignment.

Key terms: relationship permissions, ReBAC, manager of owner, entity store

9.5.4 Mixing patterns for PBAC

ACME illustrates how Cedar can combine different access-control patterns in one policy using facts from the entity store.

• Mixed Cedar policy patterns: Explain how ACME can combine access-control patterns in a Cedar policy, using the example of checking whether an employee is the owner’s manager and whether the principal belongs to the legal team. Describe how Cedar uses entity-store facts to evaluate such checks together.
  Why it matters: Combining checks lets one Cedar policy express access decisions that depend on more than one kind of fact.

Key terms: Cedar, ABAC, ReBAC, RBAC, entity store

9.6 Layering global constraints

The section shows how ACME applies one context-based constraint across its Cedar policies and why it can deny access despite other permissions.

• Global constraints and forbid precedence: Explain how ACME uses ABAC to apply organization-wide, context-based constraints without repeating checks in each application. Describe why an unmanaged device causes a denial even when another policy permits the action.
  Why it matters: A permission granted through one policy pattern does not bypass an organization-wide restriction.

Key terms: ABAC, global constraints, request’s context, forbid, permit

9.7 Using policy templates and overrides

This section introduces Cedar policy templates as a way to reuse policy patterns instead of writing each policy separately.

• Reusable Cedar policy templates: Explain that an identity team can define a Cedar policy pattern once and instantiate it multiple times with different parameters, reducing repetition and keeping policies consistent.
  Why it matters: Templates make it easier to apply consistent policies across teams, products, or customers.

Key terms: Cedar policies, templates, instantiate, parameters

9.7.1 Templates

This section explains when ACME uses Cedar templates for repeated direct grants, how that differs from relationship-based sharing, and how to manage templates safely.

• Template slots and linked grants: Explain that Cedar templates reuse a fixed policy structure for grants that vary by principal, resource, or both. Describe linking a template to concrete principal and resource values, and state that its only slots are ?principal and ?resource.
  Why it matters: The slot limits determine which repeated grants a template can express.
• Direct grants versus relationship data: Distinguish ACME’s narrow use of templates for explicit direct grants from ordinary document sharing, which updates relationships in the entity store instead of creating policies.
  Why it matters: This distinction lets ACME support ordinary sharing without producing a separate policy for every relationship.
• Safe template management: Describe the safeguards ACME recommends for template-linked policies: validate linked entities, record template versions for audit, and test and stage template changes.
  Why it matters: A mistake in a reused template or its linked values can affect many grants, so changes should be checked and traceable.

Key terms: Cedar templates, ?principal, ?resource, linked principals and resources, relationship data, entity store, relationship graph, direct grants, tenancy, semantic versions

9.7.2 Overrides

This section explains how ACME uses additional Cedar policies for local exceptions to template-generated rules, and how those overrides differ from global constraints.

• Local overrides of template rules: Explain that an override is an additional Cedar policy evaluated alongside template-generated policies, allowing a local exception without changing the original template. Describe how ACME could use one to restrict viewing in a sensitive workspace to the document owner.
  Why it matters: Overrides let a team address a special access requirement without rewriting a reusable template.
• Local versus global guardrails: Distinguish overrides, which are limited to a resource, workspace, or customer, from global constraints, which apply throughout the organization regardless of local policy. Identify the different teams the section says usually manage them.
  Why it matters: The distinction clarifies when a rule is a local exception and when it must hold everywhere.

Key terms: overrides, template-generated policies, document-view-template, local exceptions, global constraints, organization-wide guardrails, delegated administrators

9.8 Mapping requests to Cedar evaluations

Shows how a PEP turns application requests into accurate Cedar evaluations and compares ways to run Cedar in production.

• Request to Cedar mapping: Trace how ACME’s PEP turns a document-sharing request into a Cedar evaluation and handles the resulting decision.
  Why it matters: Cedar can evaluate an operation only when the application presents that operation accurately.
• Evaluation request integrity: Explain the qualities the PEP must maintain in evaluation requests and why they matter across protected operations.
  Why it matters: A correct policy cannot compensate for a PEP that asks Cedar about the wrong operation or supplies the wrong data.
• Local managed and hybrid deployment: Distinguish Cedar Local Agent from Amazon Verified Permissions and describe how a hybrid deployment combines them.
  Why it matters: Deployment changes where decisions run and who manages the infrastructure without requiring different Cedar evaluation logic.
• Embedded Cedarling evaluation: Describe Cedarling’s JWT-centered approach to embedding Cedar decisions and its stated integration limitations.
  Why it matters: Cedarling illustrates an embedded, JWT-aware option alongside local-agent and managed-service deployments.

Key terms: Policy Enforcement Point (PEP), principal, action, resource, context, is_authorized, complete, consistent, scoped, Cedar schema

9.9 From concept to policy

The section connects ACME’s Cedar policy components into an authorization flow and explains why the same policies can support different deployments.

• ACME authorization flow: Trace how ACME’s schema, policies, relationship data, constraints, templates, and overrides fit together, including how facts and real requests reach Cedar and produce decisions.
  Why it matters: This connects the chapter’s separate Cedar examples to the decisions an application actually uses.
• Policy deployment flexibility: Explain why ACME can choose among Cedar deployment environments without changing its underlying authorization model.
  Why it matters: ACME can adapt where authorization runs without rewriting what its policies mean.

Key terms: entity store, PEP, Cedar evaluations, policy set, local agent, managed service, embedded PDP, authorization model

9.10 Summary