我们做任何产品的时候，或多或少都会涉及到用户和权限的问题。 比如做企业软件时，不同部门、不同岗位的人有不同的权限； 制作论坛产品时，版主和访客的权限也不同； 例如，某个产品的付费用户和免费用户的权限也是不同的。 非常不一样。
然而，很多产品经理在设计产品的用户和权限关系时，可能会根据自己的推理来构建产品的用户和权限模型，而不知道是否存在优秀的用户和权限理论模型。 这种基于感觉和推理的模型肯定存在很多问题，比如硬编码关系导致权限不灵活、考虑不周导致权限覆盖能力弱等。
正如牛顿所说，站在巨人的肩膀上才能看得更远。 我们不妨参考现有的比较成熟的权限模型，比如：RBAC（Role-Based Access Control）——基于角色的访问控制。 我在网上收集了很多关于RBAC的资料，大部分都是关于如何利用数据表实现RBCA，不太好理解。 因此，我将从产品经理的角度来分析RBAC模型，并举例说明如何使用这个经过验证的成熟模型。
1.什么是RBAC模型？
RBAC是一种成熟的权限模型。 在传统的权限模型中，我们直接向用户授予权限。 在RBAC中，增加了“角色”的概念。 我们首先为角色分配权限，然后为用户分配角色。 这样，由于角色的增加，授权会更加灵活方便。 在RBAC中，根据权限的复杂程度，可以分为RBAC0、RBAC1、RBAC2、RBAC3。 其中RBAC0是基础，RBAC1、RBAC2、RBAC3都是在RBAC0基础上的升级。 我们可以根据自己产品权限的复杂程度来选择合适的权限模型。
2. 基本模型RBAC0
分析：
RBAC0是基础创作人，很多产品仅基于RBAC0就可以构建权限模型。 在这个模型中，我们将权限分配给角色，然后将角色分配给用户。 用户和角色、角色和权限都是多对多的关系。 用户拥有的权限等于其所有角色拥有的权限之和。
例子：
比如我们做一个企业管理产品，如果按照传统的权限模型，给每个用户授予权限会非常麻烦，而且无法批量修改用户权限。 这时候你可以抽象出几个角色，比如销售经理、财务经理、营销经理等，然后给这些角色分配权限，然后把角色分配给用户。 这样，以后无论是分配权限，还是修改权限，都只需要修改用户与角色的关系，或者角色与权限的关系，就更加灵活方便了。 另外，如果一个用户有多个角色，比如王先生同时负责销售部门和市场部门，那么可以为王先生分配两个角色rbac角色权限表设计，即销售经理+市场经理，这样他就拥有了所有的角色。这两个角色的权限。 。
3.角色层次模型RBAC1
分析：
RBAC1是在RBAC0的基础上，在角色中引入了继承的概念。 简单的理解就是角色可以分为若干级别，每个级别都有不同的权限，从而实现更细粒度的权限管理。
例子：
根据前面RBAC0的例子rbac角色权限表设计，我们还发现一个公司的销售经理可能分为几个级别。 例如，除了销售经理之外，还有一名销售副经理，而销售副经理只拥有销售经理的部分权限。 这时，我们可以利用RBAC1分级模型，将销售经理的角色划分为多个级别，并将较低级别分配给销售副经理。
4.角色限制模型RBAC2
分析：
RBAC2也是基于RBAC0，但增加了一些对用户、角色和权限的限制。 这些限制可以分为两类，即静态职责分离（SSD）和动态职责分离（DSD）。 具体限制如下：
例子：
还是根据前面RBAC0的例子，我们还发现有些角色需要互斥。 例如，如果用户被分配了销售经理的角色，则不能为其分配财务经理的角色，否则他可以输入合同并能够自行审核合同； 又比如，有的公司非常重视角色晋升。 一个销售人员要想晋升为销售经理，首先必须晋升为销售主管。 这个时候就必须采取前提限制。
5.统一模型RBAC3
分析：
RBAC3是RBAC1和RBAC2的集合，因此RBAC3既有角色分层，又有添加各种限制的能力。
例子：
这不是一个例子。 统一模型RBAC3可以解决上述三个例子的所有问题。 当然，只有当系统有非常复杂的权限需求时才应该考虑这种权限模型。
6、基于RBAC的扩展——用户组
分析：
在RBAC模型的基础上，还可以进行适当的扩展，使其更适合我们的产品。 例如，添加用户组的概念，直接将角色分配给用户组，然后将用户添加到用户组中。 这样，用户除了拥有自己的权限外，还拥有其所属用户组的所有权限。
例子：
比如我们可以把一个部门看成一个用户组，比如销售部门、财务部门，然后直接给这个部门分配角色，让这个部门拥有部门权限2d游戏素材，这样这个部门的所有用户都拥有部门权限。 用户组概念可以更轻松地对组用户进行授权，而不会影响用户已拥有的角色权限。
7. 最后的话
无论是这个权限模型，还是其他产品相关的实现方案，很多都是前人总结提炼出来的。 我们应该深入掌握这些成熟的知识和经验，而不是自己绞尽脑汁去推理。 正如我在文章开头所说，站在巨人的肩膀上，我们才能看得更远，而不是重新发明轮子。
