基于RBAC 的SAAS系统权限设计

为什么系统需要权限控制？

 

生活中有没有权限限制？

 

灾难片电影《2012》中富人和权贵有权登上诺亚方舟，穷苦老百姓只有等着灾难的来临；

 

屌丝身边为什么没有那些长得漂亮、身材好的姑娘存在？

 

因为有钱人和漂亮姑娘都是珍贵稀有的，稀有的人在一起玩耍。而普通人往往无权拥有他们所拥有的权限。

 

 

权限管理的本质

 

web程序通过 url 的切换查看不同的页面（功能），所以权限管理指的其实就是URL管理，对url控制就是对权限的控制。

 

因此，一个人有多少个权限取决于他可以访问多少个URL。

 

 

RBAC是什么？

 

RBAC（Role-Based Access Control），是基于角色的访问控制，是一种先进的权限管理的模型。RBAC把用户通过角色与权限进行关联。即让一个用户拥有若干角色，每一个角色拥有若干权限。

 

这样就构造成了“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。

 

 

 

 

 

权限系统中的概念

 

用户

应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

 

角色

为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

 

组

为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。

 

 

权限

系统的所有权限信息表达了两层含义。即控制的对象、操作。向上引申可将权限划分为3个组成部分：

 

页面权限：用户可以看到那些页面；

 

操作权限：用户可以在页面内进行那些操作，增删改查等；

 

数据权限：用户可以看到那些数据或内容；

 

 

 

权限模块设计

 

完整的权限管理做大可作为独立 系统进行开发，小做也必定做为SAAS平台的核心基础模板，在最初迭代初期就进入规划、设计环节。在进行权限模块设计时，产品可以从两个角度考虑：

 

1.权限控制管理

 

即对系统中各类涉及权限限制的元素进行使用、查看等操作的权限控制。

 

l最基本的权限管理是菜单管理，用户没有权限的功能模块在菜单节点上不显示。

 

如：普通业务人员登录系统后，是看不到【用户管理】菜单的。

 

l功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。

 

如：经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。所以在访问【添加用户】的功能（URL）时，应该有没有授权的提示信息。同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。

 

l行级权限管理

 

如：论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】此时的权限设计就应该根据论坛的相应ID来判断权限信息。

 

l列级权限管理

 

如：业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。

 

此时的权限设计要判断相应的字段（列）是否可以显示。

 

l组织机构/部门级数据权限管理

 

如：业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到销售一部和销售二部的销售订单。此时的权限设计就要根据销售订单数据本身的部门属性来做判断

 

l范围型业务数据权限管理

 

如：大卖场销售人员在下销售订单时，要选择相应的产品所在仓库信息。业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】

 

 

2.权限分配管理

 

针对权限管理内容通过系统授权功能分配给具体的用户，角色的过程。

 

l直接对用户授权，直接分配到用户的权限具有最优先级别。

 

l对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。

 

l对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。

 

l角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。

 

l分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

 

 

界面总体设计

 

想想一个简单的权限系统应该有什么功能呢？当然是：用户-角色-权限，下图所示过程：

 

 

创建角色列表

 

 

在角色列表快速创建一个角色：点击创建角色，支持创建角色时配置权限。

 

 

创建用户列表

 

 

在用户列表快速创建一个用户：支持用户关联角色的功能。用户权限管理常见设计包括：

 

l所属角色：当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的角色。

 

l所属组：当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。

 

l用户权限：通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。

 

l总权限：通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。

 

l用户管理：当选择了某用户时，点击右键，弹出菜单列表：修改、删除、取消，点击修改和删除按钮可以实现用户的删除和修改功能。

 

选择某个组织，例如 “广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。

 

l组织管理：选择某个组织，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。

 

 

上述案例是基于最简单的RBAC0模型创建，适用于大部分常规的权限管理系统。

 

角色权限管理

 

我们还可以在上面的内容基础上再加上角色等级。角色权限管理设计中，通常包括以下内容：

 

l包含用户：当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的用户。

 

l包含组：当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。

 

l角色权限：通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存”按钮保存修改信息。

 

l管理角色：选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。

 

具体界面呈现如下图：

 

 

组权限管理

 

除此之外，还有组权限管理

 

l包含用户：当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用户。

 

l所属角色：当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该组所属的角色。

 

l组权限：通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息

 

l总权限：通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息

 

l组管理：选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能

 

操作日志管理

 

l查询操作日志：输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。

 

l删除操作日志：输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。

 

- End -