casbin权限和配置文件的理解

基础权限模型
下图为我基于个人理解画出来的(关于多租户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(最基础的,后面模型的改变均基于此)
1
2
3
4
5
6
7
8
9
10
11[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加个如果是超级用户就放行
1
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act || r.sub == "root"
- 没有用户、只有资源和操作的ACL
去掉所有的sub
1
2
3r = obj, act
p = obj, act
m = r.obj == p.obj && r.act == p.act - 基础RBAC
添加role_definition
,且只有两个下划线matcher添加1
2[role_definition]
g = _, _用户-角色
关联1
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
- 具有资源角色的RBAC
相比基础RBAC
添加角色-资源
关联1
2
3
4g = _, _
g2 = _, _
m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act - 带有域/租户的RBAC
三个下划线并添加关联1
2
3g = _, _, _
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act - ABAC
matchers
进行属性的过滤,且不需要policy
文件,因为权限是即时
得出的1
m = r.sub == r.obj.Owner
- Restful
matchers
进行正则
匹配1
m = r.sub == p.sub && keyMatch(r.obj, p.obj) && regexMatch(r.act, p.act)
- matcher全
allow
才true
1
e = !some(where (p.eft == deny))
- 标题: casbin权限和配置文件的理解
- 作者: urlyy
- 创建于 : 2023-01-23 13:00:24
- 更新于 : 2025-03-16 01:04:15
- 链接: https://urlyy.github.io/2023/01/23/casbin权限和配置文件的理解/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论