Understanding How Casbin Matching Works in Detail
This post explains how to design and implement RBAC with the Casbin library. For SaaS platforms with resource hierarchies and roles that inherit permissions, Casbin is a performant option.
Introduction to RBAC
RBAC restricts access based on the roles users hold. To see how hierarchical RBAC works, we look at Azure’s RBAC and then implement something similar in Casbin.
Azure’s hierarchical RBAC

In Azure, the Owner role applies at different scopes. If I have Owner at the subscription level, I am Owner of all resource groups and resources under that subscription. If I have Owner at a resource group level, I am Owner of all resources in that group.
The image below shows Owner access at the subscription level. 
Checking IAM for a resource group under that subscription shows inherited Owner access. 
That is how Azure’s RBAC is hierarchical. Many systems use similar hierarchies. In this tutorial we implement a comparable model with Casbin.
How Casbin works
Understanding Casbin’s building blocks (request, policy, matcher, effect) makes it easier to design and tune your RBAC model.
What is ACL?
ACL (Access Control List) maps users to actions and actions to resources.
Model definition
A minimal ACL model:
[request_definition]
r = sub, act, obj
[policy_definition]
p = sub, act, obj
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
- request_definition — Defines the request format. E.g.
alice, write, data1means “Can Alice write data1?” - policy_definition — Defines the policy format. E.g. a policy
alice, write, data1grants Alice permission to write data1. - policy_effect — How multiple matching policies are combined (e.g. allow-override).
- matchers — The condition that must hold:
r.sub == p.sub && r.obj == p.obj && r.act == p.act.
Try it in the Casbin editor
Open the Casbin editor and paste the model above into the Model editor.
Paste the following in the Policy editor:
p, alice, read, data1
p, bob, write, data2
and the following in the Request editor:
alice, read, data1
The result will be:
true
Visual representation of the ACL model, policy, and request matching

What is RBAC?
RBAC (Role-Based Access Control) assigns users to roles; roles have permissions on resources. A request checks whether the user’s role allows the action on the resource.
Model definition
A simple RBAC model:
[request_definition]
r = sub, act, obj
[policy_definition]
p = sub, act, obj
[role_definition]
g = _, _
g2 = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
- role_definition — Defines graph relations (e.g.
gfor role–role or user–role). The matcher uses these to resolve roles and permissions.
Try it in the Casbin editor
Open the editor and paste the model above.
Paste the following in the Policy editor:
p, alice, reader, data1
p, bob, owner, data2
g, reader, read
g, owner, read
g, owner, write
and the following in the Request editor:
alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1
The result will be:
true
false
true
true
false