项目中权限控制系统的设计

转载于：http://blog.csdn.net/wzj_110/article/details/81590472
RBAC
权限：权利(能做的)和限制(不能做的)，在权限范围内做好自己的事情，不该看的不看(机密)，不该做的不做！最开始真正有权限的概念是在Linux上关于文件和目录的权限，再后来联想到在Windows系统下对某些系统文件的操作，慢慢回想起以前所遇到的关于权限的事情！权限管理，平时里很多地方我们都可以看到，比如聊QQ时群里的群主、管理员以及成员之间的功能是不一样的……大家一定会遇到的一个问题，所以整理 一下自己写权限系统的一些经验给大家，只起参考作用。

   RCBA：基于角色的权限访问控制(Role-Based Access Control)

一、为什么要实现权限系统
1、 系统中的权限系统，缺少组织结构管理。例如：树型的组织结构，有些系统虽然考虑了分层，但是没有考虑分多少层，组织结构是否考虑了集团公司，全国连锁经营这种模式，实际上就是很多个独立单位的概念。很多系统遇到这个问题，就需要重新做整个系统。
2、 不同登陆用户要有不同的权利，而且要有不同的菜单，如果不能灵活的修改他们的权限，那用户需求一旦变化，不是就很郁闷了。系统要能够解决这个问题，我们就要灵活的控制每个页面。即便是系统已经开发完成，投入运行，也可以通过修改配置文件，而实现权限的重新调整。

二、权限简单控制原理
规则一：每个登陆的用户，可以有多个角色；
规则二：每个角色又可以访问多个功能点；
规则三：每个功能点又由多个页面组成；
根据这个对应关系，就可以让每个用户对应到不同的页面，如果进行细致设置，基本上可以解决了应用中的很多情况

三、名词解释
页面(URL)：在web开发中也称为URL，最朴素的权限控制，就是基于页面的控制,即赋予访问者可以访问页面的范围，在系统记录所有的页面，配置权限时将允许访问的页面赋予使用者。虽然简单,却很直接和容易理解，基于这个思想，将软件的URL作为权限,进行控制，将所有的URL进行记录。但如果直接将URL作为权限配置给使用者,是相当麻烦的，因为一个操作功能往往不是在一个请求内完成的，这就意味着为了让使用者有权利完成一个功能，就必须将一组URL赋予使用者，以便其访问，显然这样给系统管理和维护带来了很多不方便.因此我们就需要功能点。

  功能点: 是一组不可分割URL(url的集合)，因为这组URL共同完成一个功能，因此他们是不可分开的。使用者要正常完成操作,就必须有权访问这组URL中的每一个，这样将一个功能点赋予使用者，也就意味着这个使用者有访问这些URL的能力。在业务中系统管理员不用关心到底什么权限对应哪些URL，只要将功能点赋予使用者，就可以关联URL了，完成授权过程。

  角色: 角色又可以成为"岗位",它是一组功能点。很多时候多个使用者的操作权限是相同的，例如一个部门中，大家都有察看自己邮箱的权利，都有修改自己口令和基本信息的权利。这时,就将邮箱功能点、修改口令、基本信息维护这几个功能点集合起来,建立一个色--"操作员岗"。那么在给使用者授权时，只要将这个角色赋予使用者，该使用者就拥有了相应的功能操作权限。适合多使用者权限的管理，尤其是使用者数量众多而且权限相同或者类似时，可以减少很多麻烦，减少出错概率。同时一个使用者可以同时拥有多个角色，这些角色所代表的权限,使用者可以同时拥有,是权限的并集。例如一个部门经理可以有"操作员"角色，具备基本的操作权限，同时还可以将"部门审核员"这个角色授予他，这样可以作操作部分管理功能。这样做可以灵活的组合和配置使用者权限，适应复杂权限管理。

  用户:是软件系统使用者的系统账号。每个使用者都有自己独一无二的账号，系统通过这个账号来识别不同的使用者。账号的安全是通过使用者口令加以保护的，口令在系统中是用加密的方式进行保存，避免了通过数据库系统泄漏使用者口令的问题。系统使用者是通过"用户"与"功能点"关联，完成使用者的授权，在使用者登陆系统后，也是通过"用户"来认证当前使用者的权限。

说明：将权限和角色关联起来，就可以把权限和用户的耦合解开，然后将角色和用户关联从而来达到用户和权限的最终关联！

图1------>三权分立，最终关联！

四、数据库设计
一个用户可以拥有多个权限，同时一个权限也可以赋予多个用户，那么用户和权限就是多对多的关系，那么就需要角色表来维护和链接用户和权限的关系。通过用户和角色关联，角色和权限关联，从而实现用户和权限的一个间接关系。那么问题又来了，用户和角色也是多对多的关系，角色和权限也是多对多的关系，我们还需要两张中间表，就是用户角色表和角色权限表。
1、用户表：登录的用户
2、角色表：与权限相关联
3、权限表：与角色相关联------>功能，具体的可操作的菜单项
4、用户角色表：用户和角色的中间表
5、角色功能表：角色和功能的中间表

图1—表的设计

交互过程：一个用户登陆了，先去找角色关联起来，再去找这些角色关联了什么样的操作，最后把这些操作对应给用户，那么用户一登录所看到的的就是可以操作的，也就是他权限范围内可以做的事情！

补充：Java权限管理之权限类型！

(1)特点：看到什么就操作什么！简单粗暴！

(3)特点：菜单就类似于导航，而功能就是对应的增删该查！

(4)特点：企业内部有很多系统，ERP、EHR、OA、CRM等等！怎么去管理？—>了解各系统名词的含义！

传统就是每个系统都有一个账号，登录还得切换！现在一个用户一个密码，对应所有的企业内部的系统，所谓的SSO单点登录！

好处：方便管理和操作！

#####################################分割线#########################################

五、权限的设计与实现

(1)表中特殊的设计

特别说明：

时间—>插入和修改的时间！

用户状态–>有效和无效！

(2)代码中实体(POJO类)的设计

(2)代码中实体(POJO类)的设计
说明：dto是数据传输对象的缩写，由于数据是在controller和页面之间进行传输，有些页面涉及多个实体的数据同时展示，用dto进行封装。

Tree：导航的树形结构

数据缓存：比如把整个菜单缓存起来。每次登陆展示就特别方便！

用户信息：超时时间、权限信息等

(4)包的最终结构

说明：AjaxResult

(5)权限和应用程序

说明：方式2根据编码–>Apach开源的的shiro和更复杂的Spring Security来实现权限控制！

(6)两种细说


说明：重点掌握！

1、用户,角色,权限(功能),角色权限,用户角色五个实体类对应五张表(省略…)
2、action层调用service层，service层调用dao层
action是界面层：管理业务（service）调度和管理跳转的，是一个管理器，只负责管理
service是业务逻辑层：管理具体功能和逻辑的，负责实施—>宏观！
DAO数据访问层：只完成增删改查，只负责封装，具体的业务逻辑如何去实现由service实施–>微观！
3、action：实现页面的功能
service：先定义一个接口抽象出具有的功能，再由impl去具体的实现，dao也是如此。

六、源码
在写权限管理的时候最头痛的地方也就是权限功能的模块了，但是不管是怎样的一个业务也是数据的增删改

源代码省略。。。

七、总结
以上只是功能模块的代码，还有角色、用户、用户角色。角色权限等模块，这些也就仅仅是数据的增删改查操作，只要大家用心的去写一下就可以了。不管是怎样的权限管理系统远远要比这个复杂，这里只是为了给大家提供功能模块的思维，仅供大家参考。

八、迁移
k8s权限中就有RBAC的影子