How It Works

Dans Casbin, un modèle de contrôle d'accès est abstrait dans un fichier CONF basé sur le métamodèle PERM (Politique, Effet, Requête, Correspondances). Changer ou mettre à niveau le mécanisme d'autorisation pour un projet est aussi simple que de modifier une configuration. Vous pouvez personnaliser votre propre modèle de contrôle d'accès en combinant les modèles disponibles. Par exemple, vous pouvez combiner les rôles RBAC et les attributs ABAC ensemble à l'intérieur d'un modèle et partager un ensemble de règles de politique.

Le modèle PERM est composé de quatre fondations : Politique, Effet, Requête et Correspondances. Ces fondations décrivent la relation entre les ressources et les utilisateurs.

Request

Définit les paramètres de la requête. Une requête de base est un objet tuple, nécessitant au moins un sujet (entité accédée), un objet (ressource accédée) et une action (méthode d'accès).

Par exemple, une définition de requête peut ressembler à ceci : r={sub,obj,act}

Cette définition spécifie les noms de paramètres et l'ordre requis par la fonction de correspondance de contrôle d'accès.

Policy

Définit le modèle pour la stratégie d'accès. Il spécifie le nom et l'ordre des champs dans le document de règle de Politique.

Par exemple : p={sub, obj, act} ou p={sub, obj, act, eft}

Note : Si eft (résultat de la politique) n'est pas défini, le champ de résultat dans le fichier de politique ne sera pas lu, et le résultat de la politique correspondante sera autorisé par défaut.

Matcher

Définit les règles de correspondance pour la Requête et la Politique.

Par exemple : m = r.sub == p.sub && r.act == p.act && r.obj == p.obj Cette règle de correspondance simple et courante signifie que si les paramètres demandés (entités, ressources et méthodes) sont égaux à ceux trouvés dans la politique, alors le résultat de la politique (p.eft) est renvoyé. Le résultat de la stratégie sera sauvegardé dans p.eft.

Effect

Effectue un jugement de combinaison logique sur les résultats de correspondance des Correspondances.

Par exemple : e = some(where(p.eft == allow))

Cette déclaration signifie que si le résultat de la stratégie de correspondance p.eft a le résultat de (quelques) autorisations, alors le résultat final est vrai.

Regardons un autre exemple :

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

La signification logique de cette combinaison d'exemple est : s'il y a une stratégie qui correspond au résultat d'autorisation et aucune stratégie qui correspond au résultat de refus, le résultat est vrai. En d'autres termes, c'est vrai lorsque les stratégies de correspondance sont toutes autorisées. S'il y a un refus, les deux sont faux (plus simplement, lorsque l'autorisation et le refus existent en même temps, le refus a la priorité).

Le modèle le plus basique et le plus simple dans Casbin est ACL. Le modèle CONF pour ACL est le suivant :

# Request definition
[request_definition]
r = sub, obj, act

# Policy definition
[policy_definition]
p = sub, obj, act

# Policy effect
[policy_effect]
e = some(where (p.eft == allow))

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

Un exemple de politique pour le modèle ACL est :

p, alice, data1, read
p, bob, data2, write

Cela signifie :

• alice peut lire data1
• bob peut écrire data2

Nous prenons également en charge le mode multi-ligne en ajoutant '' à la fin :

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

De plus, si vous utilisez ABAC, vous pouvez essayer l'opérateur 'in' comme le montre l'exemple suivant pour l'édition golang de Casbin (jCasbin et Node-Casbin ne sont pas encore pris en charge) :

# Matchers
[matchers]
m = r.obj == p.obj && r.act == p.act || r.obj in ('data2', 'data3')

But you MUST make sure that the length of the array is MORE than 1, otherwise it will cause a panic.

Pour plus d'opérateurs, vous pouvez jeter un œil à govaluate.