Understanding How Casbin Matching Works in Detail

In diesem Beitrag werde ich das Design und die Implementierung von RBAC mit Hilfe der Casbin Bibliothek erklären. Für eine SaaS-Plattform, die mit mehreren Ressourcen-Hierarchien und Rollen umgeht, die Berechtigungen von höheren Ebenen erben, bietet Casbin eine leistungsfähige Alternative zum Nachdenken.

Einführung in RBAC

RBAC ist eine Methode zur Einschränkung des Zugriffs auf Ressourcen basierend auf den Rollen, die Einzelpersonen innehaben. Um besser zu verstehen, wie hierarchisches RBAC funktioniert, werfen wir einen Blick auf das RBAC-System von Azure im nächsten Abschnitt und versuchen dann, ein ähnliches System zu implementieren.

Verständnis von Azures hierarchischem RBAC

Es gibt eine Rolle namens Owner für alle Ressourcen in Azure. Angenommen, mir wurde die Rolle Owner auf Abonnementebene zugewiesen, das bedeutet, ich bin der Owner aller Ressourcengruppen und Ressourcen unter diesem Abonnement. Wenn ich Owner auf der Ressourcengruppenebene bin, dann bin ich der Owner aller Ressourcen unter dieser Ressourcengruppe.

Dieses Bild zeigt, dass ich auf Abonnementebene Owner-Zugriff habe.

Wenn ich die IAM einer Ressourcengruppe unter diesem Abonnement überprüfe, können Sie sehen, dass ich den Owner-Zugriff vom Abonnement geerbt habe.

So ist Azures RBAC hierarchisch. Die meisten Unternehmenssoftware verwendet hierarchisches RBAC aufgrund der hierarchischen Natur der Ressourcenebenen. In diesem Tutorial werden wir versuchen, ein ähnliches System mit Casbin zu implementieren.

Wie funktioniert Casbin?

Bevor wir in die Implementierung eintauchen, ist es wichtig zu verstehen, was Casbin ist und wie es auf hoher Ebene funktioniert. Dieses Verständnis ist notwendig, weil jedes rollenbasierte Zugriffskontrollsystem (RBAC) je nach spezifischen Anforderungen variieren kann. Indem wir die Funktionsweise von Casbin verstehen, können wir das Modell effektiv feinabstimmen.

Was ist ACL?

ACL steht für Access Control List. Es handelt sich um eine Methode, bei der Benutzer Aktionen zugeordnet werden und Aktionen Ressourcen.

Die Modelldefinition

Betrachten wir ein einfaches Beispiel für ein ACL-Modell.

[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. Die request_definition ist die Abfragevorlage des Systems. Zum Beispiel kann eine Anfrage alice, write, data1 als "Kann das Subjekt Alice die Aktion 'write' auf das Objekt 'data1' ausführen?" interpretiert werden.

2. Die policy_definition ist die Zuweisungsvorlage des Systems. Zum Beispiel, indem Sie eine Richtlinie alice, write, data1 erstellen, weisen Sie dem Subjekt Alice die Berechtigung zu, die Aktion 'write' auf dem Objekt 'data1' auszuführen.

3. Der policy_effect definiert die Wirkung der Richtlinie.

4. Im Abschnitt matchers wird die Anfrage mit der Richtlinie unter Verwendung der Bedingungen r.sub == p.sub && r.obj == p.obj && r.act == p.act abgeglichen.

Jetzt testen wir das Modell im Casbin-Editor

Öffnen Sie den Editor und fügen Sie das obige Modell in den Modell-Editor ein.

Fügen Sie das Folgende in den Policy-Editor ein:

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

und das Folgende in den Request-Editor:

alice, read, data1

Das Ergebnis wird sein:

true

Visuelle Darstellung des ACL-Modells, der Richtlinie und der Anforderungsabgleichung

Was ist RBAC?

RBAC steht für Role-Based Access Control. In RBAC wird einem Benutzer eine Rolle für eine Ressource zugewiesen, und eine Rolle kann beliebige Aktionen enthalten. Die Anfrage prüft dann, ob der Benutzer die Berechtigung hat, die Aktion auf der Ressource auszuführen.

Die Modelldefinition

Betrachten wir ein einfaches Beispiel für ein RBAC-Modell:

[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. Die role_definition ist ein Graph-Relations-Builder, der einen Graphen verwendet, um das Anfrageobjekt mit dem Richtlinienobjekt zu vergleichen.

Jetzt testen wir das Modell im Casbin-Editor

Öffnen Sie den Editor und fügen Sie das obige Modell in den Modell-Editor ein.

Fügen Sie das Folgende in den Policy-Editor ein:

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

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

und das Folgende in den Request-Editor:

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

Das Ergebnis wird sein:

true
false
true
true
false

Visuelle Darstellung des RBAC-Modells, der Richtlinie und der Anforderungsabgleichung

Die Tabelle g - Role to action mapping hat eine Graph-Mapping der Rolle zur Aktion. Dieser Graph kann als Liste von Kanten kodiert werden, wie in der Richtlinie gezeigt, was eine übliche Darstellungsweise für einen Graphen ist:

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

info

p zeigt eine normale Richtlinie an, die mit dem Operator == verglichen werden kann. g ist eine auf Graphen basierende Vergleichsfunktion. Sie können mehrere Graph-Vergleicher definieren, indem Sie einen numerischen Suffix wie g, g2, g3, ... und so weiter hinzufügen.

Was ist hierarchisches RBAC?

Im hierarchischen RBAC gibt es mehr als einen Typ von Ressourcen und es besteht eine Vererbungsbeziehung zwischen den Ressourcentypen. Zum Beispiel ist "subscription" ein Typ und "resourceGroup" ist ein anderer Typ. Ein sub1 vom Typ Subscription kann mehrere resourceGroups (rg1, rg2) vom Typ ResourceGroup enthalten.

Ähnlich wie bei der Ressourcenhierarchie gibt es zwei Arten von Rollen und Aktionen: Subscription-Rollen und -Aktionen und ResourceGroup-Rollen und -Aktionen. Es besteht eine beliebige Beziehung zwischen der Subscription-Rolle und der ResourceGroup-Rolle. Betrachten Sie zum Beispiel eine Subscription-Rolle sub-owner. Diese Rolle wird von einer ResourceGroup-Rolle rg-owner geerbt, was bedeutet, dass, wenn mir die Rolle sub-owner auf Subscription sub1 zugewiesen wird, ich automatisch auch die Rolle rg-owner auf rg1 und rg2 erhalte.

Die Modelldefinition

Nehmen wir ein einfaches Beispiel für das Hierarchical RBAC Modell:

[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. Die role_definition ist ein Graph-Relation-Builder, der einen Graphen verwendet, um das Anfrageobjekt mit dem Policy-Objekt zu vergleichen.

Jetzt testen wir das Modell im Casbin-Editor

Öffnen Sie den Editor und fügen Sie das obige Modell in den Modelleditor ein.

Fügen Sie das Folgende in den Policy-Editor ein:

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

Und fügen Sie das Folgende in den Request-Editor ein:

alice, rg-read, rg1

Das Ergebnis wird sein:

true

Visuelle Darstellung des RBAC-Modells, der Richtlinie und der Anforderungsübereinstimmung

Die Tabelle g - Rolle zu (Aktion, Rolle) Zuordnung hat eine grafische Zuordnung der Rolle zur Aktion, Rollenzuordnung. Dieser Graph kann als Liste von Kanten kodiert werden, wie in der Richtlinie gezeigt, was eine übliche Art der Darstellung eines Graphen ist:

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

Die Tabelle g2 - Sub to RG Mapping hat eine grafische Zuordnung von Subscription zu ResourceGroup:

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

Visuelle Darstellung der Subject Matching

Visuelle Darstellung der Action Matching

Visuelle Darstellung der Object Matching

info

Wenn eine Anfrage an Casbin gesendet wird, findet diese Übereinstimmung für alle Richtlinien statt. Wenn mindestens eine Richtlinie übereinstimmt, dann ist das Ergebnis der Anfrage wahr. Wenn keine Richtlinie mit der Anfrage übereinstimmt, dann ist das Ergebnis falsch.

Fazit

In diesem Tutorial haben wir gelernt, wie verschiedene Autorisierungsmodelle funktionieren und wie sie mit Casbin modelliert werden können. Im zweiten Teil dieses Tutorials werden wir dies in einer Demo-Spring-Boot-Anwendung implementieren und die APIs mit Casbin absichern.