1 要满足的策略

[request_definition]

    r = sub, obj, act

# 请求的规则

# r 是规则的名称，sub 为请求的实体，obj 为资源的名称, act 为请求的实际操作动作

[policy_definition]

    p = sub, obj, act

# 策略的规则

# 同请求

[role_definition]

    g = _, _

# 角色的定义

# g 角色的名称，第一个位置为用户，第二个位置为角色，第三个位置为域（在多租户场景下使用）

[policy_effect]

    e = some(where (p.eft == allow))

# 任意一条 policy rule 满足, 则最终结果为 allow

[matchers]

    m = g(r.sub, p.sub) == true \

            && keyMatch2(r.obj, p.obj) == true \

            && regexMatch(r.act, p.act) == true \

            || r.sub == "root"

# 前三个用来匹配上面定义的请求的规则， 最后一个或条件为：如果实体是root 直接通过， 不验证权限

m =g(r.sub,p.sub) &&r.obj ==p.obj &&r.act ==p.act

r： 表示请求的规则。sub请求实体，obj资源路径，act请求的方法。

p： 表示协议的协议的规则，一般会放在数据库表中，r请求会和p进行比较，来判断是否有权限进行访问。

g：表示角色定义，也就是说简单点就是将用户A定义为角色B。（一共两个参数）

m：表示匹配的规则。这里就是进行整个匹配的核心，直接得出结论是否有权限进行相关的API权限。

m = r.sub == p.sub && keyMatch(r.obj, p.obj) && regexMatch(r.act, p.act)

得到结论：通过request r 和策略 p 通过匹配规则m 得到e e是bool型

2 角色对应策略规则

      1)列出资源及资源的操作动作   需要后台界面去勾选

如：Q_01_0,user,add   

        Q_01_1,user,list    

        Q_01_2,user,edit    

         Q_01_3,user,delete

        2)角色去关联资源操作标识Q

         super,Q_01_0

         super,Q_01_2

         super,Q_01_3

         Anchor,Q_01_1

        3)数据库存用户对应发的角色 角色几位

        小角色 不能操作大角色