权限|CRM 05：基于RBAC理论的权限设计( 二 )

至于角色爆炸的问题，在CRM实施之初就提前规划好，并约定好原则，这个问题就可以大概率避免。当然不排除后人破掉了这个限制，导致套娃
RBAC的核心设计如下绿图：

文章插图
【图片来自于Apache Directory】
用户和角色还有会话相互关联（会话的作用可理解为每次访问都要检查用户和角色的关系，如果角色冲突，就中断会话）
角色单独和权限管理，是权限的集合。权限内部又包含了对象和操作。（如果不理解对象和操作，可查看之前的UML文章）
RBAC体系的逻辑可以大体这么理解：
RBAC0：RBAC96家族的核心部分，后面的123都是基于此发展
RBAC1：在0的基础上，增加角色分层和角色继承的关系。如区域经理下方有门店店长这种关系
RBAC2：在0基础上增加了角色约束，包含：

角色互斥约束，系统的运行中互斥角色只能生效一个，如Boss直聘里的牛人和BOSS，切换以后需要重新登录
角色基数约束，限制某个用户最多的角色数量/权限数量，防止滥用
先决条件角色约束，指某用户只有在已经拥有某个角色的前提下，才能分配到特定的其他角色，如想拥有线索放弃的权限，就必须拥有销售角色的权限

RBAC3：
融合了RBAC1和RBAC2的所有特点，把角色关系和角色约束都整合到了一块，在我们的业务环境中没必要这么复杂，所以就用了RBAC0。
基于RBAC0的这种机制，落地到业务中，整体的权限配置效果如下：

一个用户，可以批量关联多个角色。一个角色可以批量授权给多个用户
一个角色可以配置不同的页面权限与操作权限（操作在我们设计的时候也抽象成了页面，更简单）
数据权限与组织树权限的颗粒度精细到具体的用户，只可单独授权。同时数据的行权限和列权限不必单独授权，保留了能力

基于RBAC的权限设计就讲到这里，希望在大家设计系统的时候有所帮助，如果在设计过程中卡在了页面设计上，把上述的每个圆圈的内容分别设计个列表和详情页，就有思路了，如图。
角色管理：

文章插图
角色详情：

文章插图
用户管理：

文章插图
用户详情：

文章插图
本文核心理论部分来自于互联网，页面截图来自于过往脱敏经历。
参考资料
RBAC https://csrc.nist.gov/projects/role-based-access-control
PBAC VS RBAC https://blog.plainid.com/why-role-based-access-control-is-not-enough
PBAC VS ABAC https://blog.plainid.com/the-advantage-of-pbac-over-the-traditional-abac
RBAC核心设计 http://directory.apache.org/fortress/user-guide/1.3-what-rbac-is.html
感谢大家的阅读！CRM系统设计的相关内容到这里基本讲完了，后面我会继续出CRM外围系统的相关内容，欢迎大家追更~~
我这几篇文章经常提到UML，也是给大家实操了一遍，建议大家练习和使用。祝大家在产品的道路上找到自己喜欢的事情。
作者：罗文正雄；公众号：罗文正雄
本文由 @罗文正雄原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议