RABC --权限控制解读

标签：自动   系统   介绍   其他   出现   数据   bubuko   利用   role   

一、基于RBAC的概念介绍

1、RBAC（Role-Based Access Control ）基于角色的访问控制。

2、RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

3、RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。

1、）基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。

2、）RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。

    RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。

    RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

3、）RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。

二、基于RBAC的几种权限体系设计

1、用户-角色-权限

这种权限体系其实就是RBAC0的模式了。这里面又包含了2种：

1. 用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当；
2. 用户和角色是多对多关系，即：一个用户可同时充当好几种角色，一种角色可以有多个用户担当；

如上图：对于左边的用户-角色对应，每个人只能同时拥有一种角色，但是同一个角色里边，可能会含有多个用户（如：李四和王麻子都是业务员）；而右边的用户-角色对应，是在左边的基础上，增加了一个用户可拥有多种角色的情况（如：小马哥既是经理，也要负责财务的工作）；

那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？

我的建议是：尽量可能地使用多对多的权限体系。如果这个系统的功能比较单一、使用人员较少、岗位权限相对清晰且不会出现兼岗的情况，这种情况也可以考虑用多对一的权限体系。

2、用户-组织-角色-权限

在“用户-角色-权限”的基础上，我们增加了用户与组织的关联关系，组织决定了用户的数据可视权限。但要想真正达到这个效果，我们还需要做2件事：

1. 组织层级划分。如下图，我们需要对组织进行梳理，并划分层级；
2. 数据可视权限规则制定。比如：上级组织职能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。

通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了。

3、用户-组织-岗位-角色-权限

第三种权限体系又是在第二种权限体系上进行优化的，增加了用户与岗位的关联关系，示意图如下：

增加岗位有以下几点好处：

1. 识别用户的主要身份。一个人可能身兼多职（多个角色），但是他的主要职能是固定的，那怎么告诉系统用户的主要职能是什么呢？答案就是：通过岗位！拿上面的小马哥举例：小马哥虽然身兼经理和财务两种身份，但他的本职工作是“经理”，因此，他的系统岗位应该“经理”。当他登录时，系统会识别他的身份为“经理”，只不过这个“经理”刚好兼具了其他岗位的职能而已；
2. 通过“组织-岗位”关联，快速甄别用户岗位。公司在不断地发展的过程中，系统的用户角色也会不断增加，当角色达到一定数量以后，管理员每新增一个用户都要花相当的时间去寻找角色。引入岗位后，可将组织和岗位、岗位和角色提前进行关联，配置账号时，管理员只要选定组织，系统就给出与该组织关联的岗位，而这些岗位，又是提前关联好角色的，选择起来，既方便又高效！

文章参考：http://www.woshipm.com/pd/872372.html

                 https://www.cnblogs.com/vinozly/p/4851364.html

RABC --权限控制解读

标签：自动   系统   介绍   其他   出现   数据   bubuko   利用   role   

原文地址：https://www.cnblogs.com/takemyjavalisfe/p/10337915.html