Zum Hauptinhalt springen

How It Works

In Casbin wird ein Zugriffskontrollmodell in eine CONF-Datei abstrahiert, basierend auf der PERM-Metamodel (Policy, Effect, Request, Matchers). Switching or upgrading the authorization mechanism for a project is as simple as modifying a configuration. Sie können Ihr eigenes Zugangskontrollmodell anpassen, indem Sie die verfügbaren Modelle kombinieren. Zum Beispiel können RBAC-Rollen und ABAC-Attribute in einem Modell kombiniert werden und eine Reihe von Richtlinien-Regeln gemeinsam genutzt werden.

The PERM model is composed of four foundations: Policy, Effect, Request, and Matchers. These foundations describe the relationship between resources and users.

Anfrage

Defines the request parameters. A basic request is a tuple object, requiring at least a subject (accessed entity), object (accessed resource), and action (access method).

Zum Beispiel kann eine Anfragedefinition so aussehen: r={sub,obj,act}

This definition specifies the parameter names and ordering required by the access control matching function.

Richtlinien

Defines the model for the access strategy. It specifies the name and order of the fields in the Policy rule document.

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

Note: If eft (policy result) is not defined, the result field in the policy file will not be read, and the matching policy result will be allowed by default.

Matcher

Defines the matching rules for Request and Policy.

For example: m = r.sub == p.sub && r.act == p.act && r.obj == p.obj This simple and common matching rule means that if the requested parameters (entities, resources, and methods) are equal to those found in the policy, then the policy result (p.eft) is returned. Das Ergebnis der Strategie wird in p.eft gespeichert.

Effekt

Performs a logical combination judgment on the matching results of Matchers.

Zum Beispiel: e = irgendwe(wo(p.eft == erlaubt))

This statement means that if the matching strategy result p.eft has the result of (some) allow, then the final result is true.

Let's look at another example:

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

The logical meaning of this example combination is: if there is a strategy that matches the result of allow and no strategy that matches the result of deny, the result is true. In other words, it is true when the matching strategies are all allow. If there is any deny, both are false (more simply, when allow and deny exist at the same time, deny takes precedence).

Das einfachste und einfachste Modell in Casbin ist ACL. The model CONF for ACL is as follows:

# Anforderungsdefinition
[request_definition]
r = sub, obj, act

# Richtlinien-Definition
[policy_definition]
p = sub, obj, act

# Policy-Effekt
[policy_effect]
e = some(where (p. ft == allow))

# Matcher
[matchers]
m = r. ub == p.sub && r.obj == p.obj && r.act == p.act

An example policy for the ACL model is:

p, alice, data1, lesen
p, bob, data2, schreiben

This means:

  • alice kann Daten 1 lesen
  • bob kann Daten 2 schreiben

We also support multi-line mode by appending '\' in the end:

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

Furthermore, if you are using ABAC, you can try the 'in' operator as shown in the following example for the Casbin golang edition (jCasbin and Node-Casbin are not supported yet):

# Matcher
[matchers]
m = r.obj == p.obj && r.act == p.act || r.obj in ('data2', 'data3')

But you SHOULD make sure that the length of the array is MORE than 1, otherwise it will cause a panic.

For more operators, you may take a look at govaluate.