当前位置： 数据库权限管理设计-权限设计 数据范围
原文链接：
这篇文章的定位不是推介某个框架，而是整理一下关于权限的一些想法，以及最近项目中的一些探索过程。 我们主要是想解决一个问题。
1、什么是权限，程序员理解的权限和客户理解的权限一致。
2.权限划分原则，权限依据什么原则？
3、角色是用户和权限之间的必然关系吗？ 角色具体是做什么的。
4.如何进行合理的表格设计。
5. 安全框架。
1.什么是权限
在与开发者和客户沟通的过程中，我们多次提到权限，但是权限的具体含义大家并不清楚，这很容易导致双方信息不对称。 有些人只是把权限理解为某个页面是否可以访问，但有些人把它理解为其他东西。 所以我们必须彻底定义什么是权限。
权限是名词属性还是动词属性，或者名词属性和动词属性都包含在内，这对于权限的含义非常重要。 如果它是一个名词属性，那么它应该有一个特定的所指对象； 如果它是一个动词，它应该有一个行为表示。
权限是名词属性还是动词属性，或者名词属性和动词属性都包含在内，这对于权限的含义非常重要。 如果它是一个名词属性，那么它应该有一个特定的所指对象； 如果它是一个动词，它应该有一个行为表示。
1、权限的名词属性：api接口、页面、功能点。
2、权限的动词属性：可操作和不可操作。
那么我们现在来看，其实权威是一个名词和一个动词的属性，它必须表达两个意思。 即控件的对象和操作。
1. 例如：权限A表示页面A可以访问。
2. 例如：权限B表示页面B可以访问，页面中的功能b不可用
3. 例如：权限C表示不能调用接口C。
4. 例如：权限D表示页面D可以访问，接口D可以访问。
那么进一步说明，权限可以表示单个受控对象的操作集，也可以表示多个受控对象的操作集。 两者之间的选择由设计师决定。
一句话概括了权限的含义：what（几个元素）performs how（几个操作）
二、权限划分原则
我们了解了权限的具体含义之后，接下来就是使用权限了。 如何使用权限，如何组合系统中的操作元素，我会用网上的一篇文章来解释。 划分的原则可以按照“最小权限原则”和“数据抽象原则”。
最小权限原则
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接口其实和页面没有关系，但是和认证activity有关。 如果页面与api没有绑定连接，调用服务端接口时会拦截所有指定的。 接口（如果页面和api接口没有绑定，页面的接口调用是不会成功的），服务端接口根本不拦截接口，会不安全，但是api接口的绑定和表结构级别的页面功能会造成操作维度的大量工作成本，如何设计更好。
(2)答：这一点在如何划分权限中已经提到。 在表结构中，我们可以添加一个业务模块表和一个操作表（或者将这两类数据添加到数据字典表中），我们可以在页面和功能点绑定业务模块和操作表的关系，绑定业务模块和操作在API接口的代码层面，逻辑上绑定关系，解耦表结构之间的关系，所以在一定程度上可以实现解决这一点，只会有一个问题，就是，当用户访问页面时，可以调用的api接口会比实际可以调用的接口数多，但是前端权限管理会隐藏功能点，这样在可视化上就解决了这个问题在某种程度上。
5. 安全框架
由于我们是基于RBAC设计权限，所以目前java框架下最常见的就是shiro和Spring Security。 这两个就是仁者见仁智者见智，我都用过。 如果只推荐使用shiro，更能理解RBAC的设计思想。 Spring Security也是一个不错的框架，但是涉及的概念太多，不利于初学者理解最基本的权限设计。 我只是从学习的角度比较这两个框架，其他领域我不比较，也不比较。
告诉大家一个好消息，我的知识星球上线了，欢迎大家加入。
推荐作品
●
●
●
●
●
●
●
●
●
上一篇 
