rbac权限管理模型phpRBAC权限治理模子根本模子及脚色模子解析及举例

我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。
譬如，做企业类软件，不同部门、不同职位的人的权限是不同的；做论坛类产品的时候，版主和访客权限也是不一样的；再例如一款产品的收用度户和免用度户权限也是迥然不同的。

但在设计产品的用户和权限的关系的时候，很多产品经理可能按照觉得来，在并不清楚用户和权限是否存在精良的理论模型的时候，就按照自我推理搭建了产品的用户和权限模型。
而这种基于觉得和推理的模型肯定是有诸多问题的，譬如写去世了关系导致权限不足灵巧、考虑不周导致权限覆盖能力弱等等。

正如牛顿所言，站在巨人的肩膀上才能看的更远。
我们不妨去参照已有的比较成熟的权限模型，如：RBAC（Role-Based Access Control）——基于角色的访问掌握。
我搜集了网上很多关于RBAC的资料，大多与如何用数据表实现RBCA干系，并不随意马虎理解。
以是，我会以产品经理的角度去解析RBAC模型，并分别举例如何利用这套已得到验证的成熟模型。

rbac权限管理模型phpRBAC权限治理模子根本模子及脚色模子解析及举例 Python

一、RBAC模型是什么?

RBAC是一套成熟的权限模型。
在传统权限模型中，我们直接把权限授予用户。
而在RBAC中，增加了“角色”的观点，我们首先把权限授予角色，再把角色授予用户。
这样，由于增加了角色，授权会更加灵巧方便。
在RBAC中，根据权限的繁芜程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。
个中，RBAC0是根本，RBAC1、RBAC2、RBAC3都因此RBAC0为根本的升级。
我们可以根据自家产品权限的繁芜程度，选取适宜的权限模型。

二、基本模型RBAC0

解析：

RBAC0是根本，很多产品只需基于RBAC0就可以搭建权限模型了。
在这个模型中，我们把权限授予角色，再把角色授予用户。
用户和角色，角色和权限都是多对多的关系。
用户拥有的权限即是他所有的角色持有权限之和。

举例：

譬如我们做一款企业管理产品，如果按传统权限模型，给每一个用户授予权限则会非常麻烦，并且做不到批量修正用户权限。
这时候，可以抽象出几个角色，譬如发卖经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色授予用户。
这样无论是分配权限还是往后的修正权限，只须要修正用户和角色的关系，或角色和权限的关系即可，更加灵巧方便。
此外，如果一个用户有多个角色，譬如王师长西席既卖力发卖部也卖力市场部，那么可以给王师长西席授予两个角色，即发卖经理+市场经理，这样他就拥有这两个角色的所有权限。

三、角色分层模型RBAC1

解析：

RBAC1建立在RBAC0根本之上，在角色中引入了继续的观点。
大略理解便是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。

举例：

基于之前RBAC0的例子，我们又创造一个公司的发卖经理可能是分几个等级的，譬如除了发卖经理，还有发卖副经理，而发卖副经理只有发卖经理的部分权限。
这时候，我们就可以采取RBAC1的分级模型，把发卖经理这个角色分成多个等级，给发卖副经理授予较低的等级即可。

四、角色限定模型RBAC2

解析：

RBAC2同样建立在RBAC0根本之上，仅是对用户、角色和权限三者之间增加了一些限定。
这些限定可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
详细限定如下图：

举例：

还是基于之前RBAC0的例子，我们又创造有些角色之间是须要互斥的，譬如给一个用户分配了发卖经理的角色，就不能给他再授予财务经理的角色了，否则他即可以录入条约又能自己审核条约；再譬如，有些公司对角色的升级十分看重，一个发卖员要想升级到发卖经理，必须先升级到发卖主管，这时候就要采取先决条件限定了。

五、统一模型RBAC3

解析：