Résumé de l'utilisation de la bibliothèque de contrôle d'accès (autorisation) Casbin
Casbin utilise un modèle de contrôle d'accès basé sur PERM (Policy, Effect, Request, Matcher). La définition du modèle est décrite dans le fichier conf, mais il est nécessaire de décrire au moins quatre sections, définition de politique, effet de politique, définition de demande et correspondance, qui correspondent à PERM.
Access Control List (ACL)
La méthode de définition du modèle Casbin sera expliquée en utilisant l'ACL définition du modèle utilisée dans les systèmes de fichiers, etc. comme sujet. (Référence: Syntaxe pour les modèles)
Request Definition
[request_definition]
r = sub, obj, act
[request_definition] définit un modèle pour entrer une demande d'accès. Comme la définition du modèle ACL, dans la plupart des cas, trois sont utilisés: sub (exécuteur d'accès), ʻobj (cible d'accès) et ʻact (méthode d'accès).
Policy Definition
[policy_definition]
p = sub, obj, act
[policy_definition] définit le format de description de politique. Si vous écrivez une politique qui "file1 (obj)peut être read (act) by user1 (sub) ʻin cette définition de modèle, ce sera p, user1, file1, read`.
Matcher
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
[machers] définit une expression conditionnelle qui recherche une politique qui correspond à la demande de jugement d'accès. Accéder à la demande de jugement r et à la politique p Référez-vous au modèle défini dans chaque[définition_demande]avec . et décrivez l'expression conditionnelle.
Dans la définition du modèle ACL, il est déterminé que toutes les demandes de jugement d'accès «sub» «obj» «act »correspondent à la politique de correspondance.
Policy Effect
[policy_effect]
e = some(where (p.eft == allow))
[policy_effect] définit comment porter un jugement lorsque plusieurs politiques correspondent à la demande de jugement d'accès.
Dans la définition du modèle ACL, si l'une des politiques qui correspondent à l'expression conditionnelle de Matcher a la valeur ʻeft définie sur ʻallow (some), la permission est jugée.
Ce ʻeft est un élément défini dans la définition de politique lors de la définition d'une politique de refus d'accès (liste noire). Si ʻeft n'est pas défini dans la définition de politique comme dans la définition du modèle ACL, p.eft est supposé avoir ʻallow défini (la valeur par défaut est ʻallow). Consultez Deny-override dans les modèles pris en charge (https://casbin.org/docs/en/supported-models) pour un exemple d'utilisation de la stratégie de refus d'accès.
Role Based Access Control (RBAC)
Pour prendre en charge RBAC, les deux points suivants doivent être modifiés par rapport à la définition du modèle ACL. (Référence: RBAC)
Role Definition
[role_definition]
g = _, _
[role_definition] (section facultative) définit le format de description de rôle. (Il est facile à comprendre si vous le considérez comme une version de rôle de [policy_definition].)
Si vous décrivez l'affectation de «role1» à «user1» dans cette définition de modèle, ce sera «g, user1, role1».
Matchers
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
«[matchers]» fait référence à la définition de rôle en tant que fonction et correspond à la combinaison de l'exécuteur d'accès «r.sub» (utilisateur) de la demande de jugement d'accès et de l'exécuteur d'accès «p.sub» (rôle) de la politique. Déterminez si la politique existe.
Présentez un exemple d'implémentation qui lit la définition de modèle de rbac_model.conf et détermine les rôles, les politiques et les demandes d'accès. ..
/*Définition du modèle de charge*/
Enforcer se = new Enforcer(ClassLoader.getSystemResource("rbac_model.conf").getFile());
//Utiliser la classe SyncedEnforcer pour une utilisation multi-thread
// Enforcer se = new SyncedEnforcer(ClassLoader.getSystemResource("rbac_model.conf").getFile());
/*Attribution de rôle*/
se.addNamedGroupingPolicy("g", "user1", "role1");
//Nom du rôle (groupe) par défaut"g"Il existe également une méthode pour attribuer à
//se.addGroupingPolicy("user1", "role1");
//se.addRoleForUser("user1", "role1");
se.addNamedPolicy("p", "role1", "data1", "read");
//Nom de stratégie par défaut"p"Il existe également une méthode pour ajouter une stratégie à
se.addPolicy("role1", "data1", "read");
/*Jugement de la demande d'accès*/
if (se.enforce("user1", "data1", "read")) {
System.out.println("user1 can read data1.");
}
if (se.enforce("role1", "data1", "read")) {
System.out.println("role1 can read data1.");
}
/*Obtenir le rôle d'utilisateur*/
List<String> roleList = se.getRolesForUser("user1");
System.out.println("user1 has " + roleList + " roles.");
Résultat d'exécution
user1 can read data1.
role1 can read data1.
user1 has [role1] roles.