权限设计的杂谈
这篇文章的定位并不是宣传某个框架，只是梳理一下关于权限的一些想法和最近项目中的一些探索过程。 我们主要想解决问题。什么是权限，程序员理解的权限和客户理解的权限是否一致？ 权限划分原则是根据什么原则组合的？ 角色是用户和权限之间的必要关系吗？ 角色到底承担了什么样的角色？ 如何进行合理的表格设计？ 安全框架。 1 .什么是权限
虽然在与许多开发者和顾客的交流过程中多次提到了权限，但权限的具体含义谁都不清楚，容易导致双方信息的不对称，有人只理解可否访问一个页面，也有人理解为另一个所以，我们必须彻底定义什么是权限。
权限是名词属性还是动词属性，是否包含在名词、动词属性中，对于权限的意义来说很重要。 如果是名词的属性，应该有具体的指示物； 如果是动词的话，应该有行为表示。
访问权限的名词属性： api接口、页面、功能点。 权限的动词属性：可操作，不可操作。 那么，现在看看吧。 其实权限是名词、动词的属性，它一定表达了两个意思。 也就是说，控制的对象、操作。
例如，权限a表示对页面a的访问。 例如，权限b表示页面b可以访问，而页面中的功能b不可用。 例如，权限c表示不调用接口c。 例如，权限d表示页面d可以访问，而接口d可以访问。 进一步说明，权限可以表示单一的受控操作的集合，也可以表示多个受控操作的集合。 这两者的取舍由设计者决定。
一句话概括权限的含义，what (几个要素)进行how )
2 .权限的划分原则
我们了解权限的具体含义后，接下来是使用问题，我们应该如何使用权限，如何组合系统内的操作要素，这将参考网上的某篇文章进行说明。 划分原则可以遵循“最小特权原则”和“数据抽象原则”。
最小特权原则列举反例。 将系统中的所有要素和操作合并为一个权限。 如果一个用户有这个权限，他就会拥有系统的所有功能。 实际上，这绝对不行。 用户在一系列的系统中一定有他不允许操作的内容，也有超级管理员也不能操作的要素。 那么，权限无法最大化。 因为不符合常识。 这样，再分割一个权限，按业务模块进行分割，但这实际上也是不可能的。 例如，在系统的财务模块中，如果假设模块包含报销页和申报页，则按模块进行分割时，一定会有同时包含两个互斥功能的用户。 根据1和2，必须按最小化划分权限。 但是，这也是有争议的。 因为根据系统的不同，最小的权限划分对提供的功能而言，划分的角度不同。 数据抽象原则“最小特权分类”在一定程度上决定控制的对象，而数据抽象原则则是决定操作。 数据的抽象化实际上很难理解实际上是什么意思。 通常，我们口头上最多的是CRUD的添加、删除、变更，这实际上是数据抽象的一种，可以理解为要素操作许可权的含义。 但是，CRUD并不是数据抽象的全部。 通过增加删除来更改为单个实体基本上没有问题，但在构建关系方面实际上还不够。 例如，免除某经理管辖某个部门，或从业务表面上修改经理的管辖范围。 但是，代码库的构建需要在经理和部门之间添加新的关系，因此需要根据需要添加许可权“免除许可”的类型。 这种类型的扩展必须根据系统的实际业务情况进行分类。 “最小特权”和“数据抽象”分别决定了权限中控制的对象和操作，但其中缺少另一个角度的是现阶段非常普遍的前后端分离的权限划分问题。
服务端权限前后分离的服务端，本质上只是提供接口、rpc服务等其他资源服务的服务商。 服务器端可以提供的权限认证机制对象：接口服务(api或其他形式的服务)不包括前端页面或页面中的功能点。 前端或移动端页面元素的控制和验证实质上不受服务器端的控制。 服务器端可以单独控制服务的权限。 服务端的服务对象是前端、移动端、第三方端，提供的服务是接口服务。 如果前端是分离的，服务器端对前端来说是接口的提供者，但无权干涉前端页面的展示。 服务端可以提供对前端来说只有认证服务的接口，但页面的构成、页面的栏菜单和页面内功能点的构成由前端单独进行。
前端或移动端的权限前端验证包括页面的可访问性以及页面上的功能按钮是否可操作。 前端和移动端的服务对象是用户，提供的服务是可视化的网页。
如果明确前后服务对象的责任划分，就不会发生权限归属的问题。 如果之前和之后的服务对象没有分离，则页面本身就是服务器端的一部分，没有问题。 虽然明确了各端本质上提供的服务情况，但是前后端分离的权限划分存在新的问题。
由于服务端和前端的认证对象不一致，服务端只能认证到api接口，所以是否要将api接口和前端的页面或页面功能点与数据库表进行表级的绑定关系。 如果进行了表和表的绑定关系，则为整
个权限系统的维护量，是否能在能承受范围之内。如果不进行表与表之间的绑定关系，前端页面在操作功能的时候，服务端如何鉴权页面调用的api接口是否在用户可操作的权限之内？其实上面的问题则需要一个取舍，要么增加运维成本严格控制前端调用api接口的关系，偏重服务端的接口服务鉴权。要么是给api接口和前端页面及功能点再提供一个通性的逻辑判断处理，如：页面及调用的功能点属于某个业务模块的操作许可，而页面触发的接口也刚好是这个业务模块的操作许可，那么鉴权通过，否则鉴权失败。这种就是属于侧重前端对于用户的控制，弱化了接口级的控制。
3.角色与权限的关系
通过1，2的描述，基本确定了权限的定义和划分一个权限的通用法则。用户在系统中最终是通过权限来使用各种功能点，是否有必要在用户和权限中间再额外的附加一个关系。在我们现在的权限设计中，是增加了这样一层关系的，就是角色。
减少操作层面的重复性。角色其实就是一组权限的集合，是权限集合的更高级抽象，为了便于运维和实际管理，通过角色的赋予，替代了权限赋予用户的繁琐性，在一套系统中，普遍情况都是权限的数量多于角色的数量。权限是控制对象和操作集合，它本身不存在任何状态，但是在赋予在用户身上则拥有了状态，比如权限A中允许用户访问页面A，权限B允许用户访问页面B，权限D运行用户访问B页面，但是不允许访问A页面。那么这层关系的维护在角色层面的话，会更加清晰，也就是说本身角色具有权限集合组装的策略问题，对于互斥的权限有不同的方案处理。（权限中没有某个操作和权限中禁止某个操作，是两个不同的角度，不能混为一谈）因为权限的可能存在互斥性，在实际业务中也会引发角色的互斥性，举一个现实中的案例来解释互斥性：威武的河马是软件部的负责人但因为工作的特殊性也同样隶属于业务部的普通员工，我们设定负责人是可以要求人事部门给本部门进行招聘的，在实际的情况中，威武的河马能给软件部招聘新员工，但是不能给业务部招聘员工。我们把这个案例运用在系统中，威武的河马则是拥有负责人和普通员工两个角色，但是招聘的功能如果不加以控制，则会发生威武的河马给业务部招人的结果。于是为了解决角色的这类问题，引入了职责划分的方案。职责划分分为：静态、动态。所谓静态职责划分则是在角色创建之初就已经确定了角色的职责内容。动态职责划分是系统运行过程中对用户已有的角色进行控制，例如：某些角色不能共存在用户身上（互斥）、角色或角色的分配数量限定（控制用量）、角色与角色同时只能激活一个进行使用（时刻唯一）。引入角色的概念后，实际上这已经是一个比较完整的RBAC的权限设计的模型了。
4.数据表的设计思路
根据3的结论，实质上已经有了一个基础的表设计的雏形。在这里就有一些值得注意的点。
（1）问：权限表是否有必要存在？（1）答：这个要结合系统的实际使用场景进行考虑，如果系统中的权限的对象很单一，比如只有页面，或者只有api接口的话，其实权限表可有可无。增加权限表反而会导致初始化项目权限的工作量增加。但是若系统中的权限对象是多个，那么权限表的存在就有了更深层次的意义。在权限对象是多个的情况，权限表的存在就是为了更好更抽象的组合“最小特权”及“责任划分”的操作对象。同时，一旦系统中的操作对象增加了，只需要给权限表增加一个对象表和关系表就可以了。这样易于扩展。（2）问：api接口和页面实际上是没有关系的，但是在鉴权活动是有关系的，页面若和api没有一点绑定联系的话，服务端接口调用的时候则要么拦截掉所有指定的接口（页面和api接口没绑定的话，则页面的接口调用都不能成功），服务端接口完全不拦截接口，也会不安全，但是api接口和页面功能在表结构层面的绑定会产生运维的大量工作成本，如何更好的设计。（2）答：在权限如何划分中已经提过了这一点，在表结构中，我们可以增加一张业务模块表和操作表（也可以在数据字典表中增加这两类数据），我们可以在页面和功能点钟 绑定业务模块和操作表关系，在api接口的代码层面去绑定业务模块和操作，在逻辑上绑定关系，解耦表结构之间的关系，那么可以在一定程度上解决这一点，这样做只会出现一种问题，那就是用户访问页面的时候可调用的api接口会比实际可调用的接口数要多，但是前端权限管理会隐藏功能点，这样就在可视化的程度上解决了这个问题。5.安全框架
由于我们是基于RBAC的权限设计，现行java框架下最常见的就是shiro和Spring Security 。这两个就是仁者见仁智者见智了，我两者都实用过。仅建议使用shiro的话，可以更好的理解RBAC的设计思路，Spring Security 也是个不错的框架，但是它涉及到的概念太多，并不利于初学者去了解最基本的权限设计。我在这只在学习的角度上去比较这两个框架，并没有再其他领域去做比较，也不去比较。
引用的文章《权限系统与RBAC模型概述[绝对经典]》
本文由开源作者cross___原创，© 著作权归作者所有，如有侵权请联系删除，