java系统权限设计思路总结
有关权限⽅⾯的⼀些想法和最近项⽬中的⼀些探索过程。 我们主要想解决⼀下问题。
1.什么是权限，程序员理解的权限和客户所理解的权限是不是⼀致的。
2.权限的划分原则，权限到底是根据什么原则进⾏组合的。
3.⾓⾊是⽤户与权限之间的必要的关系吗？⾓⾊到底承接了什么作⽤。
4.如何进⾏合理的表设计。
5.安全框架。
1.什么是权限
在很多与开发者也好，与客户也好，沟通的过程中我们很多次提到了权限，但是权限具体的含义每个⼈理解的含义都不明确，这样很容易造成双⽅信息不对称，有的⼈就只是把权限理解成某个页⾯的是否可访问，但是有的⼈却理解成其他的东西。所以我们要彻底的定义⼀下权限是什么。
权限到底是名词属性还是动词属性，还是名词、动词属性均包含，这对于权限的含义很重要。如果是名词
属性的话，那么它应该是有具体的指代物；如果是动词，则应该具有⾏为表⽰。
·权限的名词属性：api接⼝、页⾯、功能点。
·权限的动词属性：可操作、不可操作。
那么我们现在来看，其实权限是名词、动词属性，它⼀定是表达了两层含义。即控制的对象、操作。
1.例如：权限A表⽰页⾯A的可访问。
2.例如：权限B表⽰页⾯B可访问且页⾯内的功能b不可使⽤
3.例如：权限C表⽰接⼝C不可调⽤。
4.例如：权限D表⽰页⾯D可访问，且接⼝D可访问。
那么进⼀步的说明，权限可以表⽰单个控制的对象的操作集合，也可以表⽰多个控制的对象的操作集合。⽽这两者的取舍则是有设计⼈员决定的。
⼀句话总结权限的含义：what（若⼲元素）进⾏how（若⼲操作）
2.权限的划分原则
我们了解了权限的具体含义之后，接下来就是⽤的问题，我们该如何去使⽤权限，如何将系统中的操作元素进⾏⼀个组合，这个我借鉴⽹上的⼀篇⽂章来解释。划分原则可以按照“最⼩特权原则”和“数据抽象原则”。
·最⼩特权原则
1.我先举⼀个反例，我把系统中所有的元素和操作都组合成⼀个权限。⼀个⽤户拥有这个权限就相当拥
有了系统所有的功能，实际上这肯定是不⾏的，⽤户在⼀套系统中⼀定有他不允许操作的内容，哪怕是超级管理员也可能会有不能操作的元素，那么最⼤化权限则是⾏不通，因为不符合常理。
2.据此，我们就把权限再进⾏⼀个拆分，按照业务模块进⾏拆分，但是这实际上也是不⾏的。就⽐如系统中的财务模块，假定模块中含有报销页⾯和申报页⾯，如果按照模块进⾏拆分，那么肯定有⽤户同时包含了两个互斥功能。
3.根据1和2，我们需要按照最⼩化进⾏权限划分。但是这个也是值得商榷的，因为不同系统，最⼩的权限划分对于提供的功能来说，划分的⾓度也是不同的。
·数据抽象原则
1.“最⼩特权划分”从某个程度上来说决定了控制的对象 ，⽽数据抽象原则是是决定了操作。
2.数据抽象从字⾯的意思来看，其实很难理解到底是什么意思。通常我们⼝头上说最多的是CRUD增删查改，这实际上就是数据抽象的⼀种，我们可以理解成元素操作许可权的意思。
3.但是CRUD并不是数据抽象的全部，增删查改⽤于单实体，基本是没问题的，但是在构建关系上，其实是不够⽤的，例如任免某个经理管辖某个部门，从业务表⾯⽽⾔它修改了经理的管辖范围。但是从代码底层构建上来说，它属于在经理和部门间新增了⼀道关系，所以根据需求我们需要再额外的增加⼀类
许可权“任免许可”，这⼀类型的扩展则需要根据系统实际的业务情况进⾏划分。
“最⼩特权”和“数据抽象”分别决定了权限中控制的对象和操作，但是这⾥⾯还差了⼀个⾓度，则是现阶段⾮常普遍的前后端分离的权限划分的问题。
·服务端的权限
1.前后端分离下的服务端，本质⽽⾔只是提供接⼝的或者rpc服务等其他资源服务的服务提供⽅。
2.服务端能提供的权限的鉴权机制的对象：接⼝服务（api或者其他形式的服务）不包含前端的页⾯或页⾯中的功能点。
3.前端或移动端的页⾯元素的控制和鉴权实质上不由服务端控制。
4.服务端可以单独的控制服务的权限。
数据可视化什么意思
5.服务端的服务对象是前端、移动端、第三⽅客户端，提供的服务是接⼝服务。
在前后端已经分离的情况下，服务端对于前端⽽⾔只是接⼝的提供者，但⽆权⼲涉前端页⾯的展⽰，服务端对于前端⽽⾔，能提供的是仅鉴权服务的接⼝⽽已，但是页⾯的构成，页⾯的栏⽬菜单或页⾯内的功能点的构成均由前端单独完成的。
·前端或移动端的权限
1.前端的鉴权包含页⾯的可访问，和页⾯上的某项功能按钮是否可以操作。
2.前端和移动端的服务对象是⽤户，提供的服务是可视化的页⾯。
前后端分离的权限对象
前后端的服务对象的责任划分清晰之后，我们就不会混杂权限的归属的问题，在过去前后端没分离的情况下，页⾯本⾝就是服务端的⼀体，就没有这⽅⾯的问题。虽然分清楚了各端本质提供的服务的情况，但是前后端分离的权限划分中仍有新的问题。
1.因为服务端和前端的鉴权对象不⼀致，服务端只能鉴权到api接⼝，那么是否将api接⼝和前端的页⾯
乃⾄页⾯功能点进⾏数据库表与表层⾯的绑定关系。
2.如果进⾏了进⾏了表与表之间的绑定关系，那么整个权限系统的维护量，是否能在能承受范围之内。
3.如果不进⾏表与表之间的绑定关系，前端页⾯在操作功能的时候，服务端如何鉴权页⾯调⽤的api接⼝是否在⽤户可操作的权限之内？
其实上⾯的问题则需要⼀个取舍，要么增加运维成本严格控制前端调⽤api接⼝的关系，偏重服务端的接⼝服务鉴权。要么是给api接⼝和前端页⾯及功能点再提供⼀个通性的逻辑判断处理，如：页⾯及调⽤的功能点属于某个业务模块的操作许可，⽽页⾯触发的接⼝也刚好是这个业务模块的操作许可，那么鉴权通过，否则鉴权失败。这种就是属于侧重前端对于⽤户的控制，弱化了接⼝级的控制。
3.⾓⾊与权限的关系
通过1，2的描述，基本确定了权限的定义和划分⼀个权限的通⽤法则。⽤户在系统中最终是通过权限来使⽤各种功能点，是否有必要在⽤户和权限中间再额外的附加⼀个关系。在我们现在的权限设计中，是增加了这样⼀层关系的，就是⾓⾊。
1.减少操作层⾯的重复性。⾓⾊其实就是⼀组权限的集合，是权限集合的更⾼级抽象，为了便于运维和实际管理，通过⾓⾊的赋予，替代了权限赋予⽤户的繁琐性，在⼀套系统中，普遍情况都是权限的数量
多于⾓⾊的数量。
2.权限是控制对象和操作集合，它本⾝不存在任何状态，但是在赋予在⽤户⾝上则拥有了状态，⽐如权限A中允许⽤户访问页⾯A，权限B允许⽤户访问页⾯B，权限D运⾏⽤户访问B页⾯，但是不允许访问A页⾯。那么这层关系的维护在⾓⾊层⾯的话，会更加清晰，也就是说本⾝⾓⾊具有权限集合组装的策略问题，对于互斥的权限有不同的⽅案处理。（权限中没有某个操作和权限中禁⽌某个操作，是两个不同的⾓度，不能混为⼀谈）
3.因为权限的可能存在互斥性，在实际业务中也会引发⾓⾊的互斥性，举⼀个现实中的案例来解释互斥性：张三是软件部的负责⼈但因为⼯作的特殊性也同样⾪属于业务部的普通员⼯，我们设定负责⼈是可以要求⼈事部门给本部门进⾏招聘的，在实际的情况中，张三能给软件部招聘新员⼯，但是不能给业务部招聘员⼯。我们把这个案例运⽤在系统中，张三则是拥有负责⼈和普通员⼯两个⾓⾊，但是招聘的功能如果不加以控制，则会发⽣张三给业务部招⼈的结果。于是为了解决⾓⾊的这类问题，引⼊了职责划分的⽅案。
4.职责划分分为：静态、动态。所谓静态职责划分则是在⾓⾊创建之初就已经确定了⾓⾊的职责内容。动态职责划分是系统运⾏过程中对⽤户已有的⾓⾊进⾏控制，例如：某些⾓⾊不能共存在⽤户⾝上（互斥）、⾓⾊或⾓⾊的分配数量限定（控制⽤量）、⾓⾊与⾓⾊同时只能激活⼀个进⾏使⽤（时刻唯⼀）。
引⼊⾓⾊的概念后，实际上这已经是⼀个⽐较完整的RBAC的权限设计的模型了。
4.数据表的设计思路
根据3的结论，实质上已经有了⼀个基础的表设计的雏形。在这⾥就有⼀些值得注意的点。
·（1）问：权限表是否有必要存在？
·（1）答：这个要结合系统的实际使⽤场景进⾏考虑，如果系统中的权限的对象很单⼀，⽐如只有页⾯，或者只有api接⼝的话，其实权限表可有可⽆。增加权限表反⽽会导致初始化项⽬权限的⼯作量增加。
但是若系统中的权限对象是多个，那么权限表的存在就有了更深层次的意义。在权限对象是多个的情况，权限表的存在就是为了更好更抽象的组合“最⼩特权”及“责任划分”的操作对象。同时，⼀旦系统中的操作对象增加了，只需要给权限表增加⼀个对象表和关系表就可以了。这样易于扩展。
·（2）问：api接⼝和页⾯实际上是没有关系的，但是在鉴权活动是有关系的，页⾯若和api没有⼀点绑定联系的话，服务端接⼝调⽤的时候则要么拦截掉所有指定的接⼝（页⾯和api接⼝没绑定的话，则页⾯的接⼝调⽤都不能成功），服务端接⼝完全不拦截接⼝，也会不安全，但是api接⼝和页⾯功能在表结构层⾯的绑定会产⽣运维的⼤量⼯作成本，如何更好的设计。
·（2）答：在权限如何划分中已经提过了这⼀点，在表结构中，我们可以增加⼀张业务模块表和操作表（也可以在数据字典表中增加这两类数据），我们可以在页⾯和功能点钟 绑定业务模块和操作表关系，在api接⼝的代码层⾯去绑定业务模块和操作，在逻辑上绑定关系，解耦表结构之间的关系，那么可以在⼀定程度上解决这⼀点，这样做只会出现⼀种问题，那就是⽤户访问页⾯的时候可调⽤的api接⼝会⽐实际可调⽤的接⼝数要多，但是前端权限管理会隐藏功能点，这样就在可视化的程度上解决了这个问题。
5.安全框架
由于我们是基于RBAC的权限设计，现⾏java框架下最常见的就是shiro和Spring Security 。这两个就是仁者见仁智者见智了，我两者都实⽤过。仅建议使⽤shiro的话，可以更好的理解RBAC的设计思路，Sp
ring Security 也是个不错的框架，但是它涉及到的概念太多，并不利于初学者去了解最基本的权限设计。我在这只在学习的⾓度上去⽐较这两个框架，并没有再其他领域去做⽐较，也不去⽐较。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。