RBAC 权限管理模型

1|0一、RBAC模型——基于角色的访问控制

什么是RBAC

RBAC（Role-Based Access Control）基于角色的访问控制。这是从传统的权限模型的基础之上，改进而来并且相当成熟的权限模型。

为什么要引入RBAC模型

在传统的权限模型之中，没有角色的概念。我们直接把权限赋给了用户，这就会导致在配置权限的时候会相当的麻烦，并且无法快速为多个用户批量删除权限。

而在RBAC中，我们增加了“角色”的概念，首先我们需要将权限赋予角色，再将角色赋予用户。这样，由于增加了角色，授权会更加的灵活方便。用户——角色——权限这样多对多的关系，轻松地解决了上述传统模型的问题。

关键的元素：

用户：成功认证并登录系统的操作员。（主体who，系统的账号、钥匙）
角色：权限的集合，也是用户和权限之间的桥梁。
权限：访问资源的许可，含有页面权限、操作权限和数据权限。（how）
- 页面权限即模块权限，对于后台管理系统最左端的菜单栏。代表着用户可操作的模块有哪些。
- 操作权限即对资源的增删改查的权限，代表着用户是否可以操作（增删改查）该资源。
- 数据权限即数据隔离，A和B两个用户都拥有相同的权限，但是A不能查询B的隐私，B也不能查询A的隐私。即对数据进行了隔离。
资源：引入这第四个概念，包括系统菜单、页面、按钮等（what）

主体（who）如何通过权限（how）访问资源（what resource）

权限是用来访问资源的，为用户赋予权限，则可以访问资源；

在权限基础上，将权限打包为一个权限集合——角色。如：财务经理角色、则为用户赋上财务经理的角色，用户可以访问财务经理角色下的资源集合。

RBAC的分类

根据权限的复杂程度，我们将RBAC又分四种：RBAC0、RBAC1、RBAC2、RBAC3。

其中RBAC0最为基础，也最为常用。RBAC1、2、3都是以RBAC0为基础的升级版，根据产品的复杂程度，选取适合的模型。

1|11. 基本模型RBAC0

将一个或多个权限挂到角色之下，再将一个或多个角色赋予用户，权限与角色的关系、角色于用户的关系，均属于多对多的关系。

这样，用户所拥有的权限 = 他所有的角色持有权限之和。

场景

为财务经理岗位建立财务经理角色，将对账、付款审批、汇款确认等权限配置在财务经理角色之下，则公司在更换财务经理人员，只需要每次为新来的财务配置财务经理角色即可。

为客户经理建立客户经理角色，客户管理、客户查询、抢单等权限配置在客户经理角色下，适用于公司流动性高且占比庞大（多的甚至上千人）的客户经理群体，若某个权限不适宜配置给客户经理，直接在角色中删除即可，无需分别对每个人进行权限删除。

此外，如果一个用户有多个角色，譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。

1|22. 角色分层模型RBAC1

RBAC1建立在RBAC0的基础之上，在角色中引入了继承的概念。

一个角色可以从另一个角色继承许可权。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承，受限继承关系则进一步要求角色继承关系是一个树结构。

简单理解就是，给角色分为好几个等级，每个等级权限不同，从而实现更细粒度的权限管理。

场景：
适用于角色之间的层次明确，如总经理和副总经理，业务部门如：总经理--团队经理--业务员。也是用于分级管理，初级用户只能使用部分功能，中级用户能够使用更多功能。

一个公司的销售经理可能是分几个等级的，譬如：除了销售经理，还有销售副经理，而销售副经理只有销售总经理的部分权限。

这时候，我们就可以采用RBAC1的分级模型，把销售经理这个角色分成多个等级，给销售副经理赋予较低的等级即可。

1|33. 角色限制模型RBAC2

RBAC2同样建立在RBAC0的基础之上，仅是对用户、角色和权限三者之间增加了一些限制。

加入了角色的访问控制。规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：

静态职责分离SSD：

互斥角色限制：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。案例：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
基数限制：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；一个角色的权限数目受限。案例：如VP类角色不可随意分配给多个用户。
先决条件限制：指要想获得较高的权限，要首先拥有低一级的权限。案例：先有副总经理权限，才能有总经理权限。

动态职责分离DSD：

运行时互斥：例如，允许一个用户具有两个角色，但不可同时激活这两个角色。

场景
有些角色之间是需要互斥，譬如给一个用户分配了销售经理的角色，就不能在给他赋予财务经理的角色了，否则他即可以录入合同，又能自己审核合同。

有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。

1|44. 统一模型RBAC3

RBAC3是RBAC1和RBAC2的合集，所以RBAC3即拥有角色分层，也包括可以增加各种限制。

RBAC3 = RBAC1 + RBAC2

1|55. 基于RBAC的延展——用户组

基于RBAC模型，还可以适当延展，使其更适合我们的产品。

譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。

这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。

此时：一个用户的权限 = 该用户所拥有角色的权限 + 该用户所属的用户组所拥有角色的权限

譬如，我们可以把一个部门看成一个用户组，如销售部，财务部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。

__EOF__

本文作者：SalemG
本文链接：https://www.cnblogs.com/guosiliang/p/13731501.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！