权限模型中的 基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）这两种怎么结合一起使用

很典型的 各种在线文档的读写权限， 比如 文档的作者拥有刻度可写权限可复制权限， 同部门的人可读可写， 部门外的人可读， 某一个群里的人可读可写， 北京的人可读可写
怎么样的设计才是最佳的设计

设计一个结构,存储的内容是 [user 是否拥有资源 ID 的增,删,改,查]
基于角色或者基于属性或者基于业务,最终都转译为这个 map
对权限内场景正常展示或者执行,对无无权限场景,则需要根据资源类型设计一些 failback 来处理容错
例如抛出异常,禁止展示,逻辑分支,字符遮盖等都是对无权展示时候的容错处理

@leokun 所以写代码的时候,我是统一管理两个地方
一个是根据用户的角色属性等,实时计算出一个 [user 是否拥有资源 ID 的增,删,改,查]的 map
另一个是根据资源类型+访问类型不通过的 failbacks

系统权限存在总公司 分公司和多级部门和不同岗位的角色划分，就要用到 RBAC+ABAC(可能存在权限继承的关系)

rebac

插个眼，目前正在做这块只做了个 rabc ,部门的权限这个也没有想好杂弄。一批人都在一个部门，不代表他就能看部门的所有数据，有可能只有领导可以看。或者只开放了几个人看。上级的也不能看他下级的所有。

抄作业. 我是之前啊想要白嫖微软的 todo api 和语音生成 api 了解到微软那一套权限认证的, 感觉他们设计得还蛮合理的

做过云平台的一般都有类似的设计经验吧，比如阿里云控制台，总的来讲，大体上分为 3 种，功能权限，数据权限，字段权限。

比如说：
- 功能权限可定义开发角色可以启动虚拟机（ RBAC ）
- 数据权限可限制你能够看到那些地域的虚拟机（ ABAC ）
- 字段权限允许你能够访问的详细字段信息,如客户成本等 (FBAC)


从我个人经验来讲，有几点建议
1.数据权限一定要下沉到业务里面去做，而且不能设计的太过于灵活，否则后面一定会演化成性能的负担。
2.基于组织架构的数据权限控制是良好的设计。
3.数据权限应尽量通过数据库谓词下推（如 WHERE 子句）实现，避免内存中过滤。
4.优先使用静态可枚举规则，动态规则需配套缓存和索引优化。

给资源加 tag ，如["/部门/开发 2 部","/角色/部门领导","/用户/34234"]

角色是一堆属性的集合{'/usr/add', '/usr/delete', ...}, 不同角色和属性取下并集，RoleA U RoleB U {attr1, attr2, ...}, 每个请求调用前验证当前会话是否拥有该权限（属性）@Auth("attr1")

见过一个框架使用的方案就是两种混合使用：
角色优先，对每个角色分配权限，用户关联各种角色；但是某些特殊用户去自定义分配特殊的权限 + 已有的角色权限；

虽然我没有用过 https://casbin.org/zh/ 但是我从 casbin 对权限的设计上学习到了

```
[matchers]
m = g(r.sub, "admin") || (r.role == "user" && r.time.Hour >= 9 && r.time.Hour <= 18)
```

这块可以参照云平台的权限设计，PBAC ，基于某些策略+字段动态控制权限，我刚研究明白，正在给我们自己平台重构，跟以往 RBAC 权限完全不一样，这个东西更像是一个动态策略

参考一下 tailscale 的 acl 文档 https://tailscale.com/kb/1018/acls

RBAC 模型是比较简单的，其他模型都很复杂，不好实现还是其次，问题是真的难用。

其实说白了，权限就是功能权限+数据权限。RBAC 可以很好的解决功能权限的问题，但对于数据权限则无能为力。以我的经验，数据权限最终还是要落实到业务规则上，需要应用数据权限的业务，就要单独给设计一套数据权限的规则。这个规则以最低限度满足应用需求为限，千万不要过度设计。

因为数据权限和业务数据是强耦合的关系，所以理论上是不可能实现抽象的。通用数据权限就是个永动机，理论上就不可能实现。想做通用数据权限规则的话，还请早点歇了这个心思。

@xuanbg 参考 aws/阿里云的策略模型。就是个通用数据权限模型，abac+rbac 都是覆盖的…

@sampeng 正如低代码实现复杂业务，不是实现不了，而是极难实现且实现出来极难用。有这功夫，再写业务代码的时候写个相应的数据权限规则就简单得多，而且配置规则也能做到非常简单高效。