支持的Models

1. ACL (Access Control List, 访问控制列表)
2. 具有 超级用户 的 ACL
3. 没有用户的 ACL: 对于没有身份验证或用户登录的系统尤其有用。
4. 没有资源的 ACL: 某些场景可能只针对资源的类型, 而不是单个资源, 诸如 write-article, read-log等权限。 它不控制对特定文章或日志的访问。
5. RBAC (基于角色的访问控制)
6. 支持资源角色的RBAC: 用户和资源可以同时具有角色 (或组)。
7. 支持域/租户的RBAC: 用户可以为不同的域/租户设置不同的角色集。
8. ABAC (基于属性的访问控制): 支持利用resource.Owner这种语法糖获取元素的属性。
9. RESTful: 支持路径, 如 /res/*, /res/: id 和 HTTP 方法, 如 GET, POST, PUT, DELETE。
10. 拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。
11. 优先级: 策略规则按照先后次序确定优先级，类似于防火墙规则。

Model语法

• Model CONF 至少应包含四个部分: [request_definition], [policy_definition], [policy_effect], [matchers]。
• 如果 model 使用 RBAC, 还需要添加[role_definition]部分。
• Model CONF 文件可以包含注释。注释以 # 开头， # 会注释该行剩余部分。

Request定义

[request_definition] 部分用于request的定义，它明确了 e.Enforce(...) 函数中参数的含义。

[request_definition]
r = sub, obj, act

sub, obj, act 表示经典三元组: 访问实体 (Subject)，访问资源 (Object) 和访问方法 (Action)。 但是, 你可以自定义你自己的请求表单, 如果不需要指定特定资源，则可以这样定义 sub、act ，或者如果有两个访问实体, 则为 sub、sub2、obj、act。

Policy定义

[policy_definition] 部分是对policy的定义，以下文的 model 配置为例:

[policy_definition]
p = sub, obj, act
p2 = sub, act

这些是我们对policy规则的具体描述

p, alice, data1, read
p2, bob, write-all-objects

policy部分的每一行称之为一个策略规则， 每条策略规则通常以形如p, p2的policy type开头。 如果存在多个policy定义，那么我们会根据前文提到的policy type与具体的某条定义匹配。 上面的policy的绑定关系将会在matcher中使用， 罗列如下：

(alice, data1, read) -> (p.sub, p.obj, p.act)
(bob, write-all-objects) -> (p2.sub, p2.act)

Policy effect定义

[policy_effect] 是策略效果的定义。 它确定如果多项政策规则与请求相符，是否应批准访问请求。 例如，一项规则允许，另一项规则则加以拒绝。

[policy_effect]
e = some(where (p.eft == allow))

上面的策略效果表示如果有任何匹配的策略规则 允许, 最终效果是 允许 (aka allow-override). p.eft 是策略的效果，它可以 允许 或 否定。 它是可选的，默认值是 允许。 因为我们没有在上面指定它，所以它使用默认值。

策略效果的另一个例子是：

[policy_effect]
e = !some(where (p.eft == deny))

这意味着如果没有匹配的政策规则为否定, 最终效果是 允许 (别名为拒绝). some 表示：如果存在一个匹配的策略规则。 any 意味着：所有匹配的政策规则(这里不使用)。 策略效果甚至可以与逻辑表达式相关联：

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

这意味着至少有一个匹配的策略规则允许，并且没有匹配的否定的 的策略规则。 因此，允许和拒绝授权都得到支持，拒绝则被推翻。

NOTE
尽管我们设计了政策效果的语法。 目前的执行只是使用硬编码的政策效果，因为我们认为这种灵活性没有多大必要。 所以现在您必须使用内置的政策效果之一，而不是自定义您自己的效果。

支持的内在政策效应是：

项目中的实践

基于RBAC的配置，admin角色为超级管理员

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && keyMatch2(r.obj, p.obj) && r.act == p.act || r.sub == "admin"