后台管理系统的权限设计该怎么做

Posted 2023-05-02

参考技术A 由于每次开发新项目都需要一个权限管理系统，为了解决重复开发让成本增加的问题，特此开发一套狼奔权限管理系统。 狼奔权限管理系统是一个项目的基础，也是复用性最高的模块，新项目可以基于此模块开发。 系统登录 提供了登陆狼奔权限管理系统的功能。 用户必须指定用户名。如果用户没有录入登陆用户名，则提示用户“请填写 用户名” 用户必须指定验证码。如果用户没有录入登陆验证码，则提示用户“验证码 错误！” 如果用户录入的用户名称或者密码不存在，提示用户“用户名或者密码出 错。” 用户密码需要使用“*”加密显示。 用户密码区分大小写。 如果用户录入的用户名 参考技术B 一个需要流转管理的系统，不论是给内部使用，还是合作伙伴用，都不可避免的遇到一个问题：如何应对不同流转过程的帐号及帐号对应的权限设计

如果我们把流程写死了，以应对一个甲方，一旦产品需要拓展市场化，各个部门和合作关系，则需要灵活配置，以便软件系统能够应付。

常用的帐号及权限，市面上都已形成规范化。

如订单系统、服务管理系统、SCM系统等往往在一个发起单后，经历不同的岗位（部门）进行流转，通过普通的方式往往很难满足：

手把手教你做系统权限设计，看完不要说还不会

参考技术A

权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制（Role-Based Access Control)

RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。

用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面向C端的用户,比如阿里云的用户。

角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。

有人会问了为什么用户不直接关联权限呢？在用户基数小的系统,比如20个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中，用户基数比较大,其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给100人甚至更多授权,工作量巨大。

这就引入了 "角色(Role)" 概念,一个角色可以与多个用户关联,管理员只需要把该角色赋予用户,那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。

权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限:

以上是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介绍这三种类型

此模型引入了角色继承(Hierarchical Role)概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

基于核心模型的基础上，进行了角色的约束控制，RBAC2模型中添加了责任分离关系。

其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

即最全面的权限管理,它是基于RBAC-0，将RBAC-1和RBAC-2进行了整合。

当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。

如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。

根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组:

每个公司都会涉及到到组织和职位,下面就重点介绍这两个。

我们可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。

组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。

每个组织部门下都会有多个职位，比如财务部有总监，会计，出纳等职位，虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。

总监拥有所有权限，会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。

根据以上场景,新的权限模型就可以设计出来了,如下图:

根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化

授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。

有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:

在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍。

权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。