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

即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。
RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。

最小特权原则：某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
责任分离原则：是指完成敏感任务过程中需要分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
数据抽象：如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。

使用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