Zum Hauptinhalt springen

· 5 Min. gelesen
Yang Luo

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.

· 7 Min. gelesen
Aravinda Kumar

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​

Azure Hierarchy

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. Subscription Owner

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

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​

acl

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​

rbac

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
info

p indicates a normal policy that can be compared using the == operator. g is a Graph-based comparison function. You can define multiple Graph comparators by adding a numerical suffix like g, g2, g3, ... and so on.

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​

hrbac

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​

hrbac-sub-match

Action Matching Visual representation​

hrbac-act-match

Object Matching Visual representation​

hrbac-obj-match

info

When a request is submitted to Casbin, this matching happens for all the policies. If at least one policy matches, then the result of the request is true. If no policy matches the request, then the result is false.

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.

· 6 Min. gelesen
Rushikesh Tote

Einführung​

APISIX ist ein hochleistungsfähiges und skalierbares natives API Gateway basierend auf Nginx und etc. Es ist ein Open-Source-Projekt der Apache Software Foundation. Außerdem ist das, was APISIX so gut macht, die Unterstützung vieler großartiger Plugins, die verwendet werden könnten, um Funktionen wie Authentifizierung zu implementieren, überwachen, routing, etc. Und die Tatsache, dass Plugins in APISIX heiß neu geladen werden (ohne Neustart) macht es sehr dynamisch.

Bei Verwendung von APISIX kann es jedoch zu Szenarien kommen, bei denen Sie möglicherweise komplexe Autorisierungslogik in Ihrer Anwendung hinzufügen möchten. Hier könnte Ihnen authz-casbin helfen authz-casbin ist ein APISIX-Plugin, das auf Lua Casbin basiert, das eine leistungsstarke Autorisierung basierend auf verschiedenen Zugriffskontrollmodellen ermöglicht. Casbin ist eine Autorisierungsbibliothek, die Zugriffskontrollmodelle wie ACL, RBAC, ABAC unterstützt. Ursprünglich in Go geschrieben, wurde es in viele Sprachen portiert und Lua Casbin ist die Lua-Implementierung von Casbin. Die Entwicklung von authz-casbin startete, als wir ein neues Plugin für die Autorisierung im APISIX-Repository (#4674), dem die Kernmitglieder zugestimmt haben, vorschlugen. Und nach den hilfreichen Bewertungen, die zu einigen wesentlichen Änderungen und Verbesserungen geführt haben, wurde die PR (#4710) schließlich zusammengeführt.

In diesem Blog, wir werden das authz-casbin Plugin verwenden, um zu zeigen, wie Sie ein Autorisierungsmodell basierend auf der Role Based Access Control (RBAC) in APISIX implementieren können.

HINWEIS: Sie müssen ein anderes Plugin oder einen benutzerdefinierten Workflow verwenden, um den Benutzer zu authentifizieren, da Casbin nur die Autorisierung und keine Authentifizierung durchführt.

Erstellen eines Modells​

Das Plugin verwendet drei Parameter, um jede Anfrage zu autorisieren - Subjekt, Objekt und Aktion. Betreff ist hier der Wert des Benutzernamen-Headers, der so etwas wie [Benutzername: alice] sein könnte. Dann ist das Objekt der URL-Pfad, auf den zugegriffen wird und die Aktion ist die Anfragemethode, die verwendet wird.

Nehmen wir an, wir wollen ein Modell mit drei Ressourcen an den Pfaden erstellen - /, /res1 und /res2. Und wir wollen ein Modell wie dies:

bild

Dies würde bedeuten, dass alle Benutzer (*) wie zum Beispiel jack auf die Homepage zugreifen können (/). Und Benutzer mit admin Berechtigungen wie alice und bob können auf alle Seiten und Ressourcen zugreifen (wie res1 und res2). Lass uns Benutzer ohne Administratorrechte auf nur GET Anfragemethode beschränken. Für dieses Szenario könnten wir das Modell definieren als:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, handeln

[role_definition]
g = _, _

[policy_effect]
e = irgendwo (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)

Richtlinien erstellen​

Aus dem oben genannten Szenario wäre die Politik folgende:

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

Der Matcher des Modells bedeutet:

  1. (g(r.sub, p.sub) || keyMatch(r.sub, p. ub)): Entweder hat der Betreff des Antrags eine Rolle als Betreff der Richtlinie, oder der Betreff des Antrags passt in keyMatch. keyMatch ist in Funktion in Lua Kasbin Sie können einen Blick auf die Beschreibung der Funktion werfen und mehr solche Funktionen, die hier nützlich sein könnten.
  2. keyMatch(r.obj, p.obj): Das Objekt der Anfrage entspricht dem Objekt der Richtlinie (URL-Pfad hier).
  3. keyMatch(r.act, p.act): Die Aktion des Requests stimmt mit der Aktion der Richtlinie überein (HTTP-Request-Methode hier).

Aktiviere das Plugin auf der Route​

Sobald Sie das Modell und die Richtlinie erstellt haben, können Sie es auf einer Route mit der APISIX Admin API aktivieren. Um es mit Modell- und Richtlinien-Datei-Pfaden zu aktivieren:

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",
            "Benutzername": "Benutzername"
        }
    },
    "upstream": {
        "nodes": {
            "127. .0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Hier ist das Feld Benutzername der Headername, den Sie im Betreff übergeben werden. Wenn Sie zum Beispiel den Benutzernamen als Benutzer übergeben werden: Alice, würden Sie "Benutzername": "Benutzer" verwenden.

Um Modell-/Richtlinien-Text anstelle von Dateien zu verwenden, können Sie stattdessen das -Modell und Richtlinie Felder verwenden:

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, Akt

            [policy_definition]
            p = sub, obj, act

            [role_definition]
            g = _, _

            [policy_effect]
            e = irgendwo (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)",

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

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

Aktiviere das Plugin mit einem globalen Modell/Richtlinie​

Es kann Situationen geben, in denen Sie ein einzelnes Modell und die Richtlinien-Konfiguration über mehrere Routen hinweg verwenden möchten. Sie können dies tun, indem Sie zuerst eine PUT Anfrage senden, um das Modell und die Richtlinien-Konfiguration zu den Metadaten des Plugins hinzuzufügen von:

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

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = irgendwo (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"
}'

Und um dann die gleiche Konfiguration auf einer Route zu aktivieren, senden Sie eine Anfrage mit der Admin API:

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

Dies wird die Plugin-Metadatenkonfiguration zur Route hinzufügen. Sie können die Metadatenkonfiguration des Plugins auch ganz einfach aktualisieren, indem Sie die Anfrage an die Metadaten des Plugins mit aktualisiertem Modell und Richtlinien-Konfiguration erneut schicken, das Plugin aktualisiert automatisch alle Routen mit dem Plugin Metadata.

Verwende Fälle​

  • Der primäre Anwendungsfall dieses Plugins wäre die Implementierung der Autorisierung in Ihren APIs. Sie können dieses Plugin ganz einfach auf jeder API-Route hinzufügen, die Sie mit Ihrem Autorisierungsmodell und Ihrer Richtlinien-Konfiguration verwenden.
  • Wenn Sie ein einziges Autorisierungsmodell für alle Ihre APIs haben möchten, können Sie globale Modelle/Richtlinien-Methode verwenden. Dies erleichtert die Aktualisierung der Richtlinie für alle Routen, da Sie nur die Metadaten in etcd aktualisieren müssen.
  • Wenn Sie für jede Route ein anderes Modell verwenden möchten, können Sie die Routenmethode verwenden. Dies ist hilfreich, wenn verschiedene API-Routen unterschiedliche Benutzerberechtigungen haben. Sie können dies auch verwenden, wenn Sie sich mit größeren Richtlinien befassen, da es die Autorisierung beschleunigen wird, wenn Sie in mehrere Routen gefiltert werden.

· 1 Min. gelesen
Casbin

Heute freuen wir uns, Ihnen mitteilen zu können, dass Casbin's Gründer Yang Luo erhält den "Google Open Source Peer Bonus Gewinner" für seine Arbeit an Casbin, NPcap und Nmap im Jahr 2019 Q3.

ospb

Der ursprüngliche Prämienbrief kann hier aufgerufen werden..

Das Open Source Peer Bonus Programm ist beschrieben als:

Genauso wie ein Google Peer Bonus verwendet wird, um einen Googler, der über- und darüber hinausgegangen ist, zu erkennen ein Open Source Peer Bonus erkennt externe Personen an, die einen außergewöhnlichen Beitrag zu Open Source geleistet haben.

Die Ankündigung für die 2019 Gewinner ist verfügbar unter:

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

Yang und Casbin sind unter Open-Source-Entwicklern und Projekten gelistet, die relevante Auswirkungen haben wie Git, TensorFlow, V8, CPython, LLVM, Apache-Projekte, Winkel- oder Jenkins.

Wir freuen uns, dass Casbin auf diese Weise für seinen Beitrag zu Open Source und Cloud-Sicherheit erkannt wird!

Vielen Dank für das Fliegen von Casbin!

· 1 Min. gelesen
Yang Luo

Heute haben wir die Casbin-Dokumentation von GitHub Wiki zu Docs dieser Website migriert, welches von Docusaurus betrieben wird. Docusaurus bietet viele großartige Funktionen, wie z.B. bessere Markdown Stile, Volltextsuche, Versionierung, Übersetzung.

Die Dokumentation ist noch nicht perfekt und muss noch abgestimmt werden. The source code is hosted on GitHub: https://github.com/casbin/casbin-website-v2 .

Jeder Beitrag oder Vorschlag ist willkommen!

· 1 Min. gelesen
Zixuan Liu

Heute haben wir Casbin erfolgreich nach Node.js portiert, der den Namen node-Casbin trägt.

node-Casbin teilt die ähnliche Nutzung und API mit anderen Implementierungen von Casbin. Die Middlewares für Express, Koa2 und Egg.js sind bereit für . Der Speicheradapter für Sequelize wird ebenfalls vorbereitet.

Hoffentlich kann es deinem Bedürfnis gut dienen :)

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

· 1 Min. gelesen
Helong Zhang

Einige unserer Kunden fragen, ob Casbin als Service anstelle einer Bibliothek genutzt werden kann. Die Antwort lautet JA. Heute haben wir das Casbin Server Projekt als konkrete Lösung für Access Control as a Service gestartet.

Casbin Server wird von unserem Kernteam aktiv weiterentwickelt. Es hat mehrere Eigenschaften:

  • Rein entwickelt in Golang.
  • Kann tausende Casbin-Instanzen verwalten, so dass Sie die Logik der Durchsetzung von Richtlinien von mehreren Diensten auf einen Casbin-Server umstellen können.
  • gRPC wird verwendet, um mit Casbin Server zu kommunizieren. Wir erwägen auch, in naher Zukunft den RESTful Support hinzuzufügen.
  • Ein benutzerfreundliches Web-Administratorportal für nicht-Entwickler Administratoren zur Verwaltung aller Details wie Casbin-Instanzen, Modelle, Richtlinienspeicherung und Lastausgleich.

Der Quellcode wird auf GitHub gehostet: https://github.com/casbin/casbin-server

Alle Tickets oder Pull-Requests sind willkommen :)