How It Works

En Casbin, un modèle de contrôle d'accès est résumé dans un fichier CONF basé sur le métamodel PERM (Politique, Effect, Demande, Matchers). Switching or upgrading the authorization mechanism for a project is as simple as modifying a configuration. Vous pouvez personnaliser votre propre modèle de contrôle d'accès en combinant les modèles disponibles. Par exemple, vous pouvez combiner les rôles RBAC et les attributs ABAC ensemble dans un modèle et partager un ensemble de règles de politique.

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

Demander

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

Par exemple, une définition de requête peut ressembler à ceci : r={sub,obj,act}

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

Politique de confidentialité

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

Par exemple : p={sub, obj, act} ou 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.

Correspondant

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. Le résultat de la stratégie sera sauvegardé dans p.eft.

Effet

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

Par exemple : e = quelque(où(p.eft == allow))

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

Le modèle le plus basique et le plus simple de Casbin est ACL. The model CONF for ACL is as follows:

# Définition de la requête
[request_definition]
r = sub, obj, act

# Définition de la politique
[policy_definition]
p = sub, obj, acte

# Effet de police
[policy_effect]
e = quelque part (où (p. ft == allow))

# correspondances
[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, read
p, bob, data2, write

This means:

• alice peut lire les données1
• bob peut écrire des données2

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):

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