Your app grew from 3 users to 30,000. What started as a simple admin/user role check is now a 400-line jungle of nested if-statements. Your security team can't audit it. Your product manager can't understand it. Amazon built Cedar because they had the same problem — at AWS scale.
What Cedar Actually Does
Cedar is an open-source policy language and evaluation engine created by Amazon for fine-grained authorization. It powers Amazon Verified Permissions and internal AWS services. Cedar policies look almost like plain English: "A User can view a Photo if they are in the Photo's viewer list."
The Cedar engine evaluates policies in microseconds and provides formal verification tools to prove your policies are correct before you ship. The SDK is available in Rust, Java, Python, JavaScript/TypeScript, Go, and C. Fully open source (Apache 2.0).
Amazon Verified Permissions (AVP) provides a hosted version with 1 million free authorization requests/month for 12 months.
Quick Start
Using the Cedar local SDK (no AWS needed):
const { PolicySet, Request, Entities } = require('@cedar-policy/cedar-wasm');
const policies = new PolicySet(`
permit(
principal in Role::"editor",
action == Action::"Edit",
resource
) when {
resource.owner == principal.id
};
`);
const request = new Request(
{ type: 'User', id: 'alice' },
{ type: 'Action', id: 'Edit' },
{ type: 'Document', id: 'doc-42' },
{ owner: 'alice' }
);
const result = policies.isAuthorized(request, entities);
console.log(result.decision); // "Allow"
Or via AWS Verified Permissions API:
aws verifiedpermissions create-policy-store \
--validation-settings '{"mode": "OFF"}' \
--region us-east-1
Check authorization:
aws verifiedpermissions is-authorized \
--policy-store-id YOUR_STORE_ID \
--principal '{"entityType": "User", "entityId": "alice"}' \
--action '{"actionType": "Action", "actionId": "Edit"}' \
--resource '{"entityType": "Document", "entityId": "doc-42"}'
3 Practical Use Cases
1. Document Sharing Permissions
Cedar shines at "Alice shared doc with Bob" patterns:
permit(
principal,
action == Action::"View",
resource
) when {
principal in resource.viewers
};
permit(
principal,
action in [Action::"View", Action::"Edit", Action::"Delete"],
resource
) when {
resource.owner == principal
};
Two rules cover the entire document sharing model. Readable. Auditable. Correct.
2. Time-Based Contractor Access
permit(
principal in Role::"contractor",
action == Action::"AccessSystem",
resource
) when {
context.currentTime < context.contractExpiry
};
Contractor access automatically expires based on context attributes.
3. Formal Verification
The killer feature — prove policies have no gaps before shipping:
cargo install cedar-policy-cli
cedar authorize \
--policies policies.cedar \
--entities entities.json \
--principal 'User::"alice"' \
--action 'Action::"Delete"' \
--resource 'Document::"doc-1"'
The analysis tool answers: "Can a non-admin ever reach the admin endpoint?" with a mathematical proof or counterexample.
Why This Matters
Cedar represents a shift in authorization thinking. Traditional role checks are hidden, untestable, and impossible to audit. Cedar policies are first-class artifacts: version-controlled, reviewable by non-engineers, and formally verifiable.
For regulated industries (fintech, healthcare, legal), this is transformative. Your compliance team reads actual policies. Your security team runs verification. Engineers stop arguing about correctness — the math proves it.
Need custom data extraction or web scraping solutions? I build production-grade scrapers and data pipelines. Check out my Apify actors or email me at spinov001@gmail.com for custom projects.
Follow me for more free API discoveries every week!
Top comments (0)