Casbin RBAC vs. Casbin RBAC with Hierarchical Roles

The choice between standard Casbin RBAC (Role-Based Access Control) and Casbin RBAC with Hierarchical Roles largely depends on the complexity of your application's user structure and the need for role inheritance.

Both models use a similar policy structure in Casbin's configuration files (models and policies), but the hierarchical model provides a powerful shortcut for managing permissions in complex organizations.

Casbin RBAC vs. Casbin RBAC with Hierarchical Roles

Casbin Standard RBAC (Model: g only)

Standard RBAC assigns permissions to roles, and then assigns users to those roles. The core of this model in Casbin is the grouping policy (g), which maps a subject (user) to a role.

When to Choose Standard RBAC

Choose standard RBAC when your organization has a flat structure where roles are independent, or when all inheritance is handled by explicit user-to-role assignments.

• Flat Organizations: Small to medium-sized applications where roles (e.g., Admin, Editor, Viewer) have distinct, non-overlapping permission sets.
• Simple Auditing: When you need a direct, explicit list of every permission assigned to a user without having to trace an inheritance chain.
• Performance: For very high-traffic applications, avoiding a deep recursive lookup for role inheritance can slightly speed up authorization checks.

Example: Standard RBAC

Model (rbac_model.conf): Defines the grouping policy (g) to link users and roles.

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_manager]
# The rbac_model.conf file will define g, but omits the g2 for hierarchy
rm = rbac_api

[policy_effect]
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Policy (rbac_policy.csv): Explicitly grants permissions to the roles.

p, editor, articles, read
p, editor, articles, edit
g, alice, editor
g, bob, viewer

Annotation: Alice is an editor, and only the 'editor' role has permissions. The 'viewer' role is currently empty.

---

Casbin RBAC with Hierarchical Roles (Model: g and g2)

Hierarchical RBAC, sometimes referred to as RBAC with role inheritance, introduces a secondary grouping policy (g2) that maps roles to other roles. This means that a child role automatically inherits all permissions granted to its parent role.

Model definition uses a g2 line in the [policy_definition] or [grouping_policy] section to define role inheritance.

When to Choose Hierarchical RBAC

Choose hierarchical RBAC for large, complex, or deeply structured organizations where permissions need to cascade naturally down a chain of command.

• Inheritance is Key: When you can define permissions once at a high-level role (e.g., Manager) and ensure all lower-level roles (e.g., TeamLead, Supervisor) automatically receive those base permissions.
• Reduced Policy Management: It greatly simplifies the policy file by reducing redundancy. Instead of assigning 50 permissions to both Admin and Manager, you assign them to Manager and define Admin as a parent of Manager.
• Simulating Organizational Charts: It maps well to traditional organizational structures where an Executive inherits all permissions of a Director, who inherits all permissions of a Manager, etc.

Example: Hierarchical RBAC

Model (rbac_hierarchy_model.conf): Defines the grouping policy (g) for users-to-roles and the inheritance policy (g2) for roles-to-roles.

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_manager]
# The key is g2, which handles the role inheritance logic
rm = rbac_api

[policy_effect]
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

[matchers]
# The matcher must check both g (user->role) and g2 (role->role)
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

Policy (rbac_hierarchy_policy.csv): Defines both role permissions and the inheritance link.

# Permissions granted directly to the 'manager' role
p, manager, reports, view
p, manager, audits, create

# Permissions granted directly to the 'executive' role
p, executive, reports, view

# g, user, role - Alice is a Director
g, alice, director

# g2, child_role, parent_role - Defines the inheritance chain
g2, director, manager      # Director inherits all Manager permissions
g2, manager, executive     # Manager inherits all Executive permissions

Annotation: In this policy, Alice (a director) inherits permissions from manager AND executive. She can view reports, create audits, and any future permission granted to the executive role.

---

Summary and Decision Flow

Feature	Standard RBAC	Hierarchical RBAC
Role Inheritance	No (Must explicitly assign all permissions).	Yes (Child roles inherit parent permissions).
Complexity	Easier to trace and debug.	Reduces policy file size, but more complex lookups.
Policy Lines	Higher redundancy (many duplicated p lines).	Lower redundancy (single g2 lines manage many permissions).
Best For	Flat applications, simple permission needs, high performance.	Large enterprises, complex hierarchies, reduced maintenance.

If you find yourself constantly duplicating permission lines across different roles that logically should share permissions, switch to Hierarchical RBAC. If your structure is simple and static, Standard RBAC is sufficient.

Sources and Further Reading

1. Casbin Documentation - RBAC with Hierarchical Roles
2. Casbin GitHub Repository (Source Code)
3. Role-Based Access Control (RBAC) Overview