작동 원리

Casbin의 접근 제어 모델은 PERM 메타 모델 (Policy, Effect, Request, Matchers) 형식으로 추상화되어 CONF 파일에 저장됩니다. 따라서 프로젝트의 권한 부여 메커니즘을 전환하거나 확장하기 위해서는 단지 Conf 설정 파일을 변경하는 것으로 가능합니다. 가용한 모델을 결합하여 여러분의 필요에 맞는 접근 제어 모델을 구성할 수 있습니다. 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, Matchers) describing the relationship between resources and users.

Request

Define 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}

It actually defines the parameter name and order which we should provide for access control matching function.

Policy

Define the model of the access strategy. In fact, it defines 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, then the result field in the policy file will not be read, and the matching policy result will be allowed by default.

Matcher

Matching rules of 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, that is, if they can be found in the policy, then the policy result (p.eft) is returned. The result of the strategy will be saved in p.eft.

Effect

It can be understood as a model in which a logical combination judgment is performed again on the matching results of Matchers.

For example: e = some(where(p.eft == allow))

This sentence 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. ACL's model CONF is:

# 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

다음은 ACL 모델의 정책(Policy) 예제입니다.

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

이것은 다음을 의미합니다.

alice는 data1에 대해 read 할 수 있음
bob은 data2에 대해 write 할 수 있음

각 줄의 끝에 '\'를 붙여서 여러 줄로 작성할 수 있습니다.

# 조건식
[matchers]
m = r.sub == p.sub && r.obj == p.obj \ 
  && r.act == p.act

Furthermore, if you are using ABAC, you can try operator in like the following in 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 there will cause it to panic.

더 많은 연산자에 대해서 알아보려면 govaluate를 참조하세요.

Request​

Policy​

Matcher​

Effect​

Request

Policy

Matcher

Effect