用户权限管理：最常用的架构模型介绍

内容导航：

用户权限管理：最常用的架构模型介绍

权限管理之RBAC模型

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

用户权限设计

一、用户权限管理：最常用的架构模型介绍

本文由作者 Dennis_ 发布于社区

近期PMCAFF有好几个帖子都在问权限如何管理，给大家分享下吧。

1. 角色权限管理

说起用户权限管理，绕不开 RBAC模型，

直接上图：

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限（系统资源）进行关联

简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限（系统资源）”的授权模型。在这种模型中，用户与角色之间，角色与权限（系统资源）之间，一般是多对多的关系

我们可管理的权限（系统资源）分为功能权限、数据权限：

功能权限，管理API和页面元素的可控与否、可见与否

数据权限，管理数据表Key-Value的可控与否、可见与否

上述模型主要体现的是对系统资源的权限管理，接下来说说对人的复杂权限管理：

对人的权限管理需求往往是权限继承、权限隔离等，涉及：

公司体系结构（Company Architecture），例如集团公司的管理，涉及总部和子公司、股权往来公司、业务往来公司等

组织架构（Organization），例如部门和子部门、部门领导和员工等

域（Domain），例如中国域和欧洲域

多业态（Multiple formats），按照不同业态对角色进行分类，例如系统类角色、营销渠道类角色等

如何实现呢？（实现方式很多，这里仅简单举例）

在RBAC模型中引入用户组的概念，为用户赋予用户组，为用户组赋予角色，可考虑将用户组按需关联至公司体系结构层、组织架构层、域层

在RBAC模型中引入角色类型的概念，可考虑将其按需关联至多业态层

引入角色上下级继承等

RBAC模型是目前最常用的用户权限模型，但也有弊端，对权限管理粒度太细了，不一定所有业务场景都需要如此复杂的权限模型，酌情选用，也可以酌情调整模型

2. 功能权限的管理

前文说到，功能权限的管理，本质上是在管理系统资源，是在管理一个系统某个页面中的 API和页面元素，比方说一个按钮

我们有两种做法，

一种是写死，即页面下有哪些API和元素，前端工程师直接写死

一种是配置，即允许用户自行可视化的配置这些元素

如需配置，即可引入菜单管理

菜单用来干嘛？

于系统来说，菜单是我们用来管理系统资源（按钮、页面图片、API等）的载体，通过对菜单和依附菜单的系统资源做权限管控，可以实现细粒度的用户权限管理。因此，菜单管理本身属于RBAC权限管理的一部分

于用户来说，菜单最基础的作用是导航，通过菜单，用户可以快速了解系统的功能模块划分、层级结构，也可以快速切换

菜单管理如何实现？

直接上图：

菜单的管理：

菜单名称

菜单编码，即菜单的唯一标识

菜单图标

所属应用，即该菜单属于哪个系统

父级菜单，即配置多级菜单

菜单状态，即停启用

跳转方式，即站内跳转和站外跳转，影响跳转路径的配置

跳转路径，即菜单的URL

打开方式，即跳转后的页面打开方式，在当前页打开，还是新页面

菜单内资源的管理：

资源名称，即该资源的名称，例如「新增用户」

资源路径，即该资源的调用路径，例如「新增用户」的路径是Add User API的地址

资源类型，即API，或页面元素

页面元素，例如一个前端绿色小按钮静态图片

资源关联，例如配置了一个Add User API，又配置了一个绿色的新增用户按钮图片，将其关联起来

这样，我们就可以实现系统资源的可视化配置

3. 数据权限的管理

我们对于数据权限的管理需求，无非是某些数据某个人能看，而另一个不能看之类的。前文正好也讲到，实质上是在做数据表的Key-Value读写权限管理

这里就不上图了，

实现思路也不复杂，可考虑在角色引入

支持选择数据表

支持选择数据表下的Key

支持选择数据表下的Key的Value

支持选择只读、读写

前端页面的逻辑，不要忘记反选哦，很多时候我们的需求就是除了某某之外，其他都能看

↘好文推荐：

所有人问「贴吧之父」俞军

产品经理逻辑学通识

干货 | 产品经理要了解的技术类知识

👇欢迎关注：

一、权限管理之RBAC模型

在我们生活中，每个组织都会有一个组织架构，例如一个公司，它会有财务部、技术部、行政部、后勤部等。而这些部门，之所以这样划分，就是因为他们的职责不同，所负责的业务不同，本质就是他们行使的职能不同。如果模糊部门的概念，引入一个新概念——角色，赋予同一部门的人同一的角色，他们在这个角色下，会行使相同的职能，这样同一部门的人就拥有了相同的权限，以后这个部门在人事上的变动，其实就是在给这个角色增减用户。于是，就引入RBAC模型。

RBAC的核心分为：用户、角色、权限这三个模块，在产品中的实际流程如下图所示：

下面我们将结合以下问题来一起深入了解下RBAC模型

如上图所示，在创建角色时，我们会给这个角色分配相应的权限，这里的权限是有前提的，就是它是基于已开发的功能来进行的，如果一个功能还没有开发，那无法对它进行权限控制的。如下图所示为常见的添加角色操作：

可以，我们在创建角色时，可能会遇到不同的角色但有部分权限是相同的，这种情况是允许的

超级管理员，它是最大的权限，这个是必不可少的角色

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

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

迄今为止最为普及的权限设计模型是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模型是不变的,我们可以在其基础上进行扩展来满足需求。

三、用户权限设计

基于角色的访问控制模型就是把“用户—角色—操作—资源”关联到一起，实现非自主型访问控制策略。使用基于角色的访问控制模型可以减轻安全管理工作，因为某种任务是稳定的，而负责该项任务的人员是经常变化的，这种方式只需把新的用户分配给已有的角色即可，无需为用户重新指定资源和操作，因而简化了授权管理工作。

为了保障本系统操作使用的信息安全，系统登录认证体系由三个要素组成:用户、角色、权限，三者相辅相成，共同组成系统的安全运行屏障。

1.用户信息

用户信息表统一管理，在用户信息表中存储用户名称、登录名、口令、各子系统权限、用户角色信息等。

用户信息表的添加、删除以及子系统权限修改由总系统授权的管理员执行，本系统中，用户信息表的操作在业务处理与信息服务子系统的系统管理菜单下的用户信息管理页面。用户口令可以自行改变，用户权限的变更需要提请管理员同意，并由管理员修改。

子系统启动时读取用户信息表验证用户权限，在系统运行时依据权限分配相应的功能。依据用户在子系统中的权限级别控制用户可操作的功能，实现最终用户对ORACLE数据库中数据的读取和添加操作权限控制(表8－2)。

表8－2 用户信息结构表

2.角色信息

角色可以根据需要任意多地添加，多个角色权限组合生成多个权限控制，对应到一个确定的用户，赋予用户对功能模块的控制权限。用户角色表包括角色名称、用户唯一值编码等信息。示例见表8－3。

表8－3 用户角色表(示例)

在数据库中为各个功能模块建立了功能名称表，每个功能模块均有记录，有功能编码和功能名称及其他附属信息。功能名称示例见表8－4。

表8－4 功能名称表(示例)

每个用户必须属于至少一个角色，每个角色具备多个功能的控制权限，功能权限通过角色传递给用户，从而实现用户对功能的操作权限控制。

3.权限信息

权限表明了用户可执行的操作。系统权限控制采用最大优先，用户可以拥有多个角色，每个角色对每一页面都可拥有权限，但在权限结果判断时只以最大权限为主，即管理员级权限大于并包含访问者权限。功能权限示例如表8－5所示。

表8－5 功能权限表(示例)

系统规划的子系统权限等级见表8－6。

表8－6 子系统权限等级规划表(部分)

续表

4.用户认证授权

通过以上四个表将用户、角色与权限组合起来，可以形成无穷多的用户权限组合，直接控制用户权限到每个细分功能。

用户、角色、权限、功能控制流程如图8－1所示:

图8－1 用户权限控制流程图

功能权限表仅在部署角色权限时使用，标示功能具备的可部署权限。

在角色中必须保证有一个管理角色拥有用户管理功能的管理权限，防止不能分配角色与权限，同样在用户中必须保证至少有一个用户是管理角色。