2024 was the year AI agents went from demos to production. With the Model Context Protocol (MCP) gaining adoption from Google, OpenAI, Microsoft, and countless others, we're seeing a fundamental shift in how applications interact with external services. And with that shift comes a whole new set of authorization challenges that we at Casbin have been thinking about.

In this post, I will explain the design and implementation of RBAC using the Casbin library. For a SaaS platform dealing with multiple resource hierarchies and roles that inherit permissions from higher levels, Casbin provides a performant alternative to consider.

Introduction to RBAC​

RBAC is a method of restricting access to resources based on the roles that individuals hold. To better understand how hierarchical RBAC works, let's take a look at Azure's RBAC system in the next section and then attempt to implement a similar system.

Understanding Azure's Hierarchical RBAC​

There is a role called Owner for all resources in Azure. Suppose if I have the Owner role assigned to me at the subscription level, that means I am the Owner of all the resource groups and resources under that subscription. If I have Owner at the resource group level, then I am the Owner of all the resources under that resource group.

This image shows that I have Owner access at the subscription level.

When I check the IAM of a Resource Group under this Subscription, you can see that I have inherited Owner access from the subscription.

So, this is how Azure's RBAC is hierarchical. Most enterprise software uses hierarchical RBAC because of the hierarchical nature of the resource levels. In this tutorial, we'll try to implement a similar system using Casbin.

How Does Casbin Work?​

Before diving into the implementation, it is important to understand what Casbin is and how it functions at a high level. This understanding is necessary because each Role-Based Access Control (RBAC) system may vary based on specific requirements. By grasping the workings of Casbin, we can effectively fine-tune the model.

What is ACL?​

ACL stands for Access Control List. It is a method in which users are mapped to actions and actions to resources.

The model definition​

Let's consider a simple example of an ACL model.

[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. The request_definition is the query template of the system. For example, a request alice, write, data1 can be interpreted as "Can subject Alice perform the action 'write' on object 'data1'?".

2. The policy_definition is the assignment template of the system. For example, by creating a policy alice, write, data1, you are assigning permission to subject Alice to perform the action 'write' on object 'data1'.

3. The policy_effect defines the effect of the policy.

4. In the matchers section, the request is matched with the policy using the conditions r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

and the following in the Request editor:

alice, read, data1

The result will be:

true

Visual representation of the ACL model, policy, and request matching​

What is RBAC?​

RBAC stands for Role-Based Access Control. In RBAC, a user is assigned a role for a resource, and a role can contain arbitrary actions. The request then checks if the user has the permission to perform the action on the resource.

The model definition​

Let's consider a simple example RBAC model:

[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. The role_definition is a graph relation builder that uses a Graph to compare the request object with the policy object.

Now let's test the model on Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

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

and the following in the Request editor:

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

The result will be:

true
false
true
true
false

Visual representation of the RBAC model, policy, and request matching​

The g - Role to action mapping table has a Graph mapping the role to action. This Graph can be coded as a list of edges, as shown in the policy which is a common way of representing a Graph:

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

What is Hierarchical RBAC?​

In Hierarchical RBAC, there are more than one type of resources and there is an inheritance relationship between the resource types. For example, "subscription" is one type and "resourceGroup" is another type. A sub1 of type Subscription can contain multiple resourceGroups (rg1, rg2) of type ResourceGroup.

Similar to the resource hierarchy, there will be two types of roles and actions: Subscription roles and actions, and ResourceGroup roles and actions. There is an arbitrary relationship between the Subscription role and ResourceGroup role. For example, consider a Subscription Role sub-owner. This role is inherited by a ResourceGroup Role rg-owner, which means that if I am assigned the sub-owner role on Subscription sub1, then I automatically also get the rg-owner role on rg1 and rg2.

The model definition​

Let's take a simple example of the Hierarchical RBAC model:

[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. The role_definition is a graph relation builder which uses a Graph to compare the request object with the policy object.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

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

And paste the following in the Request editor:

alice, rg-read, rg1

The result will be:

true

Visual representation of the RBAC model, policy, and request matching​

The g - Role to (Action, Role) Mapping table has a graph mapping the role to the action, role mapping. This graph can be coded as a list of edges, as shown in the policy, which is a common way of representing a graph:

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

The g2 - Sub to RG Mapping table has a graph mapping subscription to resourceGroup:

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

Subject Matching Visual representation​

Action Matching Visual representation​

Object Matching Visual representation​

Conclusion​

In this tutorial, we learned about how different authorization models work and how they can be modeled using Casbin. In the second part of this tutorial, we will implement this in a demo Spring Boot Application and secure the APIs using Casbin.

Introduction​

APISIX est une passerelle native de nuage haute performance et évolutive basée sur Nginx et etcd. C'est un projet open source de la Fondation du logiciel Apache. En plus de cela, ce qui rend APISIX si bon est le support de nombreux plugins qui pourraient être utilisés pour implémenter des fonctionnalités comme l'authentification, surveillance, routage, etc. Et le fait que les plugins d'APISIX soient rechargés à chaud (sans redémarrage) le rend très dynamique.

Mais lorsque vous utilisez APISIX, il peut y avoir des scénarios où vous pourriez vouloir ajouter une logique d'autorisation complexe dans votre application. C'est là que authz-casbin pourrait vous aider, authz-casbin est un plugin APISIX basé sur Lua Casbin qui permet une autorisation puissante basée sur différents modèles de contrôle d'accès. Casbin est une bibliothèque d'autorisation qui prend en charge les modèles de contrôle d'accès comme ACL, RBAC, ABAC. Initialement écrit en Go, il a été porté dans de nombreuses langues et Lua Casbin est l'implémentation Lua de Casbin. Le développement de authz-casbin a commencé quand nous avons proposé un nouveau plugin d'autorisation dans le dépôt APISIX (#4674) auquel les membres du noyau se sont mis d'accord. Et après les critiques utiles qui ont conduit à des changements et améliorations majeurs, le PR (#4710) a finalement été fusionné.

Dans ce blog, nous utiliserons le plugin authz-casbin pour montrer comment vous pouvez implémenter un modèle d'autorisation basé sur le contrôle d'accès basé sur les rôles (RBAC) dans APISIX.

NOTE: Vous devrez utiliser un autre plugin ou un workflow personnalisé pour l'authentification de l'utilisateur puisque Casbin ne fera que l'autorisation et non l'authentification.

Création d'un modèle​

Le plugin utilise trois paramètres pour autoriser toute requête - sujet, objet et action. Ici, le sujet est la valeur de l'en-tête du nom d'utilisateur, qui pourrait être quelque chose comme [username: alice]. Ensuite, l'objet est le chemin URL auquel on accède et l'action est la méthode de requête utilisée.

Disons que nous voulons créer un modèle avec trois ressources dans les chemins - /, /res1 et /res2. Et nous voulons avoir un modèle comme celui-ci :

Cela signifierait que tous les utilisateurs (*) comme par exemple jack peuvent accéder à la page d'accueil (/). Et les utilisateurs avec les permissions admin comme alice et bob peuvent accéder à toutes les pages et toutes les ressources (comme res1 et res2). Aussi, limitons les utilisateurs qui n'ont pas les permissions d'administration à utiliser uniquement la méthode de requête GET. Pour ce scénario, nous pourrions définir le modèle comme:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, agir

[role_definition]
g = _, _

[policy_effect]
e = quelque (où (p. ft == allow))

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

Créer une politique​

À partir du scénario ci-dessus, la politique serait:

p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin

La correspondance du modèle signifie :

1. (g(r.sub, p.sub) || keyMatch(r.sub, p. ub)): Soit le sujet de la requête a un rôle en tant que sujet de la règle ou celui de la requête correspond au sujet de la règle dans keyMatch. keyMatch est inclus dans la fonction Lua Casbin, vous pouvez jeter un œil à la description de la fonction et plus de fonctions qui pourraient être utiles ici.
2. keyMatch(r.obj, p.obj): l'objet de la requête correspond à l'objet de la politique (chemin URL ici).
3. keyMatch(r.act, p.act): l'action de la requête correspond à l'action de la politique (méthode de requête HTTP ici).

Activation du plugin sur la route​

Une fois que vous avez créé le modèle et la politique, vous pouvez l'activer sur une route en utilisant l'API Admin APISIX. Pour l'activer en utilisant les chemins du modèle et des fichiers de régulation :

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model_path": "/path/to/model. onf",
            "policy_path": "/path/to/policy. sv",
            "username": "username"
        }
    },
    "amon": {
        "nodes": {
            "127. 0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Ici, le champ nom d'utilisateur est le nom d'en-tête que vous utiliserez pour passer dans le sujet. Par exemple, si vous passez l'en-tête du nom d'utilisateur en tant qu'utilisateur : alice, vous utiliserez "username": "user".

Pour utiliser le texte modèle/politique au lieu de fichiers, vous pouvez utiliser les champs modèle et politique à la place:

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model": "[request_definition]
            r = sub, obj, act

            [policy_definition]
            p = sub, obj, act

            [role_definition]
            g = _, _

            [policy_effect]
            e = quelque part (où (p. ft == allow))

            [matchers]
            m = (g(r. ub, p. ub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p. ct)",

            "polices": "p, *, /, GET
            p, admin, *, *
            g, alice, admin
            g, bob, admin",

            "username": "username"
        }
    },
    "amon": {
        "nodes": {
            "127. 0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Activer le plugin en utilisant un modèle/politique global​

Il peut y avoir des situations où vous pourriez vouloir utiliser un modèle unique et une configuration de règles sur plusieurs routes. Vous pouvez le faire d'abord en envoyant une requête PUT pour ajouter le modèle et la configuration de la politique aux métadonnées du plugin par:

curl http://127.0.0. :9080/apisix/admin/plugin_metadata/authz-casbin -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
"modèle": "[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = quelque part (où (p. ft == allow))

[matchers]
m = (g(r.sub, p.sub) || keyMatch(r. ub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r. ct, p.act)",

"policy": "p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin"
}'

Et puis pour activer la même configuration sur une certaine route, envoyez une requête en utilisant l'API Admin :

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "username": "username"
        }
    },
    "amon": {
        "nodes": {
            "127. 0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/route1/*"
}'

Ceci ajoutera la configuration des métadonnées du plugin à la route. Vous pouvez aussi facilement mettre à jour la configuration des métadonnées du plugin en renvoyant la demande vers les métadonnées du plugin avec la mise à jour du modèle et la configuration de la politique, le plugin mettra à jour automatiquement toutes les routes en utilisant les métadonnées du plugin.

Cas d'utilisation​

• Le cas d'utilisation principal de ce plugin serait l'implémentation de l'autorisation dans vos API. Vous pouvez facilement ajouter ce plugin sur n'importe quelle route API que vous utilisez avec votre modèle d'autorisation et la configuration de la politique.
• Si vous voulez avoir un modèle d'autorisation unique pour toutes vos API, vous pouvez utiliser la méthode du modèle global. Cela rend la mise à jour de la politique facile pour tous les itinéraires, car vous n'avez qu'à mettre à jour les métadonnées dans etcd.
• Si vous souhaitez utiliser un modèle différent pour chaque itinéraire, vous pouvez utiliser la méthode de l'itinéraire. Ceci est utile lorsque les différentes routes de l'API ont différents ensembles de permissions d'utilisateur. Vous pouvez également utiliser cela lorsque vous avez affaire à des politiques plus importantes, car cela rendra l’autorisation plus rapide lorsque filtrée sur plusieurs routes.

Aujourd'hui, nous sommes heureux d'annoncer que le fondateur de Casbin, Yang Luo, a reçu le prix "Google Open Source Peer Bonus diners" pour son travail sur Casbin, Np cap et IMAP au 3e trimestre 2019.

La lettre originale de récompense peut être consultée ici.

Le programme Google Open Source Peer Bonus est décrit comme :

De la même manière qu'un bonus Google Pair est utilisé pour reconnaître un autre Googler qui a dépassé et au-delà, un bonus de pair Open Source reconnaît les personnes externes qui ont apporté des contributions exceptionnelles à l'open source.

L'annonce pour les gagnants de 2019 est disponible à :

https://opensource.googleblog.com/2020/01/announcing-2019-second-cycle-google.html

Yang et Casbin sont listés parmi les développeurs et les projets open source qui ont un impact pertinent là-bas, comme Git, TensorFlow, V8, CPython, LLVM, projets Apache, Angular ou Jenkins.

Nous sommes heureux de voir que Casbin est ainsi reconnu pour sa contribution à la sécurité de l'open source et du cloud!

Merci d'avoir volé Casbin!

Aujourd'hui, nous avons migré la documentation de Casbin depuis le Wiki GitHub vers les Docs de ce site, qui est propulsé par Docusaurus. Docusaurus fournit beaucoup de fonctionnalités géniales comme de meilleurs styles Markdown, recherche plein texte, versioning, traduction.

La documentation n'est pas encore parfaite et a encore besoin d'être améliorée. Le code source est hébergé à sur GitHub: https://github.com/casbin/casbin-website-v2 .

Toute contribution ou suggestion est la bienvenue!

Aujourd'hui, nous avons porté Casbin sur Node.js, qui est nommé comme: node-Casbin.

node-Casbin partage l'utilisation et l'API similaires avec d'autres implémentations de Casbin. Les produits du milieu pour Express, Koa2 et Egg.js sont prêts à être utilisés. L'adaptateur de stockage pour Sequelize est également préparé.

J'espère qu'il pourra bien servir votre besoin :)

GitHub: https://github.com/casbin/node-casbin

Certains de nos clients demandent si Casbin peut être utilisé comme un service au lieu d'une bibliothèque. La réponse est OUI. Aujourd'hui, nous avons lancé le projet Casbin Server en tant que solution concrète pour Le contrôle d'accès en tant que service.

Le serveur Casbin est en cours de développement par notre équipe de base. Il a plusieurs caractéristiques :

• Purement développé à Golang.
• Peut gérer des milliers d'instances Casbin, de sorte que vous pouvez déplacer la logique d'application de la politique de plusieurs services vers un seul serveur Casbin.
• gRPC est utilisé pour communiquer avec le serveur Casbin. Nous envisageons également d'ajouter le support RESTful dans un avenir proche.
• Un portail administrateur web convivial est fourni aux administrateurs non-développeurs pour gérer tous les détails tels que les instances, les modèles, les politiques de stockage et l'équilibrage de charge.

Le code source est hébergé sur GitHub : https://github.com/casbin/casbin-server

Tous les problèmes ou demandes de fusion sont les bienvenus :)