随着互联网的快速发展，B端行业也逐渐兴起。 很多企业管理中使用的软件通常被称为B端管理系统。 在B端系统中，“权限管理”是必不可少的功能。 不同系统中权限的应用复杂度不同，根据实际产品和需求设置合理的权限。
设计前先了解现有情况。
说到权限控制的设计，我们首先需要明确定义和原则。 权限的本质是什么？ 事实上，它就是：用户和可以执行的操作之间的关系。
这句话有三个关键词：用户、行为、关系。
参考RBAC模型并结合这些年的工作经验，我觉得页面权限、操作权限和数据权限的管理可以通过以下方法来实现。 我把这种方法称为：“三位一体法”。换句话说，三位一体：用户+行为+关系=用户权限
出现以下问题：
关于用户
关于行为
行为之间是否存在层次结构和依赖关系？ 它们是什么样的依赖关系？
关于关系
这是概念层面的问题。 到了工作设计的时候，梳理一下需求，会有一定的帮助。 主要是用来梳理基本概念的。
简而言之，权限系统维护了人与人之间的关系以及他们可以执行的操作。
常见的访问控制模型
权威这个词从字面上可以分为权力+限制。 从使用者的角度来看，就是在限制范围内正确行使权力。 从设计者的角度来看，就是采用合理的手段。 控制用户对其可以访问的资源的访问。
在权限设计领域，最常见的权限模型如下：
DAC模型，由于用户可以自主将自己的权限授予其他用户，因此DAC模型可以任意转让权限，用户可以间接获得自己不具备的访问权限。 因此DAC模型的安全性较低，无法给予系统足够的安全性。 数据保护。
MAC模型非常适合机密机构或其他层次观念较强的行业，但对于类似的商业服务系统则不太适用，因为它不够灵活。
ACL模型，可以将权限直接授予用户，例如将查看订单列表（权限）授予操作员（用户）。 但这种模式的缺点是，当用户数量达到一定程度时，每个用户都需要授权一次，工作量会相当大。 具体来说，为每个用户维护单独的权限列表。 当需要分配或撤销权限时，需要修改对应用户的权限信息。
因此，RBAC模型应运而生，它是软件设计中最常用的权限管理模型。 与ACL模型相比，RBAC模型在用户和权限之间多了一个元素“角色”。 权限与角色关联，角色与用户关联。 间接授予用户权限的方法，从而实现用户与权限的解耦。
与RBAC相比，ABAC模型非常灵活，但实现起来比较困难。
与常见的通过某种方式将用户与权限关联起来的方式不同，ABAC通过动态计算一个属性或一组属性是否满足一定条件（可以写简单的逻辑）来进行授权判断。 属性一般分为四类：用户属性（如用户年龄）、环境属性（如当前时间）、操作属性（如阅读）和对象属性（如文章，也称为资源属性），所以理论上可以实现非常灵活的权限控制，满足几乎所有类型的需求。
例如规定：“允许所有班主任在上课时间自由进出学校”。 其中，“班主任”为用户的角色属性，“上课时间”为环境属性，“进出”为操作属性，“校门”为对象。 属性。
ABAC非常灵活，但实施起来也非常困难。 这涉及到逻辑的动态执行、数据的动态过滤等，更具体地说就是SQL语句的动态拼接（如果使用ORM，就是动态组装ORM对应的查询语句）。
RBAC 的一个问题是它不是一个自动化过程，这意味着它需要手动管理。 本质上，角色是与授权对象的静态连接，因此需要进行的任何更改（添加、删除和更新用户的访问权限）都必须由 IT 经理完成。 跟踪谁应该有权访问哪些资源是一个复杂且令人困惑的过程。 因此，当用户请求新权限时，IT 经理必须进行检查以确保允许该用户访问。 危险在于，只要涉及到“人为因素”，就很容易出现错误。
PBAC 的指导原则是设置策略、用户配置文件和环境条件必须满足允许访问的标准。 由于 PBAC 支持运行时授权，因此它是动态的并且能够允许实时进行更改。 无需维护不断变化的用户角色存储库，无需在特定组中添加或删除单个用户，也无需随着公司内员工状态和职责的变化而不断维护对资源的授权。 由于 PBAC 是一个自动化过程，因此减少了与手动干预相关的风险。 但无法直观地看到用户和资源之间的访问关系，需要实时计算。 许多规则会导致性能问题。
访问控制策略定义优缺点示例
RBAC
根据角色确定访问权限，用户可以绑定不同的角色。
管理更灵活，目前主流模式
角色是到授权对象的静态连接，
角色是手动配置的
管理员角色、编辑角色和读者角色具有不同的权限。 添加新用户只需设置相应的角色，无需依次设置每个操作的权限。
数模转换器
访问权限由资源所有者、某些组的成员决定
可基于数据/资源独立控制权限
控制相对分散系统角色权限管理设计，管理难度大
文章的发布者指定哪些其他用户可以对该文章执行哪些操作
苹果
为信息添加敏感度标签，并与用户的敏感度标签进行比较，判断是否可以访问。标签由管理员设置
适用于军事相关系统等安全要求较高的系统
不够灵活
资源A有敏感标签B，用户C有敏感标签D。如果D不小于B，则B可以访问A。
ABAC/PBAC
根据用户属性和资源属性动态计算访问权限
动态管理，支持不同粒度的权限控制
无法直观地看到用户和资源之间的访问关系。 需要实时计算。 太多的规则会导致性能问题。
满足条件A的用户可以对满足条件B的资源执行操作C。
一般来说，现代系统的权限设置基本上都是基于RBAC权限模型并进行扩展的。 下面我将介绍RBAC权限模型的概念，并根据实际业务情况列举权限设置的应用。
什么是 RBAC 权限模型？
RBAC是英文Role-BasedAccess Control的缩写，意思是基于角色的访问控制。 RBAC认为权限授权实际上是一个Who、What、How的问题。 在RBAC模型中，who、what、how构成了访问权限三元组，即Who对What进行How操作，这也是“主体”对“客体”的操作。 其中，权限的所有者或主体是谁（例如：User、Role），资源或对象是什么（Resource、Class）。
简单理解概念就是给用户赋予“角色”的概念，在系统中通过角色将用户和权限关联起来。 这样就可以实现灵活的配置。
RBAC实际上是一个分析模型，主要分为：基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。
RBAC权限模型是基于角色的权限控制。 模型中有几个关键术语：
1.RBAC0
RBAC0是RBAC权限模型的核心思想。 RBAC1、RBAC2和RBAC3都是在RBAC0上扩展的。
RBAC0由四部分组成：用户、角色、会话、权限。
用户和角色之间是多对多关系，用户和会话之间是一对一关系，会话和角色之间是一对多关系，角色和权限之间是多对多关系。
2.RBAC1
RBAC1是在RBAC0权限模型的基础上，在角色中增加了继承的概念。 加入继承概念后，角色就会有上下级或者等级关系。
例如：群组权责列表包含的角色为：系统管理员、总部权责管理员、区域权责管理员、普通用户。 当管理方式向后兼容时，可以利用RBAC1的继承关系来实现权限。 设置。
上级角色拥有所有下级角色的权限，上级角色可以拥有额外的权限
3.RBAC2
RBAC2在RBAC0权限模型的基础上，增加了用户和角色、会话和角色之间的约束（职责分离）的概念。 职责分离是指同一个人不能拥有两个特定的权限（例如财务部门的权限）。 纳入和支出，或球员和裁判员等）。
用户和角色约束有以下形式：
会话和角色之间的约束可以动态地约束用户所拥有的角色。 例如，一个用户可以拥有两个角色，但在运行时只能激活一个角色。
例如：在下面的系统中，用户和角色采用了约束的概念。 只允许一名超级管理员。
4.RBAC3
RBAC3是RBAC1和RBAC2的集合，因此RBAC3包括继承和约束。
为什么要引用RBAC权限模型？
RBAC 有角色的概念。 如果没有角色的概念，那么在系统中，每个用户都需要单独设置权限。 系统涉及的功能权限和数据权限较多，每个用户需要单独设置权限。 维护权限对于管理员来说无疑是一项繁琐、工作量大的工作。
引入角色的概念后，我们只需要在系统中设置不同的角色，为角色授予权限，然后将用户与角色关联起来，这样与用户关联的角色就直接拥有该角色下的所有权限。
例如：用户1~用户8分别拥有以下权限。 我用不同的颜色来区分相同权限的不同用户，如下图：
在不引入RBAC权限模型的情况下，用户和权限的关系图可以如下图所示。 每个用户分别设置相应的权限。 即使具有相同权限的用户也需要多次设置权限。
介绍了RBAC权限模型和角色的概念。 根据上表统计创作人，用户1、用户3、用户5、用户8拥有相同的权限。 用户2、用户6、用户7具有相同的权限。 用户4是独立的。 权限，所以这里我们可以根据数据统计和实际需求创建三个不同的角色，角色A、角色B、角色C。这三个角色对应三组用户的不同权限，如下图所示。 :
相应的，我们可以将上面的案例表调整为包含角色列的数据表，这样我们就可以清楚地知道每个用户对应的角色和权限。
通过引用RBAC权限模型，可以更好地建立和管理系统中大量用户的权限设置。 角色的引入可以让具有相同权限的用户统一关联到同一个角色，这样角色在系统中只需要设置一次。 权限，后续用户可以直接与这些角色关联，从而无需重复设置权限。 对于大型平台上的应用程序，用户数量达到数万，因此可以避免设置权限的工作。 浪费很多时间。
RBAC权限模型的优点
（1）将抽象权限具体化，让您在分配权限时不再考虑抽象问题。
例如：新入职的初级销售人员小张要求管理员开户。 管理员无需担心是否授予小张“查看部门销售”的权限。 他只需要将小张的账号指向“初级销售”的角色即可。 ，这个角色有什么样的权限已经定义好了。
(2)批量调整权限
例如：有时公司推出新的业务模块时，管理员需要授权某个属性的用户查看该模块的数据。 例如，如果公司推出新的直播功能，运营团队需要能够运营直播后端。 此时管理员只需要修改“操作”角色的权限即可修改所有操作组成员的账户权限。
引入用户组的概念
我们仍然以上表案例为例。 虽然我们前面应用了RBAC权限模型的概念，但是对于大量具有相同权限的用户，我们还需要为每个用户设置相应的角色。 如果一个部门有几万人，那么我们需要为这个部门的几万人设置角色，而这几万人实际上拥有相同的权限。 如果我们直接采用基本的RBAC权限模型，那么面对这样的情况，无疑会有巨大的重复工作量，并且不利于后期用户变更的维护和管理，那么对于相同用户拥有相同权限的情况权限方面，我们可以引入用户组的概念。
什么是用户组？ 用户组：对具有相同角色的用户进行分类。
在我们上面的数据表案例中，用户1、用户3、用户5和用户8具有相同的角色A，用户2、用户6和用户7也具有相同的角色B。那么我们可以将这些用户与相同的角色。 用户建立用户组关系。 以上述案例为例，我们为相同角色的用户建立群组关系，如下：
由于用户4只有一个用户，因此可以直接建立用户和角色的关系，而无需建立用户组。 即使只有一个用户，也可以建立用户组关系。 这将有助于其他用户将来拥有与用户 4 相同的角色。 ，您可以直接将其他用户添加到该用户组中，并根据实际业务情况选择合适的解决方案。
通过案例表单的变化，我们可以直观地看到权限设置变得清晰简洁。 **给用户组分配角色可以减少很多重复性工作。 **我们常见的企业组织和部门往往有不同的用户具有相同的角色，所以使用用户组可以很好的解决这个问题。 为具有相同权限的用户创建用户组，并将用户组与相应的角色关联起来。 这个用户组就会拥有这个角色下的所有权限，而用户又属于这个用户组，所以该用户组下的所有用户也都拥有这个角色下的所有权限。 一个用户可以属于多个用户组，一个用户组也可以包含多个用户，因此用户和用户组之间存在多对多的关系。
引入权限组的概念
权限组的原理与用户组类似。 他们与一些相对固定的功能或权限建立组关系，然后将角色分配给这个权限组。 目前我接触到的B端项目使用权限组概念的还是比较少的。 简单看一下关系图就可以了
权限组，父菜单类似子菜单
功能权限和数据权限
B端系统中一般产品的权限由页面、操作和数据组成。 页面和操作是相互关联的。 您必须拥有页面权限才能在页面下分配相应的操作权限。 可以对数据进行添加、删除、修改、检查。 因此，权限管理分为功能权限管理和数据权限管理。
功能权限管理：指用户可以看到哪些模块、可以操作哪些按钮，因为企业中的用户有不同的角色，有不同的职责。
数据权限管理：指用户可以看到哪些模块的哪些数据。
例如：一个系统包含多个职责列表（列表1、列表2和列表3）。 系统管理员可以对整个系统进行操作和维护，还可以对系统中的所有列表进行操作（添加、删除、修改等）。 查看）; 如果总部权限管理员被分配到列表1，则他只能对列表1进行操作（添加、修改、查看）； 普通用户可能只有查看数据的权限，而没有对数据维度进行操作（查看）的权限，这里的操作都是系统中可点击按钮的权限操作，所列的增删改查只是其中的操作。最常见的操作。
实际案例总结
整个权限系统设计就是定义各个节点以及节点之间关系的过程。
节点包括：
用户;
用户组；
角色;
角色组；
权限（页面、操作、数据）；
权限组（页面、操作、数据）；
关系包括：
是/否关系；
继承关系；
限制关系（互斥、范围限制、边界限制、领域限制……）；
……
理清所有逻辑后，通过灵活定义节点，结合节点之间的关系，就可以轻松完成角色权限设计的多种方案。
我目前做的项目是一个权责管理平台的B端系统。 我简单介绍一下系统中的权限需求，并利用上面总结的RBAC权限模型来设计和分析实际的业务需求：
不同的区域管理员有不同的权限（也就是说会有不同的用户有不同的权限，那么我们可以用角色来规范他们）。 存在大量具有相同权限的用户（如组织、部门等）（说明如果存在具有相同权限的用户，那么我们可以使用用户组的概念）上级管理员拥有所有的权限下属人员的权限（表示存在继承关系） 不同用户看到的数据和可以编辑的数据不同，一些机密数据只允许部分人查看或编辑（表示有限制）。 会有临时用户（表示需要支持新角色）。 同一用户会有多个角色（需要组合多个角色或切换用户角色）。
RBAC权限模型由三部分组成，即用户管理、角色管理、权限管理。
用户管理按照企业架构或者业务线架构来划分。 这些结构本身都比较清晰，具有非常好的扩展性和可读性。
角色管理必须在深入理解业务逻辑之后进行设计。 一般以各部门的真实角色为基础，然后根据业务逻辑进行扩展。
权限管理是前两种管理的强化。 太详细了，就太碎片化了，太粗糙了，又不够安全。 这里我们需要根据经验和实际情况来设计。
表结构
有了上面的权限模型，表结构的设计就不难了。 以下是多系统下的表结构。 在一个简单的设计中，提供了主要思想：
Java中常用的权限框架 1.用户管理
用户管理中的用户是企业中的每一位员工。 他们有自己的组织结构。 我们可以直接以企业部门架构或者业务线架构为线索来构建用户管理系统。
2. 角色管理
在设计系统角色时，我们应该深入了解公司架构和业务架构，然后根据需要设计角色以及角色内的层级。
一般来说，角色相对于用户来说是固定的。 每个角色都有自己明确的权限和限制。 这些权限是在系统设计时就确定的，以后不会轻易更改。
(1)自动获取基本字符
当员工加入某个部门时，该员工的账号应该自动添加到该部门对应的基础角色中，并拥有相应的基础权限。 这样做是为了保证系统安全，减少管理员大量的手动操作。 让新员工能够快速使用系统，提高工作效率。
(2) 临时角色及失效时间
公司的业务有时需要外部的支持。 他们不是公司的员工硬件设备，仅在一定时期内为公司提供支持。 此时我们需要设置临时角色来应对可能跨多个部门协作的临时员工。
如果公司安全级别较高，此类账户默认会有固定的过期时间。 一旦达到过期时间系统角色权限管理设计，需要再次审核后才能重新开放。 避免因流程不完善而导致临时账户被遗忘在系统中，造成安全风险。
(3)虚拟角色
部门角色中的级别可以授权同级别的员工拥有相同的权限。 但部分员工因工作原因需要使用超出角色级别的权限。 同一级别的不同员工需要使用不同的权限。 对于这种超越角色级别的合理权限授予，我们可以设置虚拟角色。 该虚拟角色整合了工作所需的所有权限，然后将其分配给特定员工。 这样，无需调整组织架构和相应角色，也能满足工作中特殊情况的权限要求。
(4)黑白名单3.权限管理
权限管理一般受到三个方面的限制。 页面/菜单权限、操作权限、数据权限。
(1)页面/菜单权限
对于没有权限操作的用户，直接隐藏相应的页面入口或菜单选项。 这种方法简单、快速、直接，对于一些对安全性不是很敏感的权限来说非常高效。
（二）操作权限
操作权限通常是指不同用户是否可以对同一组数据进行添加、删除、修改、查看等操作。 对于某些用户来说，它是只读浏览数据，而对于某些用户来说，它是可编辑数据。
(3) 数据权限
对于安全性要求较高的权限管理，仅从前端限制隐藏菜单和编辑按钮是不够的。 您还需要对数据接口施加限制。 如果用户试图通过非法手段编辑不属于其权限的数据，服务器将识别、记录并限制访问。
在实际开发中，需要设置用户只能查看哪些部门的数据。 这种情况一般称为数据权限。
例如，销售和财务数据非常敏感，因此需要控制数据权限。 对于基于集团的应用系统，更需要对各个公司的数据进行控制。
例如，如果您设置为仅查看您公司或部门的数据，则特殊领导可能需要跨部门的数据。 因此，程序无法硬编码领导者应该访问哪些数据。 需要控制后台权限和数据权限。
开发参考：
#%E6%95%B0%E6%8D%AE%E6%9D%83%E9%99%90%E4%BD%BF%E7%94%A8
#%E6%9D%83%E9%99%90%E6%B3%A8%E8%A7%A3
文章来源:https://blog.csdn.net/fly910905/article/details/121947510
