后台经验分享：如何做权限管理系统设计？

———— / BEGIN / ————

在人人都是产品经理的网站上蛰居了4年，学习了四年，由于最近的工作方向偏向于后台，在设计后台时时常会查阅后台的相关资料，但是关于后台的文章等内容分享的太少了。

正好这一段时间在调整，想尝试撰写一系列的关于后台文章，希望跟大家一起来探讨、分享，希望对大家有所裨益。

由于不同的后台需求多样化，不能一一兼顾，只能蜻蜓点水，尽量深入浅出。

一、权限管理系统定义

权限管理是一个几乎所有后台系统的都会涉及的一个重要组成部分，主要目的是对整个后台管理系统进行权限的控制，而针对的对象是员工，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，数据泄露等问题。

其实权限管理的设计并不难，就目前来说最广泛的是一个账号对应多个角色，每个角色对应相应的权限集（RBAC模型）这种模型基本可以应对所有的问题，且通过角色可以实现灵活且多样的的权限操作需求，我们梳理一下上面主要提到的几个名词：账号、角色、权限。

1. 账号的定义

每个员工想要进入系统肯定都会有一个账号，而这个账号就是一把钥匙。

我们通过控制账号所具备的权限，进而控制这个员工的授权范围。

因此需要告诫员工，账号密码不能轻易提供他人，不然遇到的问题由自己承担。

2. 角色的定义

角色管理是确定角色具备哪些权限的一个过程，他是一个集合的概念，是众多最小权限颗粒的组成。

我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。

引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。

角色的命名最好按照职位而定，例如市场部普通员工，市场部主管等。因为职位在任何企业都是存在的，且是有限的，并且容易理解，市场部文员那就是市场部文员角色，方便我们配置权限时的判断，避免配置错误。

3. 权限的定义

权限可以分为三种：页面权限，操作权限，数据权限。

页面权限

控制你可以看到哪个页面，看不到哪个页面。

很多系统都只做到了控制页面这一层级，它实现起来比较简单，一些系统会这样设计，但是比较古板，控制的权限不精细，难以在页面上对权限进行更下一层级的划分。

操作权限

则控制你可以在页面上操作哪些按妞。

可能你在某个页面上，只能查询数据，而不能修改数据。

数据权限

数据权限则是控制你可以看到哪些数据，比如市场A部的人只能看到或者修改A部创建的数据，他看不到或者不能修改B部的数据。

哪个页面要放置哪些权限，完全根据业务需要配置，你只需要把控制权限的地方列出来交给开发就好。

二、权限管理系统基本的页面设计

1. 角色列表页

删除角色，需要去判断是否有账号关联了此角色，如果有关联，则不允许删除。如果角色不想用或者取消了，你可以将角色设置为无效状态，账户获取角色时会首先判断角色是否有效。

从便捷性上可以提供一个功能批量给某角色添加账户，在新员工入职时特别是同一岗位的，设置的权限时效率会大大提升。

给角色配置权限

2. 账户列表页

首先我们肯定有个账户列表，因为我们是给账户配置权限。里面可以查询到或者添加到所有的人（为什么说添加，因为很多大公司有很多的管理系统，而每一个管理系统只有一部分人用，所以不会把所有人都在账户列表显示出来，故用到了添加）。

这里需要注意的是账号的禁用，用于防止员工离职后的问题。可以跟人事系统打通，人事那边设置某员工离职后，所有系统账号自动设为禁用。

有很多系统，提供了给账号直接添加具体权限的功能而不是通过角色，如同下图，我是不提倡的，给某个员工增加某个特定权限时，虽然操作更加便捷了，但是缺少规范性，一个员工明明是只有市场部角色，居然有财务部的支付功能，这个在页面上是解释不通的，而且日积月累会导致人员权限混乱，这种需求完全可以通过可以新增一个角色去处理。

账户列表

给账户配置角色

3. 从权限添加账户

这种方式也是不提倡的，这种形式如果上面所讲的，直接给账号添加具体的权限，虽然提升的操作的便捷性，但是影响了权限的规范性与可维护性，角色这一桥梁就会变成断桥，统一性就会破坏掉。

截取的部分原型的页面，页面有点粗陋，仅供参考。

三、权限的分配

权限的分配要合理，很多公司分配给部门权限的时候很随意，部门要什么权限就给什么权限，其实这是有隐患的。

我们更多需要更深入的考虑部门能有什么权限，而不是要什么权限，而这一块往往被忽略。

四、总结

归根到底我想强调一件事情：权限的管理，如何从公司制度上重视？

即如何规范权限的分配，即那个部门哪个员工要哪个权限都需要进行审批或邮件知会后才能帮其配置，还有哪些数据要设置权限，哪些操作要设置权限，这些权限管理过程才是权限系统的核心，恰恰这些核心的东西在系统上是体现不出来的。

前期的不经意就会在后期会变成麻烦，不仅影响业务效率，更会导致风险危机。

权限管理最终是为了风控，如果权限的风控意识没做好，权限系统做的再好也是枉然。

———— / END / ————

来源：人人都是产品经理                       时间：2017年11月06日

　　B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。

需求陈述

不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。

可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。

权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。

满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。

关于设计

　　借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。

我们先来分析一下数据库结构：

　　首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：

　　这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：

　　由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：

　　另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：

　　根据上面的分析，我们进行数据库结构设计，如下图：

点击这里查看权限管理系统数据表字段设计

　　为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。

一 权限映射表 如下图：

　　首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。

　　看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：

　　如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。

　　使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。

　　action字段相关联在数据库中的表现如下图：