官方文档
基础权限模型
下图为我基于个人理解画出来的(关于多租户RBAC模型可能有误)
发现一篇博客讲的还行Casbin权限模型,看他的权限系统设计模型分析部分
casbin配置文件内容的结构解释
注意matchers
可以设置多个。我在知道这个之前一直疑惑为什么需要policy_effect
policy.csv
只是一个数据文件,即持久化了的用户权限数据,也可以存在数据库
中
而model.conf
一般在设计项目权限模型时就定好了,一般就用conf文件
或者字符串形式
model.conf文档相关
- 至少包含
[request_definition], [policy_definition], [policy_effect], [matchers]
- 使用
#
进行注释 [policy_definition]
如果只有操作没有具体资源,比如write-all-objects
,可以只写p = sub, act
- [policy_effect]:自己去看官方文档吧,感觉怪怪的
模型方案的具体实现
- ACL(最基础的,后面模型的改变均基于此)
[request_definition] r = sub, obj, act[policy_definition] p = sub, obj, act[policy_effect] e = some(where (p.eft == allow))[matchers] m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
- 有超级用户的ACL:
matchers加个如果是超级用户就放行
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act || r.sub == "root"
- 没有用户、只有资源和操作的ACL
去掉所有的sub
r = obj, act p = obj, act m = r.obj == p.obj && r.act == p.act
- 基础RBAC
添加role_definition
,且只有两个下划线
matcher添加[role_definition] g = _, _
用户-角色
关联m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
- 具有资源角色的RBAC
相比基础RBAC
添加角色-资源
关联g = _, _ g2 = _, _m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act
- 带有域/租户的RBAC
三个下划线并添加关联g = _, _, _m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act
- ABAC
matchers
进行属性的过滤,且不需要policy
文件,因为权限是即时
得出的m = r.sub == r.obj.Owner
- Restful
matchers
进行正则
匹配m = r.sub == p.sub && keyMatch(r.obj, p.obj) && regexMatch(r.act, p.act)
- matcher全
allow
才true
e = !some(where (p.eft == deny))