权限系统是应用开发中极为复杂的一个部分，如何能够让权限系统在符合我们业务场景的需要下，满足我们自定义配置权限的需要，同时又在复杂场景下能够灵活的和业务系统对接上？本期 Robust 就来聊一聊权限系统。
网易云音乐：点击播放
喜马拉雅：点击播放
求打赏🙇如果你觉得 Robust 这样一档技术类的谈话节目还不错，希望我继续做下去，不妨打赏支持。你可以扫描本文下方的二维码打赏，也可以加我微信后红包打赏。
纠错
- 音频中提到英文单词 Enterprise 中文解释应为“企业”
内容大纲
一、通用权限系统设计
- 什么是权限系统？
- 权限系统不做什么事？
- Morningstar EAMS
- 权限系统三大要素：
- 账号、角色、权限
- 用户（user）、系统/应用（system/application）、策略（policy）
- 权限系统存在形式：
- 嵌入在业务系统中
- 权限系统的管理界面单独存在，权限被用在业务系统中
- 权限系统分为两个部分，一个部分管理用户和角色，独立存在，另一部分管理角色和权限的联系，在多个业务系统中
- 常见权限管理模型：DAC, MAC, RBAC, ABAC
- RBAC（Role-Based Access Control）模型
- RBAC0: 账号-<多对多>-角色-<多对多>-权限
- RBAC1: RBAC0+角色分级（继承）
- RBAC2: RBAC0+角色限制（角色互斥、基数限制、先决条件限制、运行限制...）
- RBAC3: RBAC1+RBAC2
- T-RBAC
- ABAC（Attribute-Based Access Control）模型
- 当前用户是否拥有某个操作的权限，依赖四种属性的计算结果：用户属性（who）、环境属性（when）、操作属性（how）、对象属性（what）
- Kubernetes便因为ABAC太难用，在1.8版本里引入了RBAC的方案
- 也被称为 PBAC（Policy-Based Access Control）
- 权限分类：功能权限（是否能进入某个功能模块，前端是否展示）、业务权限（是否能进行某个具体的提交操作）
二、具体问题处理
- 不同端权限不同
- 同一公司旗下不同产品中权限不同
- 字段级权限
- 单一记录权限
- 动态角色：这个订单产生之后，订单的运营、配送、消费者才产生，在这个订单中，这些角色的权限生效，否则无效。
- 动态权限：我是这个订单的配送，在订单不同阶段，我在某个功能上权限不同。
- 5+6：在权限系统中，我的角色拥有该权限，但是实际使用中，我并不拥有该权限。
- 上级自动拥有下级部分权限
- 用户只能看自己所在部门的数据（数据范围限定）
- 权限期限（试用期、过期）
- 许可证（用来卖的）
- 到底是用户组、还是权限组？
- 超级管理员应该具备什么权限？
- 权限分层：拥有A权限才有资格去判断B权限，否则根本不需要判定B权限
- 组合权限：拥有A权限同时不拥有B权限，相当于拥有C权限，同时拥有AB权限相当于拥有D权限
- 某个上级领导，要求他自己登陆系统去配置自己下属的权限
- 独立的权限管理系统，权限和业务的联系在具体业务系统中实现
- 权限命名怎么才能更合理？
- API Gateway
2020-06-21 3620 权限
在知乎关注了博主, 然后发现了这个博客, 很多内容都是现阶段我想看到的, 很棒!
这期音频从通用设计讲到一些比较具体的点, 让我对权限管理管理有了一点点进一步的认识, 我觉得印象比较深的点有:
1. 权限系统不做和业务逻辑相关的任何事情
2. RBAC + ABAC 合理搭配使用. (感觉rbac像编译时, abac像运行时
我是一个前端, 如果让我单单想前端这一部分的话:
1. 某个页面用户是否可见
2. 某个页面里的某些元素用户是否可见
3. 一些表单字段, 是否需要根据权限, 让前端做一些表单校验的限制
其中1,2应该都是好办的, 直接判断显示不显示就好了, 3应该看产品需求, 因为表单形式多样, 需要前端做校验的话必须先调用接口先获取一些校验规则, 太麻烦. 不知道3这种情况的需求博主碰到的多吗? 感觉就是音频里说到的字段级权限, 前后端处理这种情况都比较麻烦
另外就是, 没有实际的抽象良好的项目例子来参考的话, 单单听这些听完以后我的感觉还是比较泛. 当然不是说博主说得不好, 是说得很好, 也符合talk这个主题, 而且有实际项目参考也不现实, 只是写代码的话没有show me the code总感觉不完整哈哈哈哈哈
播客没法show the code，至于业务案例，因为公司内项目不便公开讨论