权限系统设计前言权限管理是所有后台系统的重要组成部分之一，主要目的是对不同人的访问资源进行权限控制，避免权限控制的缺失和操作错误带来的风险问题，如操作错误、隐私数据泄露等问题
现在在公司负责权限，所以对权限这个设计很熟悉。 当公司采用微服务架构时，权限系统自然是独立的。 其他业务系统包括商品中心、订单中心、用户中心、仓库系统、小程序、多个APP等十多个系统和终端
1 .权限模型迄今为止最流行的权限设计模型是RBAC模型(基于角色的访问控制(基于角色的访问控制) ) ) ) )。
1.1 RBAC0型号RBAC0型号为以下：
它是权限(包括用户/角色/权限)最基本、最核心的模型，用户与角色是多对多的关系，角色与权限也是多对多的关系。用户是发起操作的主体，按类型分为2B和2C用户，无论是后台管理系统的用户还是OA系统的内部员工，都是c端用户，例如Alibaba ccom角色充当了桥梁，与用户建立了权限关系。 每个角色可以具有多个相关联的权限，并且如果一个用户同时关联多个角色，则该用户将具有多个角色的多个权限。 为什么用户不直接关联权限呢？ 在基于用户的小系统(例如20个小系统)中，管理员可以直接将权限与用户相关联，工作量很小，只需对用户进行检查并选择所需的权限即可。 但是在实际的企业系统中，用户基数比较大，其中很多都有相同的权限。 普通的访问权限。 如果管理员授予100人以上的许可，工作量就会变大。 它引入了“角色”概念，可以将一个角色与多个用户相关联，管理员只需将该角色授予用户，然后将用户设计为具有该角色下的所有权限，从而大大提高了效率和可扩展性。权限是用户可以访问的资源，包括页面权限、操作权限和数据权限：
页面权限：是用户可以登录系统查看的页面，由菜单控制。 菜单包含一级菜单和二级菜单，如果用户具有一级菜单和二级菜单权限，则用户可以访问页面操作权限为：的页面上的功能按钮。 包括查看、添加、修改、删除、审核等，当用户单击删除按钮时，会在后台检查用户角色下的所有权限是否都包含该删除权限，如果是，则根据系统而定当页面上看到操作按钮时，用户可以操作。 要实现这个要求，前端在这里需要合作。 前端开发将缓存用户的权限信息，在页面上确定用户是否包含此权限，如果有，则显示该按钮，如果没有，则隐藏该按钮。 用户体验有所提高，但在实际场景中，您可以自行选择是否需要数据权限：的数据权限。 例如，财务部只能看到该部门下的用户数据，采购部只能看到采购部的数据，一些大公司在全国有很多城市和分公司，比如杭州的用户注册系统只能看到杭州的数据。 上海的用户只能看到上海的数据。 解决办法一般是将数据与具体的组织结构相关联。 举个例子，在给用户授权时，用户选择某个角色同时将财务部、合肥分公司等组织联系起来，拥有该角色下财务部、合肥分公司下的数据权限。 以上是RBAC的核心设计和模型分析，该模型也被称为RBAC0，基于核心概念，RBAC还提供扩展模式。 包括RBAC1、RBAC2和RBAC3机型。 下面介绍这三种类型
1.2 RBAC1机型
该模型引入了“角色继承”(Hierarchical Role )的概念，即角色具有上下关系，角色之间的继承关系可分为常规继承关系和有限继承关系。 在典型继承关系中，角色继承关系是绝对的偏差关系，角色之间必须能够进行多个继承。 在受限继承关系中，角色继承关系是树结构，这进一步要求在角色之间实现单一继承。 此设计可以对角色进行分组和分层，在一定程度上简化了权限管理工作。
1.3 RBAC2模型基于核心模型进行角色约束控制。 RBAC2模型中添加了责任隔离关系，该关系规定了向角色授予权限或向用户授予角色以及用户在某个时间激活角色时必须遵循的强制规则。 责任分离包括静态责任分离和动态责任分离。 主要包括以下限制：
互斥角色：同一用户最多只能分配给一组互斥角色中的一个角色，支持责任分离原则。 互斥角色是指各自权限相互制约的两个角色。 例如，财务部有会计和审计师两个角色，他们是互斥角色时，用户不能同时拥有这两个角色，职责分离原则基数约束：说明分配给一个角色的用户数量受到限制； 一个用户可以拥有的角色数量有限制； 与同一角色对应的访问权限的数量也受到限制，这是控制高级权限分配给系统的先决条件角色：也就是说，用户要获得高级角色，需要将RBAC1和RBAC2集成在一起的基于RBAC0的最全面的权限管理1.4 RBAC3模型
1.5用户群在平台用户基数增大、角色类型增加时，且部分人具有相同属性。 例如，财务部的所有员工如果直接为用户分配角色，管理员的工作量就会变大。 将具有相同属性的用户分类为用户组后，管理员可以直接将角色分配给用户组，用户组中的所有用户都可以拥有该角色，稍后其他用户加入用户组后，该用户组中的所有角色将自动分配给用户另外，用户
可以根据用户组是否有上下关系来划分
为有上下级的用户组和普通用户组: 具有上下级关系的用户组: 最典型的例子就是部门和职位,可能多数人没有把部门职位和用户组关联起来吧。当然用户组是可以拓展的,部门和职位常用于内部的管理系统,如果是面向C端的系统,比如淘宝网的商家,商家自身也有一套组织架构,比如采购部,销售部,客服部,后勤部等,有些人拥有客服权限,有些人拥有上架权限等等,所以用户组是可以拓展的 普通用户组: 即没有上下级关系,和组织架构,职位都没有关系,也就是说可以跨部门,跨职位,举个例子,某电商后台管理系统,有拼团活动管理角色,我们可以设置一个拼团用户组,该组可以包括研发部的后台开发人员,运营部的运营人员,采购部的人员等等。每个公司都会涉及到到组织和职位,下面就重点介绍这两个。
1.5.1 组织常见的组织架构如下图:
我们可以把组织与角色进行关联,用户加入组织后,就会自动获得该组织的全部角色,无须管理员手动授予,大大减少工作量,同时用户在调岗时,只需调整组织,角色即可批量调整。组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。
1.5.2 职位假设财务部的职位如下图:
每个组织部门下都会有多个职位,比如财务部有总监,会计,出纳等职位,虽然都在同一部门,但是每个职位的权限是不同的,职位高的拥有更多的权限。总监拥有所有权限,会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。
1.6 含有组织/职位/用户组的模型根据以上场景,新的权限模型就可以设计出来了,如下图:
根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化,
授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。
手动授权: 管理员登录权限中心为用户授权,根据在哪个页面授权分为两种方式:给用户添加角色,给角色添加用户。给用户添加角色就是在用户管理页面,点击某个用户去授予角色,可以一次为用户添加多个角色;给角色添加用户就是在角色管理页面,点击某个角色,选择多个用户,实现了给批量用户授予角色的目的。审批授权: 即用户申请某个职位角色,那么用户通过OA流程申请该角色,然后由上级审批,该用户即可拥有该角色,不需要系统管理员手动授予。 3.表结构有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:
4.权限框架 Apache ShrioSpring Security在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍.
5.结语权限系统可以说是整个系统中最基础,同时也可以很复杂的,在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就需要具体问题具体分析,但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。
最后,如果您觉得这篇文章对您有帮助,可以点个赞,谢谢支持!
转载于:https://www.cnblogs.com/iceblow/p/11121362.html