How It Works

In Casbin wird ein Zugriffskontrollmodell in eine CONF-Datei abstrahiert, basierend auf dem PERM-Metamodell (Policy, Effect, Request, Matchers). Das Wechseln oder Aktualisieren des Autorisierungsmechanismus für ein Projekt ist so einfach wie das Ändern einer Konfiguration. Sie können Ihr eigenes Zugriffskontrollmodell anpassen, indem Sie die verfügbaren Modelle kombinieren. Zum Beispiel können Sie RBAC-Rollen und ABAC-Attribute in einem Modell kombinieren und einen Satz von Richtlinienregeln teilen.

Das PERM-Modell besteht aus vier Grundlagen: Policy, Effect, Request und Matchers. Diese Grundlagen beschreiben die Beziehung zwischen Ressourcen und Benutzern.

Request

Definiert die Anforderungsparameter. Eine grundlegende Anforderung ist ein Tupel-Objekt, das mindestens ein Subjekt (zugreifende Entität), ein Objekt (zugreifende Ressource) und eine Aktion (Zugriffsmethode) erfordert.

Zum Beispiel könnte eine Anforderungsdefinition so aussehen: r={sub,obj,act}

Diese Definition gibt die erforderlichen Parameternamen und die Reihenfolge für die Zugriffskontroll-Matching-Funktion an.

Policy

Definiert das Modell für die Zugriffsstrategie. Es gibt den Namen und die Reihenfolge der Felder im Policy-Regeldokument an.

Zum Beispiel: p={sub, obj, act} oder p={sub, obj, act, eft}

Hinweis: Wenn eft (Policy-Ergebnis) nicht definiert ist, wird das Ergebnisfeld in der Policy-Datei nicht gelesen und das übereinstimmende Policy-Ergebnis wird standardmäßig zugelassen.

Matcher

Definiert die Übereinstimmungsregeln für Request und Policy.

Zum Beispiel: m = r.sub == p.sub && r.act == p.act && r.obj == p.obj Diese einfache und gängige Übereinstimmungsregel bedeutet, dass wenn die angeforderten Parameter (Entitäten, Ressourcen und Methoden) gleich denen in der Policy sind, dann wird das Policy-Ergebnis (p.eft) zurückgegeben. Das Ergebnis der Strategie wird in p.eft gespeichert.

Effect

Führt eine logische Kombinationsbeurteilung der Übereinstimmungsergebnisse von Matchers durch.

Zum Beispiel: e = some(where(p.eft == allow))

Diese Aussage bedeutet, dass wenn das Übereinstimmungsergebnis p.eft das Ergebnis von (einigen) erlauben hat, dann ist das endgültige Ergebnis wahr.

Schauen wir uns ein weiteres Beispiel an:

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

Die logische Bedeutung dieser Beispielkombination ist: Wenn es eine Strategie gibt, die das Ergebnis von erlauben übereinstimmt und keine Strategie, die das Ergebnis von verweigern übereinstimmt, ist das Ergebnis wahr. Mit anderen Worten, es ist wahr, wenn die übereinstimmenden Strategien alle erlauben. Wenn es irgendein Verweigern gibt, sind beide falsch (einfacher gesagt, wenn Erlauben und Verweigern gleichzeitig existieren, hat Verweigern Vorrang).

Das grundlegendste und einfachste Modell in Casbin ist ACL. Das Modell CONF für ACL ist wie folgt:

# 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

Ein Beispiel für eine Richtlinie für das ACL-Modell ist:

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

Das bedeutet:

• alice kann data1 lesen
• bob kann data2 schreiben

Wir unterstützen auch den Mehrzeilenmodus, indem wir am Ende ein '' anhängen:

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

Darüber hinaus, wenn Sie ABAC verwenden, können Sie den 'in' Operator ausprobieren, wie im folgenden Beispiel für die Casbin golang Edition gezeigt (jCasbin und Node-Casbin werden noch nicht unterstützt):

# 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.

Für weitere Operatoren können Sie einen Blick auf govaluate werfen.