casbin权限和配置文件的理解

urlyy

官方文档

基础权限模型

下图为我基于个人理解画出来的(关于多租户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
    3
    r = obj, act
    p = obj, act
    m = r.obj == p.obj && r.act == p.act
  • 基础RBAC
    添加role_definition,且只有两个下划线
    1
    2
    [role_definition]
    g = _, _
    matcher添加用户-角色关联
    1
    m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
  • 具有资源角色的RBAC
    相比基础RBAC添加角色-资源关联
    1
    2
    3
    4
    g = _, _
    g2 = _, _

    m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act
  • 带有域/租户的RBAC
    三个下划线并添加关联
    1
    2
    3
    g = _, _, _

    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全allowtrue
    1
    e = !some(where (p.eft == deny))
  • 标题: casbin权限和配置文件的理解
  • 作者: urlyy
  • 创建于 : 2023-01-23 13:00:24
  • 更新于 : 2023-06-19 13:34:26
  • 链接: https://urlyy.github.io/2023/01/23/casbin权限和配置文件的理解/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。