- 文档：https://casbin.org/zh/docs
- 编辑器：https://casbin.org/zh/editor
- 支持模型列表：https://casbin.org/zh/docs/supported-models
Casbin是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。
它有两个配置文件，model.conf 和 policy.csv。其中 model.conf 存储的是我们的访问控制模型，policy.csv 存储的是我们具体的用户权限配置。
注意model.conf 一旦修改，对应的 policy 就需要进行同步修改，所以 model 在一个系统中不要进行频繁修改。
PML(PERM modeling language)。其中的 PERM 指的是 Policy-Effect-Request-Matcher
Request 请求
它的写法是
request ::= r : attributes attributes ::= {attr1, attr2, attr3, ..}
比如我们写一行：
r = sub, obj, act
代表一个请求有三个标准的元素，请求主体，请求对象，请求操作。其中的sub, obj, act 可以是自己定义的，只要你在一个配置文件中定义的元素标识符一致就行。
Policy - 规则（策略），它表示具体的权限定义的规则是什么。
它同样是形如 p = sub, obj, act 的表示方法，比如我们定义了 policy 的规则如此，那么我们在 policy.csv 中每一行定义的 policy_rule 就必须和这个属性一一对应。
Policy_Rule
在 policy.csv 文件中定义的策略就是 policy_rule。它和 Policy 是一一对应的。
比如 policy 为
p = sub , obj , act
设置的一条 policy_rule 为
p , bob , data2 , write
表示 bob（p.sub = bob）可以对 data2 (p.obj = data2) 进行 write (p.act = write) 操作这个规则。
policy 默认的最后一个属性为决策结果，字段名 eft，默认值为 allow，即通过情况下，p.eft 就设置为 allow。
Matcher - 判断
有请求，有规则，那么请求是否匹配某个规则，则是 matcher 进行判断的。
matcher ::= (variables, constants, stub functions) variables ::= {r.attr1, r.attr2, .., p.attr1, p.attr2, ..} constants ::= {const1, const2, const3, ..}
比如下面这个 matcher :
m = r . sub == p . sub && r . obj == p . obj && r . act == p . act
表示当（r.sub == p.sub && r.obj == p.obj && r.act == p.act ）的时候，返回 true，否则返回 false。
Effect
Effect 用来判断如果一个请求满足了规则，是否需要同意请求。它的规则比较复杂一些。
例子：
e = some ( where ( p . eft == allow ))
这句话的意思就是将 request 和所有 policy 比对完之后，所有 policy 的策略结果（p.eft）为 allow 的个数 >=1，整个请求的策略就是为 true。
自定义函数
自定义函数是在 matcher 中使用的。我们可以自己定义一个函数，然后注册进 enforcer，在 matcher 中我们就可以使用了。
1、我们先定义属性，通用的一些属性如 subject, object, action。
2、定义的属性可以作为 Request 的属性，也可以作为 Policy 的属性。
3、Policy_Rule 是 Policy 的具体规则。
4、使用定义的 Matcher 将 Request 和 Policy 进行匹配，这个匹配的过程可能使用到自定义函数。
5、所有的 Policy 匹配完成的结果，通过 Effect 规则得出最终是否可以访问的结果。
Casbin 支持的权限模型有
ACL (Access Control List, 访问控制列表)
具有超级用户的ACL
没有用户的 ACL: 对于没有身份验证或用户登录的系统尤其有用。
没有资源的 ACL: 某些场景可能只针对资源的类型, 而不是单个资源, 诸如 write-article, read-log等权限。它不控制对特定文章或日志的访问。
RBAC (基于角色的访问控制)
支持资源角色的RBAC: 用户和资源可以同时具有角色 (或组)。
支持域/租户的RBAC: 用户可以为不同的域/租户设置不同的角色集。
ABAC (基于属性的访问控制): 支持利用resource.Owner这种语法糖获取元素的属性。
RESTful: 支持路径, 如 /res/*, /res/: id 和 HTTP 方法, 如 GET, POST, PUT, DELETE。
拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。
优先级: 策略规则按照先后次序确定优先级，类似于防火墙规则。
访问控制模型
UGO(User, Group, Other)
这个是Linux中对于资源进行权限管理的访问模型。Linux中一切资源都是文件，每个文件都可以设置三种角色的访问权限（文件创建者，文件创建者所在组，其他人）。
缺点：只能为一类用户设置权限，如果这类用户中有特殊的人，那么它无能为力了。
ACL(访问控制列表)
它的原理是，每个资源都配置有一个列表，这个列表记录哪些用户可以对这项资源进行CRUD操作。当系统试图访问这项资源的时候，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定这个用户是否有权限访问当前资源。
RBAC(基于角色的权限访问控制)
这个是很多业务系统最通用的权限访问控制系统。它的特点是在用户和具体权限之间增加了一个角色。就是先设置一个角色，比如管理员，然后将用户关联某个角色中，再将角色设置某个权限。用户和角色是多对多关系，角色和权限是多对多关系。所以一个用户是否有某个权限，根据用户属于哪些角色，再根据角色是否拥有某个权限来判断这个用户是否有某个权限。
RBAC的逻辑有更多的变种。
变种一：角色引入继承
角色引入了继承概念，那么继承的角色有了上下级或者等级关系。
变种二：角色引入了约束
角色引入了约束概念。约束概念有两种，
一种是静态职责分离：
a、互斥角色：同一个用户在两个互斥角色中只能选择一个
b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的
c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色
一种是动态职责分离：可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
变种三：既有角色约束，又有角色继承
就是前面两种角色变种的集合。
ABAC(基于属性的权限验证)
Attribute-based access control，这种权限验证模式是用属性来标记资源权限的。比如k8s中就用到这个权限验证方法。
这个权限验证模型的好处就是扩展性好，一旦要增加某种权限，就可以直接增加某种属性。
DAC（自主访问控制）
在ACL的访问控制模式下，有个问题，能给资源增加访问控制的是谁，这里就有几种办法，比如增加一个super user，这个超级管理员来做统一的操作。还有一种办法，有某个权限的用户来负责给其他用户分配权限。这个就叫做自主访问控制。
MAC(强制访问控制)
强制访问控制和DAC相反，它不将某些权限下放给用户，而是在更高维度（比如操作系统）上将所有的用户设置某些策略，这些策略是需要所有用户强制执行的。这种访问控制也是基于某些安全因素考虑。
评论区