本文已收录在Github仓库，其中包括计算机基础、Java基础、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等核心知识点，欢迎star~Github地址：https://github.com/Tyson0314/...今天就和大家聊聊常见的方案权限系统设计。1、为什么需要权限管理？日常工作中的权限问题一直伴随着我们。新加入公司的程序员需要找人开通各种权限，比如网络连接权限、代码下载提交权限、监控平台登录权限等。,运营平台查数据的权限等等。很多时候，我们觉得这么多繁杂的申请给我们的工作带来了不便，突然要查一些数据，发现自己没有申请权限，我们需要重新走审批流程，时间会很长。那为什么需要这么严格的权限管理呢？比如支付公司有运营后台，运营后台可以查到所有的商户信息、法人代表信息、交易信息和费率配置信息。如果我们把这些信息不加筛选的给公司的每一个小伙伴，那么任何一个经营市场的人都可以操纵商家的费率信息。如果一不小心更改了汇率，将会造成巨大的损失。又比如，商家的信息非常保密，一些居心叵测的合作伙伴将这些信息拿出来卖给商家的竞争对手，会给商家造成严重的不良后果。虽然这样做是部分个人的人为失误，但如果信息本身不在系统中公开，就可以在很大程度上避免违法违纪的发生。一般来说，权限管理是公司数据安全的重要保障。不同的岗位和级别，看到的数据不同，对操作数据的限制也不同。比如资金相关的信息只对财务相关岗位开放，配置相关的信息只对运营相关岗位开放，这样各个部门及其职能就可以避免很多不必要的安全问题。如何让系统中各个岗位的人各司其职，是权限管理要解决的问题。2.权限模型2.1权限设计在业务分类上，权限可以分为数据查看权限、数据修改权限等，对应系统设计中的页面权限、菜单权限、按钮权限等。菜单也分为一级菜单、二级菜单，甚至还有三级菜单。以csdn文章编辑页面左侧菜单栏为例，有两级菜单。页面上有很多按钮对应菜单。设计的时候最好把权限设计成树状结构，这样在申请权限的时候，一眼就能看出菜单的结构，需要哪些权限就很清楚了。如下图：按照这个结构，按钮的父级是二级菜单，二级菜单的父级是一级菜单，这样用户就可以清楚的看到自己需要哪些权限申请权限的时候。2.2为什么要明确角色权限的结构？整理完权限后，我们就需要考虑如何给用户分配权限了。当用户较少时，可以直接分配。一个用户可以有多个权限，一个权限可以为多个用户所有。User-permission模型结构如下：该模型可以满足分配权限的基本能力，但是随着用户数量的增长，该模型的劣势也凸显出来。每个用户都需要分配权限，这对管理员来说是非常浪费的。时间和精力，用户和权限之间杂乱的对应关系会带来后期巨大的维护成本。用户-权限对应关系图：这种对应关系在用户多的时候基本无法维护。事实上，很多用户对同一个业务模块需要相同的权限。这样的话，我们是不是可以通过第三个媒介，给这个媒介赋予同样的权限，然后把用户和这个媒介关联起来，这个用户就会拥有媒体权限。这就是经典的RBAC模型，这里的媒介就是我们通常所说的角色。2.3权限模型的演进2.3.1RBAC模型有了角色，就可以为角色分配权限。需要相同权限的用户可以与角色相关联。一个权限可以分配给多个角色，一个角色可以有多个权限，同一个用户可以分配多个角色，一个角色也可以对应多个用户。对应的模型如下：这是经典的RBAC模型（role-based-access-control），其中roles起到桥梁作用，连接用户和权限之间的关系。每个角色可以拥有多个权限，可以为每个用户分配多个角色，让用户对多个角色拥有多个权限。同时，因为以角色为媒介，错综复杂的交互关系大大减少。比如在几万人的公司里，可能只需要几百个角色，因为很多用户都需要相同的权限。好的。该模型的对应关系图如下：用户和角色，角色和权限都是多对多的关系。这种模式是最常见的权限管理模式，节省了大量的权限维护成本，但实际业务千变万化的权限管理模式也需要根据不同的业务模式进行适当的调整。例如，公司的内部组织结构是等级制的。级别越高，权限越大，因为级别高的人不仅拥有下属的权限，第二阶段还拥有一些额外的权限。RBAC模型可以为不同级别的人分配不同的角色，级别越高对应的角色拥有的权限越多。这种处理方式可以解决问题，但是有没有更好的解决办法呢？答案肯定是肯定的，这就引出了角色继承的RBAC模型。2.3.2RBAC角色继承模型RBAC角色继承模型也称为RBAC1模型。每个公司都有自己的组织结构。例如，公司的财务经理包括财务总监、财务主管和出纳。财务主管需要有但不限于出纳的权限。权限，这样的管理关系向下兼容模式需要使用角色继承的RBAC模型。角色继承的RBAC模型的思想是上层角色继承下层角色的所有权限，并且可以额外拥有其他权限。模型如下：从模型图中可以看出，下级角色拥有的权限属于上级角色，上级角色可以拥有其他权限。角色的层次关系可以分为两种类型。一是一个下级角色只能有一个上级角色，而一个上级角色可以有多个下级角色。这种结构被形象地表示为一个树形结构，如下图所示：存在一个下级角色可以有多个上级角色，一个上级角色也可以有多个下级角色的关系。这种结构在图形上表示为有向无环图，如下图所示：树状图是我们常用的，因为一个用户一般不会同时有多个直属上级。比如财务部只能有一个财务总监，但是可以有多个财务总监和出纳。2.3.3带约束的RBAC模型带约束的RBAC模型也称为RBAC2模型。在实际工作中，出于安全考虑，约束条件较多。例如，财务部门的同一个人不能同时是会计师和审计师。一个人不能同时是运动员和裁判员，这是情理之中的事。财务部门的审计人员不能超过2人，不能有1人，也不能没有。因为角色和权限是关联的，所以我们可以做好角色约束。常见的约束包括：角色互斥、基数约束、先决条件约束等互斥角色：如果角色A和角色B互斥，那么一个用户不能同时拥有角色A和角色B，只能拥有其中一个他们。例如，如果我们将会计角色分配给用户，则不能同时分配审计员角色。如果我们要有审计师的角色，我们必须先去掉会计师的角色。假设投稿角色和审稿角色互质，我们可以用一个图形表示：基数约束：可以限制分配给同一个角色的用户数量，比如规定只有一个用户拥有超级管理员角色；用户分配的角色数量也需要限制，分配给一个角色的权限数量也可以限制。先决条件约束：如果一个用户想要被赋予一个上级角色，他必须首先拥有一个下级角色。例如，技术总监的角色和普通技术人员的角色是上下级关系，那么用户想要用户技术主管的角色，就必须首先具备普通技术人员的性格。2.4用户划分2.4.1用户组我们创建角色是为了解决用户数量大时用户分配权限繁琐，用户权限关系维护成本高的问题。抽象一个角色，把需要一起操作的权限分配给这个角色，再把角色分配给用户，用户就会拥有角色的权限，避免了一个一个给用户分配权限，节省了大量的资源.同样，如果一组用户需要同一个角色，我们也需要为用户一个一个分配角色。比如某公司客服部有500多人。有一天，研发部开发了一套查询后台数据的产品。合作伙伴需要使用，但是客服之前并没有给所有的客服合作伙伴一个统一的角色。这时候就需要添加一个新的角色，给这个角色分配权限，然后给客服人员一个一个分配角色。有时候你会发现给500个用户一个一个添加角色很麻烦。但是客服人员有共同的属性，所以我们可以创建一个用户组，所有的客服人员都属于客服用户组，给客服用户组分配角色，这个用户组下的所有用户都有需要的权限。RBAC模型中加入用户组后的模型图如下：很多朋友会问，用户组和角色有什么区别？简单的说，用户组是一组用户的组合，角色是用户和权限之间的桥梁。用户组将具有相同属性的用户组合在一起。比如同一个项目的开发、产品、测试可以是一个用户组。同一部门同一职位的员工可以是一个用户组。一个用户组可以是一个职级，可以是一个部门，可以是不同岗位一起工作的人。用户可以分组，权限也可以分组。当权限过多时，可以将一个模块的权限组合成一个权限组。权限组也解决了权限和角色对应关系复杂的问题。比如我们定义权限的时候，一级菜单、二级菜单、按钮都可以是权限。一级菜单下有几十个二级菜单，每个二级菜单下有几十个按钮。这时候，我们把权限一个一个分配给角色也是很麻烦的。可以使用分组的方式对权限进行分组，然后将划分好的分组分配给角色。分组权限也是一项技术任务。有必要弄清楚权限之间的关系。比如在支付操作后台，我们需要查询各种信息，比如账户数据，订单数据，商户数据等，这些查询数据不在A页面，每个页面也有很多按钮，我们可以将这些组合起来页面和按钮对应的权限划分为一个权限组并分配角色。添加权限组后的RBAC模型如下：在实际工作中，我们很少对权限进行分组，更多的是对用户进行分组的场景。有时用户组也可以直接关联权限。这个要看实际业务场景是否需要，没有统一的权限模型，业务越复杂，业务模型就会越多样化。2.4.2组织结构每个公司都有自己的组织结构，很多时候可以根据组织结构划分权限分配。因为同一个组织的小伙伴使用的权限大部分都是一样的。某公司的组织结构图如下所示：按照这种组织结构，各个组织的成员所使用的基本权限很可能是相同的。比如人力资源需要看人才招聘的相关信息，营销需要看行业分析的相关信息，按照组织分配角色会有很多好处：实现权限分配的自动化：打通关系后与组织，根据组织分配角色。如果有新用户，归入某个组织后，自动获取该组织下的所有权限，无需手动分配。又如，用户转岗，只需要调整组织关系，权限会根据组织关系自动调整，无需人工干预。为此，首先需要打通权限与组织的关系。控制数据权限：将角色与组织关联，组织内的成员只能看到组织下的数据，比如营销和客户定制，营销是针对分散的客户，定制是针对一定数量的客户，虽然相互数据在同一个平台，只能看到自己组织下的数据。加入组织后的RBAC模型如下：用户可以在多个组织中，因为组织也有层级结构，一个组织中只能有多个用户，所以用户和组织之间是多对的关系许多关系，组织和角色之间的关系是一对一的关系。对应关系可根据工作中的实际情况确定。2.4.3职位一个组织下有很多职位，比如财务管理，就有财务总监、财务主管、会计、出纳等职位。由于一个人的职位是固定的，用户和职位的对应关系是一对一的关系，而职位和角色的对应关系可以是多对多的关系。加仓的RBAC模型如下：2.5理想的RBAC模型RBAC模型会根据不同业务场景的需要，演化出多种方式。实际工作中，业务很复杂，权限分配也很复杂。如果你想做一个通用的和高效的模型是困难的。总结RBAC模型的演进将是一个支持海量数据和复杂业务的理想模型。结合RBAC、RBAC1、RBAC2、用户组、组织、职位的模型如下：按照这个模型基本上可以解决所有的权限问题，根据实际业务情况确定对应关系。一般来说，组织和职位之间是一对多的关系。特殊情况下可以多对多，需要根据实际情况确定。理想的RBAC模型并不是说我们在建立权限模型之初就可以做到这一点，而是说在数据量和业务复杂度达到一定程度之后，我们可以用这个模型来解决权限问题。如果数据量特别少，比如刚成立的公司只有十几个人，那么可以使用用户权限模型，没必要使用RBAC模型。3.权限系统表设计3.1标准RBAC模型表设计标准RBAC模型表比较简单。表达用户-角色-权限的关系，首先创建用户表、角色表、权限表，用户和角色是多对多的关系，角色和权限是多对多的关系。需要再创建两章关系表，分别是用户-角色关系表和角色-权限关系表。这六张表的ER图如下：3.2理想的RBAC模型表设计理想的RBAC模型是通过标准RBAC模型的多次扩展得到的，表结构会比较复杂，因为需要维护很多关系，如图下图中理想RBAC模型的ER图：这里需要强调的是角色互斥表。互斥关系可以放在角色上，也可以放在权限上，视实际工作需要而定。4.结语本文从易到难详细介绍了权限模型的设计。工作中需要根据实际情况定义模型。RBAC模型对于1000人以下的公司是完全够用的。无需设计权限模型。太复杂。模式的选择要根据具体情况，比如公司规模、业务类型、人员数量等，总之，最适合自己公司的模式就是最好的模式。权限模式与设计模式相同。都是为了更好的解决问题。不要为了使用模型而使用模型。最后给大家分享一个Github仓库，里面有大斌编译的300多本经典计算机书籍PDF，包括C语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构还有算法，机器学习，编程生活等等，可以star一下，下次找书的时候可以直接在上面搜索，仓库持续更新中~Github地址：https://github.com/泰森0314/…
