Cedar is a purpose-built, open source policy language for fine-grained, real-time authorization. It expresses decisions about whether a principal may perform an action on a resource under contextual conditions, combining attributes, relationships, and context without scattering authorization checks through application code. section 7.0 section 7.1
A policy has an effect, a scope, and optional conditions. Effects are permit or forbid; scope identifies the principal, action, and resource to which the rule applies; conditions add contextual restrictions such as device trust, time, or location. Requests use the matching PARC model: Principal, Action, Resource, and Context. section 7.2 section 7.3
{
"principal": "Employee::\"bob\"",
"action": "Action::\"edit\"",
"resource": "Document::\"doc456\"",
"context": {
"device": {
"is_managed": true
},
"time": "2025-07-08T10:30:00Z"
}
}
A Cedar request is structured data. The calling system extracts identity, action, resource, and runtime context, normalizes them into PARC, and submits them with the applicable policy store. section 7.3.1
Evaluation first narrows policies by structural scope, then evaluates applicable conditions. A matching forbid always produces Deny; otherwise, a matching permit produces Allow; and no applicable permit produces Deny. This deny-overrides, deny-by-default model makes explicit permission necessary for access. section 7.3.3 section 8.2.2
Cedar emphasizes constrained, reviewable authorization logic:
- Uses typed entities, namespaces, and first-class entity references, so policies can directly model ownership, membership, and management relationships. section 7.4.2
- Limits expressions to a declarative feature set; loops, external calls, regular expressions, and other potentially unpredictable operations are intentionally absent. section 7.4.4
- Supports static analysis for contradictions, unreachable rules, coverage, equivalence, and refactoring checks before deployment. section 7.4.6
Scoped administrator deletion
A policy can state that it applies specifically to principals in an admin group and to the delete action. Declaring those constraints in policy scope makes intent visible and lets the engine prefilter irrelevant policies before condition evaluation. section 8.2.2
Cedar can unify role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC). Schemas define entity types, attributes, actions, and context; entity data supplies changing relationships; policies remain a clear, static decision layer. Templates, overrides, testing, and analysis support governance as policies evolve. section 9.1 section 9.10
