在之前的文章《CRM02-销售域系统设计与实现》中，对权限的划分进行了讲解。 本文讨论系统的权限设计机制，重点讨论RBAC机制。
1. 基本逻辑
首先，让我拆解访问的逻辑。 一个完整的访问由以下部分组成：
基于这个逻辑rbac角色权限表设计，可以通过不同的机制来控制访问过程。
2、准入机制
目前，市场上广泛流传的权限控制机制有以下三种：
瞬间扔掉3种访问控制机制，会让人无从下手。 我先从我的角度来介绍一下。 如有错误，欢迎有经验的专家指正。
首先，这三种机制没有好坏之分，只有适不适合。 每种机制的倡导者都会说他们自己的机制代表着未来。
1.阿巴克
访问是根据用户的特定属性进行控制的。 例如，基于年龄属性限制，18岁以下的用户无法访问某些页面。 这就是ABAC。
优点：集中管理，一刀切
缺点：如果权限要求灵活多变，配置就会混乱，无法看出用户是否可以访问特定对象。
2.RBAC
基于角色的权限控制增加了一层角色抽象，这也是设计CRM结构（引自第二篇文章）中介绍的方法。 通过不同的页面授权，将不同对象的权限组合成角色，实现灵活配置。
优点：可以直观地追溯用户和对象之间的关系，调整和配置非常灵活。
缺点：如果公司业务规模较大，分工模糊。 例如，一个人兼任簿记角色和监督角色。 这种分工是极其不合理的。 根据这种层次模型，理论上，对象越多，可以安排的权限组合就越多，角色也就越多。这种现象称为
人物爆炸。 基于角色爆炸，推出以下PBAC。
3.PBAC
如果一个大系统有很多关联的子系统，那么各个子系统的权限配置、级别、菜单都不同。
这种场景更适合PBAC，基于策略的角色控制。 该机制下的配置逻辑是“按照原则设计权限限制”。 这一原则构成了政策。 比如，只要某个部门的人不需要打卡，。 例如：“部门属性”=“运维组”时音效，访问页面包含“系统配置”。
优点：PBAC 支持上下文和上下文控制，因此可以设置策略以授予在特定时间和位置对资源的访问权限游戏素材，甚至可以评估身份和资源之间的关系。 可以在给定的时间段内快速调整和设置策略（例如响应违规或其他紧急情况）。 可以轻松添加、删除或修改用户组，并且只需单击一下即可撤销过时的权限。
缺点：配置操作难度大，不适合一般商业公司，对配置人员要求较高。
3.RBAC核心设计
在介绍了不同的机制之后，我将重点介绍 RBAC。
RBAC认为权限的过程可以抽象概括为：判断逻辑表达式[谁可以对What执行How访问操作(Operator)]的值是否为True的求解过程。
也就是说，将权限问题转化为“谁”、“什么”和“如何”的问题。 谁、什么以及如何构成访问权限三元组。
RBAC 支持公认的安全原则：最小特权原则、职责分离原则和数据抽象原则。
使用RBAC机制的好处是在业务环境中非常明确。 您可以通过角色快速识别角色包含的页面，并且多个角色可以叠加组合，减少配置工作量。
至于角色爆炸的问题rbac角色权限表设计，如果在CRM实施之初就未雨绸缪，约定好原则，这个问题大概率是可以避免的。当然，也不排除后人会打破这个限制，导致在俄罗斯套娃中
RBAC的核心设计如下：
[图片来自Apache目录]
用户、角色和会话是相互关联的（会话的角色可以理解为每次访问时检查用户和角色的关系，如果角色冲突则会话中断）
单独的角色和权限管理是权限的集合。 权限包括对象和操作。 （如果不懂对象和操作，可以查看之前的UML文章）
RBAC系统的逻辑可以大致理解如下：
RBAC0：RBAC96家族的核心部分，后续的123都是基于此开发
RBAC1：在0的基础上，增加角色分层和角色继承的关系。比如区域经理下面有门店经理这样的关系。
RBAC2：在0的基础上增加了角色约束，包括：
RBAC3：
它结合了RBAC1和RBAC2的所有特性，并集成了角色关系和角色约束。 我们的业务环境不需要那么复杂，所以使用RBAC0。
当这种基于RBAC0的机制在业务中实现时，整体的权限配置效果如下：
基于RBAC的权限设计到此结束。 希望对大家设计系统时有所帮助。 如果你在设计过程中卡在页面设计上，就为以上每个圈子设计一个列表和详情页面。 我有一个想法，如图所示。
角色管理：
角色详情：
用户管理：
用户详细信息：
本文核心理论来自网络，页面截图来自过往脱敏经历。
参考
RBAC
PBAC 与 RBAC
PBAC VS ABAC
RBAC核心设计
感谢大家的阅读！ 到这里CRM系统设计的相关内容就基本结束了。 后续我会继续发布CRM周边系统的相关内容。 欢迎大家关注~~
我在这些文章中经常提到 UML，并且还给您提供实际练习。 我建议您练习并使用它。 祝大家在产品研发的道路上找到自己喜欢的东西。
