Understanding How Casbin Matching Works in Detail

Dans cet article, j'expliquerai la conception et la mise en œuvre de RBAC en utilisant la bibliothèque Casbin. Pour une plateforme SaaS qui gère plusieurs hiérarchies de ressources et des rôles qui héritent des permissions des niveaux supérieurs, Casbin offre une alternative performante à considérer.

Introduction à RBAC

RBAC est une méthode de restriction d'accès aux ressources basée sur les rôles que les individus détiennent. Pour mieux comprendre comment fonctionne le RBAC hiérarchique, examinons le système RBAC d'Azure dans la section suivante, puis essayons de mettre en œuvre un système similaire.

Comprendre le RBAC hiérarchique d'Azure

Il existe un rôle appelé Propriétaire pour toutes les ressources dans Azure. Supposons que si j'ai le rôle de Propriétaire qui m'est attribué au niveau de l'abonnement, cela signifie que je suis le Propriétaire de tous les groupes de ressources et des ressources sous cet abonnement. Si j'ai le rôle de Propriétaire au niveau du groupe de ressources, alors je suis le Propriétaire de toutes les ressources sous ce groupe de ressources.

Cette image montre que j'ai un accès de Propriétaire au niveau de l'abonnement.

Lorsque je vérifie l'IAM d'un groupe de ressources sous cet abonnement, vous pouvez voir que j'ai hérité de l'accès de Propriétaire de l'abonnement.

C'est donc ainsi que le RBAC d'Azure est hiérarchique. La plupart des logiciels d'entreprise utilisent le RBAC hiérarchique en raison de la nature hiérarchique des niveaux de ressources. Dans ce tutoriel, nous essaierons de mettre en œuvre un système similaire en utilisant Casbin.

Comment fonctionne Casbin ?

Avant de plonger dans la mise en œuvre, il est important de comprendre ce qu'est Casbin et comment il fonctionne à un niveau élevé. Cette compréhension est nécessaire car chaque système de contrôle d'accès basé sur les rôles (RBAC) peut varier en fonction des exigences spécifiques. En saisissant le fonctionnement de Casbin, nous pouvons efficacement affiner le modèle.

Qu'est-ce que l'ACL ?

ACL signifie Liste de contrôle d'accès. C'est une méthode dans laquelle les utilisateurs sont mappés à des actions et les actions à des ressources.

La définition du modèle

Prenons un exemple simple d'un modèle ACL.

[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

1. La request_definition est le modèle de requête du système. Par exemple, une requête alice, write, data1 peut être interprétée comme "Le sujet Alice peut-il effectuer l'action 'write' sur l'objet 'data1' ?".

2. La policy_definition est le modèle d'attribution du système. Par exemple, en créant une politique alice, write, data1, vous attribuez à Alice la permission d'effectuer l'action 'write' sur l'objet 'data1'.

3. policy_effect définit l'effet de la politique.

4. Dans la section matchers, la demande est mise en correspondance avec la politique en utilisant les conditions r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Testons maintenant le modèle sur l'éditeur Casbin

Ouvrez l'éditeur et collez le modèle ci-dessus dans l'éditeur de modèle.

Collez ce qui suit dans l'éditeur de politique :

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

et ce qui suit dans l'éditeur de demande :

alice, read, data1

Le résultat sera :

true

Représentation visuelle du modèle ACL, de la politique et de la correspondance des demandes

Qu'est-ce que le RBAC ?

RBAC signifie Contrôle d'Accès Basé sur les Rôles. Dans le RBAC, un utilisateur se voit attribuer un rôle pour une ressource, et un rôle peut contenir des actions arbitraires. La demande vérifie ensuite si l'utilisateur a la permission d'effectuer l'action sur la ressource.

La définition du modèle

Prenons un exemple simple de modèle RBAC :

[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

1. La role_definition est un constructeur de relation de graphique qui utilise un Graphique pour comparer l'objet de la demande avec l'objet de la politique.

Testons maintenant le modèle sur l'éditeur Casbin

Ouvrez l'éditeur et collez le modèle ci-dessus dans l'éditeur de modèle.

Collez ce qui suit dans l'éditeur de politique :

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

et ce qui suit dans l'éditeur de demande :

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

Le résultat sera :

true
false
true
true
false

Représentation visuelle du modèle RBAC, de la politique et de la correspondance des demandes

Le tableau g - Role to action mapping a un Graphique qui mappe le rôle à l'action. Ce Graphique peut être codé sous forme de liste d'arêtes, comme le montre la politique qui est une façon courante de représenter un Graphique :

g, reader, read
g, owner, read
g, owner, write

Infos

p indique une politique normale qui peut être comparée en utilisant l'opérateur ==. g est une fonction de comparaison basée sur un Graphique. Vous pouvez définir plusieurs comparateurs de Graphiques en ajoutant un suffixe numérique comme g, g2, g3, ... et ainsi de suite.

Qu'est-ce que le RBAC hiérarchique ?

Dans le RBAC hiérarchique, il y a plus d'un type de ressources et il existe une relation d'héritage entre les types de ressources. Par exemple, "subscription" est un type et "resourceGroup" est un autre type. Un sub1 de type Subscription peut contenir plusieurs resourceGroups (rg1, rg2) de type ResourceGroup.

Semblable à la hiérarchie des ressources, il y aura deux types de rôles et d'actions : les rôles et actions de Subscription, et les rôles et actions de ResourceGroup. Il existe une relation arbitraire entre le rôle de Subscription et le rôle de ResourceGroup. Par exemple, considérons un rôle de Subscription sub-owner. Ce rôle est hérité par un rôle de ResourceGroup rg-owner, ce qui signifie que si je suis assigné le rôle sub-owner sur Subscription sub1, alors j'obtiens automatiquement aussi le rôle rg-owner sur rg1 et rg2.

La définition du modèle

Prenons un exemple simple du modèle Hierarchical RBAC :

[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) && g2(p.obj, r.obj)

1. Le role_definition est un constructeur de relation de graphique qui utilise un Graph pour comparer l'objet de requête avec l'objet de politique.

Maintenant, testons le modèle sur l'éditeur Casbin

Ouvrez l'éditeur et collez le modèle ci-dessus dans l'éditeur de modèle.

Collez ce qui suit dans l'éditeur de politique :

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Et collez ce qui suit dans l'éditeur de requête :

alice, rg-read, rg1

Le résultat sera :

true

Représentation visuelle du modèle RBAC, de la politique, et de la correspondance de la requête

Le tableau g - Role to (Action, Role) Mapping a un graphique mappant le rôle à l'action, le mappage de rôle. Ce graphique peut être codé sous forme de liste de bords, comme le montre la politique, qui est une façon courante de représenter un graphique :

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

Le tableau g2 - Sub to RG Mapping a un graphique mappant l'abonnement au resourceGroup :

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Représentation visuelle de la correspondance des sujets

Représentation visuelle de la correspondance des actions

Représentation visuelle de la correspondance des objets

Infos

Lorsqu'une demande est soumise à Casbin, cette correspondance se produit pour toutes les politiques. Si au moins une politique correspond, alors le résultat de la demande est vrai. Si aucune politique ne correspond à la demande, alors le résultat est faux.

Conclusion

Dans ce tutoriel, nous avons appris comment fonctionnent différents modèles d'autorisation et comment ils peuvent être modélisés en utilisant Casbin. Dans la deuxième partie de ce tutoriel, nous mettrons cela en œuvre dans une démo d'application Spring Boot et sécuriserons les API en utilisant Casbin.