How It Works

Casbin의 접근 제어 모델은 PERM 메타 모델 (Policy, Effect, Request, Matchers) 형식으로 추상화되어 CONF 파일에 저장됩니다. Switching or upgrading the authorization mechanism for a project is as simple as modifying a configuration. 가용한 모델을 결합하여 여러분의 필요에 맞는 접근 제어 모델을 구성할 수 있습니다. For example, you can combine RBAC roles and ABAC attributes together inside one model and share one set of policy rules.

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

Request

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

For instance, a request definition may look like this: r={sub,obj,act}

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

Policy

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

For instance: p={sub, obj, act} or 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. The result of the strategy will be saved in p.eft.

Effect

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

For example: e = some(where(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).

The most basic and simplest model in Casbin is ACL. The model CONF for ACL is as follows:

# Request 정의
[request_definition]
r = sub, obj, act

# Policy 정의
[policy_definition]
p = sub, obj, act

# Policy effect (허용/거부)
[policy_effect]
e = some(where (p.eft == allow))

# 조건식
[matchers]
m = r.sub == 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는 data1에 대해 read 할 수 있음
• bob은 data2에 대해 write 할 수 있음

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

# 조건식
[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.