RBAC vs ABAC

AWS Verified Permissions and Cedar support both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Understanding when to use each pattern is key to building flexible, maintainable authorization systems.

Overview

RBAC

Role-Based Access ControlAccess decisions based on user roles (Admin, Analyst, Auditor)Pros:

Simple to understand
Easy to manage
Matches organizational structure

Cons:

Less flexible
Can lead to role explosion
Coarse-grained control

ABAC

Attribute-Based Access ControlAccess decisions based on attributes (department, clearance level, classification)Pros:

Very flexible
Fine-grained control
Scales to complex scenarios

Cons:

More complex to reason about
Requires more planning
Needs attribute management

Cedar’s Power: You don’t have to choose! Cedar lets you combine RBAC and ABAC in the same policy for maximum flexibility.

RBAC: Role-Based Access Control

RBAC grants permissions based on what role a user has. It’s the traditional approach used by most applications.

Pure RBAC Example

This policy allows any Auditor to read any document:

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

Key characteristics:

Decision based solely on role membership
No attribute checks
All Auditors get the same permissions
Simple to understand and manage

How RBAC Works in Cedar

Define Roles

Roles are defined in the schema as entity types:

"Role": {
    "memberOfTypes": []
}

Assign Users to Roles

Users become members of roles via the parents field:

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

Write Role-Based Policies

Use the principal in Role::"RoleName" syntax:

principal in FinancialApp::Role::"Analyst"

AVP Evaluates Membership

AVP checks if the user is a member of the specified role and grants access accordingly.

Common RBAC Patterns

Admin Access
Role-Specific Actions
Multiple Roles

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

Admins can do anything. Classic superuser pattern.

permit (
  principal in FinancialApp::Role::"Analyst",
  action in [
    FinancialApp::Action::"Read",
    FinancialApp::Action::"Edit"
  ],
  resource
);

Analysts can read and edit, but not delete.

permit (
  principal in FinancialApp::Role::"Manager",
  action == FinancialApp::Action::"Approve",
  resource
);

permit (
  principal in FinancialApp::Role::"Director",
  action == FinancialApp::Action::"Approve",
  resource
);

Both Managers and Directors can approve. You can also combine this into one policy using || operator.

ABAC: Attribute-Based Access Control

ABAC grants permissions based on attributes of the user, resource, action, or environment. It’s more flexible but requires more careful design.

Pure ABAC Example

This policy allows access only if departments match:

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

Key characteristics:

Decision based on attributes, not roles
Works for any user regardless of role
Dynamic based on context
Can express complex business rules

Attribute Types

ABAC policies can check different types of attributes:

Principal Attributes
Resource Attributes
Relational Attributes
Context Attributes

Attributes of the user making the request:

when {
  principal.department == "Finance" &&
  principal.clearance_level >= 3
}

Examples:

principal.department
principal.clearance_level
principal.email
principal.title

Attributes of the resource being accessed:

when {
  resource.classification == "confidential" &&
  resource.department == "Finance"
}

Examples:

resource.department
resource.classification
resource.owner
resource.created_date

Comparing principal and resource attributes:

when {
  principal.department == resource.department ||
  principal.clearance_level > resource.required_clearance
}

Examples:

Same department check
Clearance level comparison
Owner verification

Environmental factors (not in current demo):

when {
  context.ip_address like "10.0.*" &&
  context.time_of_day >= 9 &&
  context.time_of_day <= 17
}

Examples:

IP address
Time of day
Geographic location
Device type

Common ABAC Patterns

Same Department
Clearance Level
Complex Conditions
Negative Conditions

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

Users can only access resources in their department.

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

Only users with high clearance can access confidential documents.

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

Users can edit documents in their department if they have level 2+ clearance, OR any user with level 4+ clearance can edit any document.

permit (
  principal,
  action == FinancialApp::Action::"Read",
  resource
)
when {
  principal.department == resource.department
}
unless {
  resource.classification == "top-secret"
};

Users can read documents in their department except top-secret ones.

Hybrid: RBAC + ABAC

The most powerful approach is combining RBAC and ABAC. This gives you the organizational clarity of roles with the flexibility of attribute-based rules.

Hybrid Example from Demo

This policy uses both role membership and attribute comparison:

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

Breakdown:

RBAC part: principal in FinancialApp::Role::"Analyst"
- Only Analysts get this permission
ABAC part: principal.department == resource.department
- But only for documents in their department

Result: Role defines who gets the permission, attributes define when they can use it.

More Hybrid Patterns

Role + Clearance
Role + Multiple Attributes
Multiple Roles + Attributes

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

Analysts with sufficient clearance can read. Combines role membership with attribute check.

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

Analysts can edit documents in their department if they have clearance 2+ and the document isn’t restricted.

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

Analysts can read documents in their department, OR Auditors can read any document.

Demo Scenario Breakdown

Let’s analyze each demo policy by RBAC/ABAC classification:

Act 2: AllowAnalystReadOwnDepartment

Type: Hybrid (RBAC + ABAC)

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

RBAC: Uses role to identify Analysts
ABAC: Uses department attribute to limit scope
Benefit: Clear role definition with fine-grained control

Act 3: AllowAuditorReadAll

Type: Pure RBAC

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

RBAC: Only uses role membership
ABAC: None
Benefit: Simple, easy to understand and manage

Act 4: ForbidAuditorModify

Type: Pure RBAC

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

RBAC: Only uses role membership
ABAC: None
Benefit: Clear restriction based on job function

When to Use Each Pattern

Use RBAC When
Use ABAC When
Use Hybrid When

Scenario 1: Simple organizational permissions

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

All admins get full access. No conditions needed.Scenario 2: Job function permissions

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

Auditors need read access to do their job. Role defines capability.When RBAC works best:

Permissions align with organizational roles
Everyone in a role needs the same access
Simple permission model
Easy for non-technical stakeholders to understand

Scenario 1: Data ownership

permit (
  principal,
  action,
  resource
)
when {
  resource.owner == principal.id
};

Users can manage resources they own.Scenario 2: Dynamic conditions

permit (
  principal,
  action == FinancialApp::Action::"Read",
  resource
)
when {
  principal.department == resource.department &&
  resource.status == "active"
};

Access depends on runtime attributes.When ABAC works best:

Permissions depend on data attributes
Need fine-grained, dynamic control
Many users with varying access needs
Business rules change frequently

Scenario 1: Role with constraints

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

Analysts have read permissions, but limited to their department.Scenario 2: Multiple pathways

permit (
  principal,
  action == FinancialApp::Action::"Edit",
  resource
)
when {
  (principal in FinancialApp::Role::"Editor" &&
   principal.department == resource.department) ||
  (resource.owner == principal.id) ||
  (principal in FinancialApp::Role::"Admin")
};

Multiple ways to get access: role + department, ownership, or admin.When Hybrid works best:

Need both role clarity and fine-grained control
Different access levels within roles
Complex business requirements
Most real-world applications

Comparison Table

Aspect	RBAC	ABAC	Hybrid
Complexity	Low	High	Medium
Flexibility	Low	High	High
Maintenance	Easy	Complex	Medium
Scalability	Role explosion	Scales well	Scales well
Performance	Fast	Slightly slower	Medium
Auditability	Easy	Complex	Medium
Business Alignment	High	Medium	High
Best For	Simple orgs	Dynamic rules	Most apps

Migration Path: RBAC → Hybrid → ABAC

If you’re starting with RBAC and want more flexibility:

Start with Pure RBAC

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

Begin with simple role-based policies. Get basic authorization working.

Add Attribute Conditions

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

Add when clauses to existing policies. Now you have hybrid RBAC+ABAC.

Introduce Pure ABAC

permit (
  principal,
  action == FinancialApp::Action::"Read",
  resource
)
when {
  resource.owner == principal.id
};

Add attribute-only policies for dynamic scenarios. Roles become optional.

Mix and Match

Use RBAC for coarse-grained permissions, ABAC for fine-grained control, and hybrid for most scenarios. Choose the right pattern for each use case.

Best Practices

Use roles for job functions, attributes for data access

Roles should represent what someone does (Analyst, Admin, Auditor). Attributes should control what data they can access (department, clearance level).Good:

principal in FinancialApp::Role::"Analyst"  // Job function
when { principal.department == resource.department }  // Data access

Avoid: Creating roles like “FinanceAnalyst”, “HRAnalyst”, “SalesAnalyst” - use one Analyst role + department attribute instead.

Keep role hierarchies flat

Cedar doesn’t have built-in role hierarchy. Keep roles simple and use policies to define relationships.Instead of:

Admin > Manager > Analyst (hierarchy)

Use:

Separate policies for each role
Use attributes to distinguish levels

Design attributes for reusability

Attributes should be reusable across multiple policies.Good: department, clearance_level, classification
Avoid: can_read_finance_docs, is_senior_analyst (too specific)

Document the authorization model

Clearly document which patterns you’re using and why. Future maintainers will thank you.

Start simple, add complexity as needed

Begin with RBAC. Add ABAC only when you need it. Don’t over-engineer from the start.

Next Steps

Policy Examples

See complete RBAC, ABAC, and hybrid policies from the demo

Schema Definition

Review the entity types and attributes that enable RBAC and ABAC

Policy Overview

Learn Cedar policy language fundamentals

Deploy Demo

Try RBAC and ABAC policies yourself in the live demo

Get Started

Deployment

Architecture

Usage

Cedar Policies

RBAC vs ABAC

RBAC vs ABAC

Overview

RBAC

ABAC

RBAC: Role-Based Access Control

Pure RBAC Example

How RBAC Works in Cedar

Common RBAC Patterns

ABAC: Attribute-Based Access Control

Pure ABAC Example

Attribute Types

Common ABAC Patterns

Hybrid: RBAC + ABAC

Hybrid Example from Demo

More Hybrid Patterns

Demo Scenario Breakdown

Act 2: AllowAnalystReadOwnDepartment

Act 3: AllowAuditorReadAll

Act 4: ForbidAuditorModify

When to Use Each Pattern

Comparison Table

Migration Path: RBAC → Hybrid → ABAC

Best Practices

Next Steps

Policy Examples

Schema Definition

Policy Overview

Deploy Demo

Build docs developers (and LLMs) love

Get Started

Deployment

Architecture

Usage

Cedar Policies

​RBAC vs ABAC

​Overview

RBAC

ABAC

​RBAC: Role-Based Access Control

​Pure RBAC Example

​How RBAC Works in Cedar

​Common RBAC Patterns

​ABAC: Attribute-Based Access Control

​Pure ABAC Example

​Attribute Types

​Common ABAC Patterns

​Hybrid: RBAC + ABAC

​Hybrid Example from Demo

​More Hybrid Patterns

​Demo Scenario Breakdown

Act 2: AllowAnalystReadOwnDepartment

Act 3: AllowAuditorReadAll

Act 4: ForbidAuditorModify

​When to Use Each Pattern

​Comparison Table

​Migration Path: RBAC → Hybrid → ABAC

​Best Practices

​Next Steps

Policy Examples

Schema Definition

Policy Overview

Deploy Demo

Build docs developers (and LLMs) love

RBAC vs ABAC

Overview

RBAC: Role-Based Access Control

Pure RBAC Example

How RBAC Works in Cedar

Common RBAC Patterns

ABAC: Attribute-Based Access Control

Pure ABAC Example

Attribute Types

Common ABAC Patterns

Hybrid: RBAC + ABAC

Hybrid Example from Demo

More Hybrid Patterns

Demo Scenario Breakdown

When to Use Each Pattern

Comparison Table

Migration Path: RBAC → Hybrid → ABAC

Best Practices

Next Steps