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(最基础的，后面模型的改变均基于此)

  [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，且只有两个下划线

  [role_definition]
  g = _, _
  

  matcher添加用户-角色关联

  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))