RBAC

Définition du rôle

Le [role_definition] est utilisé pour définir les relations d'héritage de rôle RBAC. Casbin prend en charge plusieurs instances de systèmes RBAC, où les utilisateurs peuvent avoir des rôles et leurs relations d'héritage, et les ressources peuvent également avoir des rôles et leurs relations d'héritage. Ces deux systèmes RBAC ne se gêneront pas mutuellement.

Cette section est facultative. Si vous n'utilisez pas de rôles RBAC dans le modèle, alors omettez cette section.

[role_definition]
g = _, _
g2 = _, _

La définition de rôle ci-dessus montre que g est un système RBAC, et g2 est un autre système RBAC. _,_ signifie qu'il y a deux parties impliquées dans une relation d'héritage. Dans le cas le plus courant, vous utilisez généralement g seul si vous n'avez besoin de rôles que pour les utilisateurs. Vous pouvez également utiliser à la fois g et g2 lorsque vous avez besoin de rôles (ou de groupes) à la fois pour les utilisateurs et les ressources. Veuillez voir les rbac_model.conf et rbac_model_with_resource_roles.conf pour des exemples.

Casbin stocke la cartographie réelle utilisateur-rôle (ou la cartographie ressource-rôle si vous utilisez des rôles sur les ressources) dans la politique. Par exemple :

p, data2_admin, data2, read
g, alice, data2_admin

Cela signifie que alice hérite/est membre du rôle data2_admin. Ici, alice peut être un utilisateur, une ressource, ou un rôle. Casbin ne le reconnaît que comme une chaîne.

Ensuite, dans un comparateur, vous devriez vérifier le rôle comme indiqué ci-dessous :

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

Cela signifie que le sub dans la requête devrait avoir le rôle sub dans la politique.

note

Casbin ne stocke que la cartographie utilisateur-rôle.
Casbin ne vérifie pas si un utilisateur est un utilisateur valide ou si un rôle est un rôle valide. Cela devrait être pris en charge par l'authentification.
N'utilisez pas le même nom pour un utilisateur et un rôle à l'intérieur d'un système RBAC, car Casbin reconnaît les utilisateurs et les rôles comme des chaînes, et il n'y a aucun moyen pour Casbin de savoir si vous spécifiez l'utilisateur alice ou le rôle alice. Vous pouvez simplement le résoudre en utilisant role_alice.
Si A a le rôle B, et B a le rôle C, alors A a le rôle C. Cette transitivité est infinie pour l'instant.

Convention de nom de jeton

Conventionnellement, le nom du jeton sujet dans la définition de la politique est sub et placé au début. Maintenant, Golang Casbin prend en charge les noms de jetons personnalisés et les places. Si le nom du jeton sujet est sub, le jeton sujet peut être placé à un endroit arbitraire sans aucune action supplémentaire nécessaire. Si le nom du jeton de sujet n'est pas sub, e.SetFieldIndex() pour constant.SubjectIndex doit être appelé après l'initialisation de l'exécuteur, quelle que soit sa 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

Hiérarchie des rôles

Le RBAC de Casbin prend en charge la fonctionnalité de hiérarchie des rôles de RBAC1, ce qui signifie que si alice a role1, et role1 a role2, alors alice aura également role2 et héritera de ses permissions.

Ici, nous avons un concept appelé niveau de hiérarchie. Donc, dans cet exemple, le niveau de hiérarchie est 2. Pour le gestionnaire de rôles intégré dans Casbin, vous pouvez spécifier le niveau de hiérarchie maximum. La valeur par défaut est 10. Cela signifie qu'un utilisateur final comme alice ne peut hériter que de 10 niveaux de rôles.

// 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
}

Comment distinguer le rôle de l'utilisateur ?

Casbin ne fait pas de distinction entre les rôles et les utilisateurs dans son RBAC. Ils sont tous deux traités comme des chaînes de caractères. Si vous n'utilisez qu'un RBAC à un seul niveau (où un rôle ne sera jamais membre d'un autre rôle), vous pouvez utiliser e.GetAllSubjects() pour obtenir tous les utilisateurs et e.GetAllRoles() pour obtenir tous les rôles. Ils listeront tous les u et tous les r, respectivement, dans toutes les règles g, u, r.

Mais si vous utilisez un RBAC à plusieurs niveaux (avec hiérarchie des rôles) et que votre application n'enregistre pas si un nom (chaîne) est un utilisateur ou un rôle, ou si vous avez un utilisateur et un rôle avec le même nom, vous pouvez ajouter un préfixe au rôle comme role::admin avant de le passer à Casbin. De cette façon, vous saurez si c'est un rôle en vérifiant ce préfixe.

Comment interroger les rôles ou les permissions implicites ?

Lorsqu'un utilisateur hérite d'un rôle ou d'une permission via la hiérarchie RBAC au lieu de se les voir attribuer directement dans une règle de politique, nous appelons ce type d'attribution "implicite". Pour interroger de telles relations implicites, vous devez utiliser ces deux API : GetImplicitRolesForUser() et GetImplicitPermissionsForUser() au lieu de GetRolesForUser() et GetPermissionsForUser(). Pour plus de détails, veuillez consulter cette question GitHub.