RBAC
Rollen-Definition
[role_definition] defines RBAC role inheritance relationships. Casbin supports multiple independent RBAC systems: users can have roles with inheritance relationships, and resources can have their own roles with separate inheritance relationships. These RBAC systems operate independently.
Dieser Abschnitt ist optional. Omit it if your model doesn't use RBAC roles.
[role_definition]
g = _, _
g2 = _, _
This definition shows two RBAC systems: g and g2. The _,_ notation indicates two parties participate in each inheritance relationship. Typically, you'll use only g when roles apply to users alone. Use both g and g2 when roles apply to both users and resources. See rbac_model.conf and rbac_model_with_resource_roles.conf for examples.
Casbin stores user-role mappings (or resource-role mappings for resource roles) in the policy:
p, data2_admin, data2, read
g, alice, data2_admin
This means alice inherits from or belongs to role data2_admin. Here, alice represents a user, resource, or role. Casbin treats it as a string.
Check the role in a matcher:
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
This matcher verifies that the request's sub has the policy's sub role.
- Casbin stores only user-role mappings.
- Casbin doesn't validate users or roles. Authentication handles this responsibility.
- Avoid using the same name for both a user and a role within an RBAC system. Casbin treats users and roles as strings, making it impossible to distinguish between user
aliceand rolealice. Use prefixes likerole_aliceto avoid conflicts. - Role inheritance is transitive: if
Ahas roleB, andBhas roleC, thenAhas roleC. This transitivity is unlimited.
By convention, the subject token name in policy definitions is sub and appears first. Golang Casbin supports custom token names and positions. When the subject token name is sub, place it anywhere without additional configuration. For other subject token names, call e.SetFieldIndex() for constant.SubjectIndex after initializing the enforcer, regardless of position.
# `subject` here is for sub
[policy_definition]
p = obj, act, subject
e.SetFieldIndex("p", constant.SubjectIndex, 2) // index starts from 0
ok, err := e.DeleteUser("alice") // without SetFieldIndex, it will raise an error
Rollenhierarchie
Casbin's RBAC implements RBAC1's role hierarchy: when alice has role1, and role1 has role2, then alice inherits role2 and its permissions.
Hierarchy level describes the depth of role inheritance. In this example, the hierarchy level is 2. Casbin's built-in role manager lets you specify the maximum hierarchy level, defaulting to 10. This means an end user like alice can inherit up to 10 levels of roles.
// NewRoleManager is the constructor for creating an instance of the
// default RoleManager implementation.
func NewRoleManager(maxHierarchyLevel int) rbac.RoleManager {
rm := RoleManager{}
rm.allRoles = &sync.Map{}
rm.maxHierarchyLevel = maxHierarchyLevel
rm.hasPattern = false
return &rm
}
Wie unterscheidet man Rolle von Benutzer?
Casbin treats roles and users identically in RBAC—both are strings. For single-level RBAC (where roles never belong to other roles), use e.GetAllSubjects() to list all users and e.GetAllRoles() to list all roles. These functions return all u and all r values from g, u, r rules.
For multi-level RBAC (with role hierarchy), if your application doesn't track whether a name represents a user or role, or if users and roles share names, add a prefix like role::admin before passing it to Casbin. Check for this prefix to identify roles.
Wie fragt man implizite Rollen oder Berechtigungen ab?
When users inherit roles or permissions through RBAC hierarchy rather than direct policy assignment, we call these "implicit" assignments. Query implicit relationships using GetImplicitRolesForUser() and GetImplicitPermissionsForUser() instead of GetRolesForUser() and GetPermissionsForUser(). See this GitHub issue for details.
Verwendung von Musterabgleich in RBAC
Siehe RBAC mit Muster
Rollenmanager
Siehe den Abschnitt Rollenmanager für Details.