Cedar Authorization

Cedar is a language for writing authorization policies. This document covers Cedar concepts and its decision logic as a reference model for the Arda Multi-Enterprise Authorization Model.

External References

• Cedar Documentation
• AWS Guidance
• Cedar on GitHub

Core Concepts

An authorization request in Cedar is a four-tuple: (Principal, Action, Resource, Context) evaluated against a policy set.

Key types:

• Entity — the base type for Principal, Action, and Resource. Every entity has a type, an id, a map of attributes, and optional parents for hierarchical membership.
• Context — a map of contextual attributes (e.g., time of day, IP address) that accompany the request but are not modelled as entities.
• Policy — has an effect (permit or forbid), three scope clauses (principal, action, resource), and optional when and unless condition clauses.
• Schema — declares the entity types, action definitions, and principal-resource constraints. Used to validate both entities and policies before evaluation.
• AuthorizationDecision — either Allow or Deny, produced by evaluating a policy set against a request.

Decision Logic

Cedar uses a default deny model with forbid-takes-precedence:

• The decision is Allow if and only if at least one permit policy is applicable AND no forbid policy is applicable.
• In all other cases the decision is Deny.

A policy is applicable to a request when:

1. All three scope clauses match — principal scope, action scope, and resource scope.
2. All when conditions evaluate to true.
3. All unless conditions evaluate to false.

Scope matching supports two forms:

• Exact match: the entity type and id must equal the scope’s type and id.
• Membership match (in operator): the entity is a direct or transitive member of the group identified by the scope’s type and id (hierarchy traversal via parents).

Formal Authorization Predicate

Authorize(request, policySet, schema) → AuthorizationDecision

  Precondition: All entities in the request validate against the schema.

  LET is_permitted = ∃ p ∈ policySet: p.effect = permit ∧ IsApplicable(p, request)
  LET is_forbidden = ∃ f ∈ policySet: f.effect = forbid ∧ IsApplicable(f, request)

  IF (is_permitted ∧ ¬is_forbidden) THEN Allow ELSE Deny

Where IsApplicable is:

IsApplicable(policy, request) :=
    ScopeMatches(request.principal, policy.principalScope)
    ∧ ScopeMatches(request.action, policy.actionScope)
    ∧ ScopeMatches(request.resource, policy.resourceScope)
    ∧ ∀ w ∈ policy.whenClauses:   EvaluateCondition(w, request) = true
    ∧ ∀ u ∈ policy.unlessClauses: EvaluateCondition(u, request) = false

Implications for Arda

Cedar’s model (entities with hierarchies, rich context, typed schema, default deny, forbid override) maps directly to the Arda Multi-Enterprise Authorization Model requirements:

• Multi-tenant principals can be modelled with entity hierarchies (UserAccount → Tenant).
• Cross-enterprise resource access policies can use forbid overrides for explicit denials that survive any permit.
• The schema validates that only declared entity types and actions appear in policies, catching authoring errors before deployment.