如何做权限管理系统设计

在设计后台时时常会查阅后台的相关资料，但是关于后台的文章等内容分享的太少了，正好这一段时间在调整，想尝试撰写一系列的关于后台文章，希望跟大家一起来探讨、分享，希望对大家有所裨益，由于不同的后台需求多样化，不能一一兼顾，只能蜻蜓点水，尽量深入浅出。

权限管理系统定义
权限管理是一个几乎所有后台系统的都会涉及的一个重要组成部分，主要目的是对整个后台管理系统进行权限的控制，而针对的对象是员工，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，数据泄露等问题。其实权限管理的设计并不难，就目前来说最广泛的是一个账号对应多个角色，每个角色对应相应的权限集（RBAC模型）这种模型基本可以应对所有的问题，且通过角色可以实现灵活且多样的的权限操作需求，我们梳理一下上面主要提到的几个名词：账号、角色、权限。

账号的定义
每个员工想要进入系统肯定都会有一个账号，而这个账号就是一把钥匙。我们通过控制账号所具备的权限，进而控制这个员工的授权范围。因此需要告诫员工，账号密码不能轻易提供他人，不然遇到的问题由自己承担。

角色的定义
角色管理是确定角色具备哪些权限的一个过程，他是一个集合的概念，是众多最小权限颗粒的组成。我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。

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

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

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

操作权限则控制你可以在页面上操作哪些按妞。（延伸：当我们进入一个页面，我们的目的无非是在这个页面上进行增删改查，那在页面上对应的操作可能是：查询，删除，编辑，新增四个按钮）可能你在某个页面上，只能查询数据，而不能修改数据。

数据权限则是控制你可以看到哪些数据，比如市场A部的人只能看到或者修改A部创建的数据，他看不到或者不能修改B部的数据（延伸：数据的控制我们一般通过部门去实现，每条记录都有一个创建人，而每一个创建人都属于某个部门，因此部门分的越细，数据的控制层级也就越精细，这里是否有其他好的方式除了部门这个维度还有其他什么方式可以控制数据权限，大家可以提出来探讨一下）。

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

权限管理系统基本的页面设计
角色列表页
删除角色，需要去判断是否有账号关联了此角色，如果有关联，则不允许删除。如果角色不想用或者取消了，你可以将角色设置为无效状态，账户获取角色时会首先判断角色是否有效。
从便捷性上可以提供一个功能批量给某角色添加账户，在新员工入职时特别是同一岗位的，设置的权限时效率会大大提升。

给角色配置权限

账户列表页
首先我们肯定有个账户列表，因为我们是给账户配置权限。里面可以查询到或者添加到所有的人（为什么说添加，因为很多大公司有很多的管理系统，而每一个管理系统只有一部分人用，所以不会把所有人都在账户列表显示出来，故用到了添加）。
这里需要注意的是账号的禁用，用于防止员工离职后的问题。可以跟人事系统打通，人事那边设置某员工离职后，所有系统账号自动设为禁用。
有很多系统，提供了给账号直接添加具体权限的功能而不是通过角色，如同下图，我是不提倡的，给某个员工增加某个特定权限时，虽然操作更加便捷了，但是缺少规范性，一个员工明明是只有市场部角色，居然有财务部的支付功能，这个在页面上是解释不通的，而且日积月累会导致人员权限混乱，这种需求完全可以通过可以新增一个角色去处理。
账户列表

给账户配置角色

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

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

权限的分配
权限的分配要合理，很多公司分配给部门权限的时候很随意，部门要什么权限就给什么权限，其实这是有隐患的，我们更多需要更深入的考虑部门能有什么权限，而不是要什么权限，而这一块往往被忽略。

总结
归根到底我想强调一件事情，权限的管理，如何从公司制度上重视，即如何规范权限的分配，即那个部门哪个员工要哪个权限都需要进行审批或邮件知会后才能帮其配置，还有哪些数据要设置权限，哪些操作要设置权限，这些权限管理过程才是权限系统的核心，恰恰这些核心的东西在系统上是体现不出来的。前期的不经意就会在后期会变成麻烦，不仅影响业务效率，更会导致风险危机。权限管理最终是为了风控，如果权限的风控意识没做好，权限系统做的再好也是枉然。

一、权限管理系统定义

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

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

1. 账号的定义

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

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

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

1. 角色的定义

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

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

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

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

1. 权限的定义

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

页面权限

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

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

操作权限

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

延伸：当我们进入一个页面，我们的目的无非是在这个页面上进行增删改查，那在页面上对应的操作可能是：查询，删除，编辑，新增四个按钮。

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

数据权限

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

延伸：数据的控制我们一般通过部门去实现，每条记录都有一个创建人，而每一个创建人都属于某个部门，因此部门分的越细，数据的控制层级也就越精细，这里是否有其他好的方式除了部门这个维度还有其他什么方式可以控制数据权限，大家可以提出来探讨一下。

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

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

1. 角色列表页

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

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

给角色配置权限

1. 账户列表页

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

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

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

账户列表

给账户配置角色

1. 从权限添加账户

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

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

三、权限的分配

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

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

四、总结

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

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

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

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

一．引言

   因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。



   权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

二．设计目标

   设计一个灵活、通用、方便的权限管理系统。



   在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢。我们可以把这些资源简单概括为静态资源（功能操作、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。

系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。

三．相关对象及其关系

   大概理清了一下权限系统的相关概念，如下所示：

1. 权限

系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子

系统管理

    用户管理



           查看用户



            新增用户



                 修改用户



                 删除用户



   对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。

1. 用户

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

1. 角色

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

1. 组

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

针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。

通用权限管理设计篇_设计模式

有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比较棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。

当然对于有些项目，权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。

在另一些情况中，引入了角色对象，例如基于角色的权限系统， 只需要给角色分配权限，用户都隶属于角色，不需要单独为用户分配角色信息。

理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于N对N的关系，一般需要加入一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为：权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。

   各表及其关系如下： 

通用权限管理设计篇_设计模式

1. 用户表

通用权限管理设计篇_设计模式

1. 角色表

通用权限管理设计篇_设计模式

1. 权限表

通用权限管理设计篇_设计模式

1. 组表

通用权限管理设计篇_设计模式

1. 角色权限表

通用权限管理设计篇_设计模式

1. 组权限表

通用权限管理设计篇_设计模式

1. 组角色表

通用权限管理设计篇_设计模式

1. 用户权限表

通用权限管理设计篇_设计模式

1. 用户角色表

通用权限管理设计篇_设计模式

1. 用户组表

通用权限管理设计篇_设计模式

1. 组织表

通用权限管理设计篇_设计模式

1. 操作日志表

通用权限管理设计篇_设计模式

1. 引言 1.1 编写目的

本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 背景

a、 软件系统的名称：通用权限管理系统；

b、 任务提出者、开发者：谢星星；

c、 在J2EE的web系统中需要使用权限管理的系统。 1.3 术语

本系统：通用权限管理系统；

SSH：英文全称是Secure Shell。 1.4 预期读者与阅读建议通用权限管理设计篇_设计模式

1.5 参考资料

《通用权限管理系统需求规格说明书》

《通用权限管理系统数据库设计说明书》 2. 总体设计 2.1 设计目标

权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.2 运行环境

操作系统：Windows系统操作系统和Linux系列操作系统。 2.3 网络结构

通用权限管理系统可采用Java Swing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEB Service上。暂时用Java Swing实现。 2.4 总体设计思路和处理流程

在说明总体设计思路前，我们先说明本系统的相关概念：

1. 权限资源

系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子

系统管理

    用户管理



           查看用户



           新增用户



           修改用户



           删除用户

对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。

1. 用户

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

1. 角色

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

1. 组

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

针对如上提出的四种对象，我们可以整理得出它们之间的关系图，如下所示：通用权限管理设计篇_设计模式

总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。

其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分，某个组的权限信息可用公式表示：组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理包括包含用户、包含组和角色权限三部分，某个角色的权限的计算公式为：角色权限 = 角色自身权限。

用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。

组织管理即对用户所属的组织进行管理，组织以树形结构展示，组织管理具有组织的增、删、改、查功能。

操作日志管理用于管理本系统的操作日志。

注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。 2.5 模块结构设计

本系统的具有的功能模块结构如下图所示： 通用权限管理设计篇_设计模式

2.6 尚未解决的问题

无。 3. 接口设计（暂略） 3.1 用户接口（暂略） 3.2 外部接口（暂略） 3.3 内部接口（暂略） 4. 界面总体设计

本节将阐述用户界面的实现，在此之前对页面元素做如下约定：通用权限管理设计篇_设计模式

4.1 组权限管理 通用权限管理设计篇_设计模式

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

通用权限管理设计篇_设计模式

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

通用权限管理设计篇_设计模式

通用权限管理设计篇_设计模式

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

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

通用权限管理设计篇_设计模式

4.2 角色权限管理 4.2.1包含用户

通用权限管理设计篇_设计模式

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

4.2.2包含组
通用权限管理设计篇_设计模式
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。
4.2.3角色权限
通用权限管理设计篇_设计模式

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

   在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。 通用权限管理设计篇_设计模式 4.3 用户权限管理 4.3.1所属角色 

通用权限管理设计篇_设计模式

当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的角色。 4.3.2所属组通用权限管理设计篇_设计模式

当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。 4.3.3用户权限通用权限管理设计篇_设计模式

通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。 4.3.4总权限通用权限管理设计篇_设计模式

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

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



   选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。 通用权限管理设计篇_设计模式

4.3.6组织管理

   选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。通用权限管理设计篇_设计模式

4.4 操作日志管理 4.4.1查询操作日志

编号 操作名称 操作内容 操作人 操作时间

1 xx1 – Amigo 2007-10-8

2 xx2 – xxyy 2007-10-8

…

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

编号 操作名称 操作内容 操作人 操作时间

1 xx1 – Amigo 2007-10-8

2 xx2 – xxyy 2007-10-8

…

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