Cedar Policy Examples

This page contains all the Cedar policies used in the demo scenarios. Each policy demonstrates different authorization patterns and Cedar language features.

Demo Scenario Policies

These policies correspond to the five acts in the live demo. You can copy and paste them directly into your AVP Policy Store.

Act 1: Zero Trust Default Deny

In Act 1, we demonstrate Zero Trust by showing that Alice is denied access even with valid credentials when no policies exist.

No policies yet! This act demonstrates that AVP denies by default. Without any permit policies, all access requests return DENY.

Test Case:

Principal: Alice Garcia (Analyst, Finance)
Action: Read
Resource: Q4-Report-2024 (Finance, confidential)
Result: 🚫 DENY (no matching policies)

Act 2: Basic RBAC with Department Check

This policy enables Analysts to read documents, but only within their own department.

Cedar Policy
Explanation
Test Cases
Code Reference

permit (
  principal in FinancialApp::Role::"Analyst",
  action == FinancialApp::Action::"Read",
  resource
)
when {
  principal.department == resource.department
};

Policy Name: AllowAnalystReadOwnDepartmentWhat it does:

Allows users who are members of the Analyst role
To perform the Read action
On any Document resource
Only if the user’s department matches the document’s department

Key Concepts:

principal in Role::"Analyst" - RBAC pattern (role membership check)
when { ... } - ABAC pattern (attribute-based condition)
Combines RBAC and ABAC for fine-grained control

This policy is created in the demo at lambda/app.py:234 when demonstrating Act 2.Users are assigned to roles via the parents field:

"parents": [
    {
        "entityType": "FinancialApp::Role",
        "entityId": "Analyst"
    }
]

Act 3: Cross-Department Access for Auditors

Auditors need to read documents across all departments for compliance purposes.

Cedar Policy
Explanation
Test Cases
Combined Effect

permit (
  principal in FinancialApp::Role::"Auditor",
  action == FinancialApp::Action::"Read",
  resource
);

Policy Name: AllowAuditorReadAllWhat it does:

Allows users who are members of the Auditor role
To perform the Read action
On any Document resource
No conditions - full read access

Key Concepts:

Simple RBAC policy without conditions
No when clause means no attribute restrictions
Works across all departments

Act 4: Forbid Critical Actions

Even Auditors shouldn’t be able to modify or delete documents. Forbid policies enforce this.

Cedar Policy
Explanation
Test Cases
Precedence

forbid (
  principal in FinancialApp::Role::"Auditor",
  action in [FinancialApp::Action::"Edit", FinancialApp::Action::"Delete"],
  resource
);

Policy Name: ForbidAuditorModifyWhat it does:

Denies users who are members of the Auditor role
From performing Edit or Delete actions
On any Document resource

Key Concepts:

forbid effect - explicitly denies access
action in [...] - matches multiple actions
Forbid always wins over permit policies

Why forbid wins:Even if you added this permit policy:

permit (
  principal in FinancialApp::Role::"Auditor",
  action == FinancialApp::Action::"Edit",
  resource
);

The forbid policy would still block Edit requests from Auditors. Forbid always takes precedence over permit.

Additional Policy Patterns

Here are more Cedar policies demonstrating advanced patterns you can use:

Admin Full Access

Administrators can perform any action on any resource:

permit (
  principal in FinancialApp::Role::"Admin",
  action,
  resource
);

Features:

action without conditions matches all actions
resource without conditions matches all resources
Simple but powerful for admin roles

Clearance Level Gating

Restrict access based on security clearance:

permit (
  principal in FinancialApp::Role::"Analyst",
  action == FinancialApp::Action::"Read",
  resource
)
when {
  principal.clearance_level >= 3 &&
  resource.classification == "confidential"
};

Use Case: Only Analysts with clearance level 3 or higher can read confidential documents.

Block All Deletes on Confidential Documents

Protect critical documents from deletion:

forbid (
  principal,
  action == FinancialApp::Action::"Delete",
  resource
)
when {
  resource.classification == "confidential"
};

Features:

principal without restrictions applies to all users
Even Admins cannot delete confidential documents
Ultimate data protection for critical resources

Department-Based Edit Access

Allow editing only within your department:

permit (
  principal in FinancialApp::Role::"Analyst",
  action == FinancialApp::Action::"Edit",
  resource
)
when {
  principal.department == resource.department &&
  principal.clearance_level >= 2
};

Use Case: Analysts can edit documents in their department if they have sufficient clearance.

Time-Based Access (Concept)

While not in the current demo, Cedar can check context attributes like time:

permit (
  principal in FinancialApp::Role::"Analyst",
  action == FinancialApp::Action::"Read",
  resource
)
when {
  context.current_time >= context.business_hours_start &&
  context.current_time <= context.business_hours_end
};

This requires passing context data to AVP’s IsAuthorized call. Not implemented in the current demo but shows Cedar’s flexibility.

Policy Testing Matrix

Here’s a complete matrix showing which user can perform which action on which resource after all demo policies are applied:

User	Role	Document	Read	Edit	Delete
Alice	Analyst	Q4-Report-2024 (Finance)	✅ Act 2	🚫 No policy	🚫 No policy
Alice	Analyst	HR-Payroll-2024 (HR)	🚫 Dept mismatch	🚫 No policy	🚫 No policy
Bob	Admin	Q4-Report-2024 (Finance)	✅ (if admin policy added)	✅ (if admin policy added)	✅ (if admin policy added)
Bob	Admin	HR-Payroll-2024 (HR)	✅ (if admin policy added)	✅ (if admin policy added)	✅ (if admin policy added)
Carol	Auditor	Q4-Report-2024 (Finance)	✅ Act 3	🚫 Act 4 forbid	🚫 Act 4 forbid
Carol	Auditor	HR-Payroll-2024 (HR)	✅ Act 3	🚫 Act 4 forbid	🚫 Act 4 forbid
Carol	Auditor	Sales-Dashboard (Sales)	✅ Act 3	🚫 Act 4 forbid	🚫 Act 4 forbid

Policy Creation Tips

Name your policies descriptively

In the AVP console, give each policy a clear name:

✅ AllowAnalystReadOwnDepartment
✅ ForbidAuditorModify
❌ Policy1
❌ test-policy

Test incrementally

Add one policy at a time and test it before adding the next. This makes debugging easier.

Use the AVP console policy editor

The AVP console provides syntax highlighting and validation. It will catch typos and schema violations before you save.

Start with permit, add forbid later

Get your permit policies working first. Then add forbid policies to enforce restrictions. This follows the principle of starting permissive and adding restrictions.

Use the Cedar Playground

Test policies offline at cedarpolicy.com/playground before deploying to AVP.

Policy vs Code Comparison

One of the key benefits of Cedar is separating authorization from code. Here’s what the same logic would look like in code:

Cedar Policy
Python Code

permit (
  principal in FinancialApp::Role::"Analyst",
  action == FinancialApp::Action::"Read",
  resource
)
when {
  principal.department == resource.department
};

Lines of code: 7
Deployment needed: No (change takes effect immediately)
Who can change: Security team via AVP console

def check_access(user, action, resource):
    # Check if user is an Analyst
    if user['role'] != 'Analyst':
        return False
    
    # Check if action is Read
    if action != 'Read':
        return False
    
    # Check if departments match
    if user['department'] != resource['department']:
        return False
    
    return True

Lines of code: 12
Deployment needed: Yes (code deployment + testing)
Who can change: Developers with code access

With Cedar, you can update authorization rules without deploying code. Security teams can adjust policies in real-time through the AVP console.

Next Steps

RBAC vs ABAC

Learn the difference between role-based and attribute-based access control

Schema Definition

Review the schema that makes these policies possible

Deploy the Demo

Try these policies yourself in the live demo

Cedar Playground

Experiment with Cedar policies in your browser

Get Started

Deployment

Architecture

Usage

Cedar Policies

Cedar Policy Examples

Cedar Policy Examples

Demo Scenario Policies

Act 1: Zero Trust Default Deny

Act 2: Basic RBAC with Department Check

Act 3: Cross-Department Access for Auditors

Act 4: Forbid Critical Actions

Additional Policy Patterns

Admin Full Access

Clearance Level Gating

Block All Deletes on Confidential Documents

Department-Based Edit Access

Time-Based Access (Concept)

Policy Testing Matrix

Policy Creation Tips

Policy vs Code Comparison

Next Steps

RBAC vs ABAC

Schema Definition

Deploy the Demo

Cedar Playground

Build docs developers (and LLMs) love

Get Started

Deployment

Architecture

Usage

Cedar Policies

​Cedar Policy Examples

​Demo Scenario Policies

​Act 1: Zero Trust Default Deny

​Act 2: Basic RBAC with Department Check

​Act 3: Cross-Department Access for Auditors

​Act 4: Forbid Critical Actions

​Additional Policy Patterns

​Admin Full Access

​Clearance Level Gating

​Block All Deletes on Confidential Documents

​Department-Based Edit Access

​Time-Based Access (Concept)

​Policy Testing Matrix

​Policy Creation Tips

​Policy vs Code Comparison

​Next Steps

RBAC vs ABAC

Schema Definition

Deploy the Demo

Cedar Playground

Build docs developers (and LLMs) love

Cedar Policy Examples

Demo Scenario Policies

Act 1: Zero Trust Default Deny

Act 2: Basic RBAC with Department Check

Act 3: Cross-Department Access for Auditors

Act 4: Forbid Critical Actions

Additional Policy Patterns

Admin Full Access

Clearance Level Gating

Block All Deletes on Confidential Documents

Department-Based Edit Access

Time-Based Access (Concept)

Policy Testing Matrix

Policy Creation Tips

Policy vs Code Comparison

Next Steps