chapter seven

7 The building blocks of policy

 

This chapter covers

  • The structure of a Cedar policy: effect, scope, and conditions
  • The PARC model (Principal, Action, Resource, Context) for representing access requests
  • How Cedar evaluates access decisions using matching, condition logic, and deny-overrides
  • Key features of the Cedar language, including strong typing, entity references, and namespaces
  • Cedar’s design principles that enable safety, performance, and formal analysis

At ACME Corp, the identity team has just finished rolling out a new set of access policies. Engineers can now deploy code only from company-managed devices, and only when they are on call or during business hours. Document sharing is managed through a graph of relationships, letting managers like Carol review their team’s work without needing explicit access permissions. These decisions are made in real time, but behind the scenes, there must be rules that govern access.

This chapter is about those rules. After exploring the main models for dynamic authorization, we now focus on how policy is actually written and evaluated. What does it mean to say “on call” or “manager” in a way that a system can understand? How does an authorization engine decide whether to allow or deny a request?

7.1 Introducing Cedar

7.2 Policy structure: effect, scope, and conditions

7.2.1 Effect: what the policy does

7.2.2 Scope: when the policy applies

7.2.3 Conditions: under what circumstances

7.2.4 Putting it together

7.3 The PARC model: understanding policy evaluation

7.3.1 Cedar’s representation of PARC

7.3.2 Evaluating policies

7.3.3 Combining results from multiple policies

7.3.4 PARC as the bridge

7.4 Cedar’s unique design

7.4.1 Strong data types

7.4.2 Rich entity model

7.4.3 Clear namespace and type safety

7.4.4 What Cedar doesn’t include

7.4.5 Minimal operators with maximum impact

7.4.6 Safe and analyzable by design

7.4.7 Clean, simple, and powerful

7.5 Cedar’s distinctive strengths

7.6 Summary