7 The building blocks of policy

This chapter introduces Cedar as a purpose-built language for expressing authorization policies that are precise, fast, and safe enough for real-time decisions. Using ACME Corp as an example, it shows why a team would choose Cedar: it can capture relationship-based and attribute-based rules in one policy language, supports review before deployment, and fits into systems that need immediate access checks. The chapter frames Cedar as a practical way to turn business rules like ownership, device trust, on-call status, and business hours into policies that both machines and humans can understand.

The core of the chapter explains how a Cedar policy is built from three parts: effect, scope, and conditions. The effect says whether the rule permits or forbids access, with forbids taking precedence over permits. The scope defines which principal, action, and resource the policy applies to, while conditions add extra constraints such as device status, team membership, time of day, or ownership. These pieces combine into a clear contract: a request is allowed or denied based on who is asking, what they want to do, what they want to act on, and whether the surrounding context satisfies the rule.

The chapter then connects policy structure to runtime evaluation through the PARC model: Principal, Action, Resource, and Context. Cedar first matches requests against policy scope, then evaluates any conditions, and finally combines results using deny-overrides and deny-by-default semantics. It also highlights Cedar’s distinctive design choices: strong typing, structured entities, namespaces, a small operator set, and the deliberate omission of complex or unsafe features like loops and external calls. Together, these choices make Cedar predictable, analyzable, and suitable for policy governance, while also laying the groundwork for comparing it with other authorization languages later in the book.

 A complete Cedar policy showing effect (top box), scope (middle box), and conditions (bottom box)

Mapping an access request to a policy. Each component of the request (left) is matched against the corresponding part of the policy (right). Scope is matched directly; conditions are evaluated by using attributes and context.

• Cedar is a purpose-built policy language designed for real-time, fine-grained authorization decisions using attributes, relationships, and context.
• Policies are organized using three elements: effect (permit or forbid), scope (principal, action, resource), and conditions (contextual logic).
• Access requests follow the PARC model, and Cedar evaluates them by matching scope and evaluating conditions, using a deny-overrides decision model.
• Cedar offers a rich entity model, allowing policies to reference relationships such as ownership or team membership through first-class entity types and attributes.
• Namespaces and type safety help prevent errors and promote modular policy development by clearly organizing entities and enforcing strict type rules.
• Cedar emphasizes safety, clarity, and analyzability by using strong typing, simple data access, and a minimal set of operators.
• Design choices such as omitting regular expressions and loops make policies easier to audit, verify, and maintain, especially when using static analysis tools like Cedar Analysis.

FAQ