Lion Cipher Lab

Write and test authorization policies with Cedar

• Identity & Access Management
• Intermediate
• ~45 min
• Free · no account required

Why it matters

Most authorization — deciding who is allowed to do what — gets written as if-statements sprinkled through application code: `if user.role == 'admin' or (doc.owner == user.id and not doc.locked): ...`. That works until it doesn't. The rules end up duplicated across services, no one can answer 'who can actually access this?' without reading code, and you can never PROVE the rules are consistent, because arbitrary code is not analyzable. Cedar is an answer to exactly this. It is an open-source authorization policy language created by AWS (and the engine behind Amazon Verified Permissions) that…

What you'll learn

• explaining 'policy-as-authorization': why you pull access decisions OUT of your application code and into a dedicated policy language and engine, instead of scattering if-statements through your codebase
• installing the real Cedar CLI (`cedar`) from source with `cargo install cedar-policy-cli`, or using a pre-built binary from the project's GitHub releases
• writing a small Cedar schema that declares entity types (principals and resources), their attributes, and which actions apply to which principal/resource types
• writing permit and forbid policies over a principal/action/resource scope, narrowed by `when { ... }` and `unless { ... }` attribute conditions
• authoring entities as a Cedar JSON file and running `cedar authorize` on concrete request tuples to get an ALLOW or DENY decision you can read on one line
• seeing Cedar's core semantics in action: deny-by-default (nothing is allowed unless a permit grants it) and forbid-wins (a satisfied forbid overrides any satisfied permit)
• running `cedar validate` against the schema to catch a policy bug — an attribute the schema does not define — before it ever ships, which is Cedar's analyzability payoff
• judging RBAC vs ABAC vs ReBAC, why a decidable policy language beats imperative authz code for auditability and analysis, and when a policy language is overkill

Steps in this lab

1. What Cedar is, and what 'policy-as-authorization' means
2. Install the Cedar CLI (`cedar`)
3. Write a schema: the shape of your world
4. Write the policies: permit, forbid, and a `when` condition
5. Author entities and run `cedar authorize` — see ALLOW and DENY
6. Forbid-wins in one sentence, then let `cedar validate` catch a bug
7. The judgment: RBAC vs ABAC vs ReBAC, and when NOT to use a policy language
8. What you did — and the reflex to keep

Open the full interactive lab →