第3章-SaaS-HRM系统用户权限设计

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/pyycsd/article/details/103070567

学习目标： 理解RBAC模型的基本概念及设计思路 了解SAAS-HRM中权限控制的需求及表结构分析 完成组织机构的基本CRUD操作 完成用户管理的基本CRUD操作 完成角色管理的基本CRUD操作

1 RBAC模型

1.1 什么是RBAC

RBAC（全称：Role-Based Access Control）基于角色的权限访问控制，作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

访问控制是针对越权使用资源的防御措施，目的是为了限制访问主体（如用户等）对访问客体（如数据库资源等）的访问权限。企业环境中的访问控制策略大部分都采用基于角色的访问控制（RBAC）模型，是目前公认的解决大型企业的统一资源访问控制的有效方法

1.2 基于RBAC的设计思路

基于角色的访问控制基本原理是在用户和访问权限之间加入角色这一层，实现用户和权限的分离，用户只有通过激活角色才能获得访问权限。通过角色对权限分组，大大简化了用户权限分配表，间接地实现了对用户的分组，提高了权限的分配效率。且加入角色层后，访问控制机制更接近真实世界中的职业分配，便于权限管理。

11464886-2a139c8f7841dbba.png

在RBAC模型中，角色是系统根据管理中相对稳定的职权和责任来划分，每种角色可以完成一定的职能。用户通过饰演不同的角色获得角色所拥有的权限，一旦某个用户成为某角色的成员，则此用户可以完成该角色所具有的职能。通过将权限指定给角色而不是用户，在权限分派上提供了极大的灵活性和极细的权限指定粒度。

11464886-90fbacaa73cb1af0.png

RBAC权限设计

1.3 表结构分析

11464886-1da55336b0b0cb78.png

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

2 SAAS-HRM中的权限设计

2.1 需求分析

2.1.1 SaaS平台用户设计

一般SaaS平台基本角色由平台管理员、租户用户、租户管理员、租户其他角色组成。以O2O业务的企业架构为例，图解系统角色关系。

11464886-59cc2ccc11ab0976.png

• 平台管理员：负责平台的日常维护和管理，包括用户日志的管理、租户账号审核、租户状态管理、租户费用的管理，租户权限的管理，要注意的是平台管理员不能对租户的具体业务进行管理。如果租户数量大，还可以对平台管理员划分角色，可以按地域划分，比如西北地区、东北地区等，让平台管理员分别管理不同的租户；也可以根据业务进行划分，比如租户管理员，租费管理员等。
• 租户：指访问SaaS平台的用户企业，在SaaS平台中各租户之间信息是独立的。租户信息包括租户的名称、地址等租户企业的相关信息，主要用来区别各租户，并且由平台管理员对租户账号状态进行管理。各租户可根据需要自行选择SaaS平台功能模块并依此付费。
• 租户管理员：为租户角色分配权限和相关系统管理、维护。
• 租户用户：根据租户管理员分配的权限以及自己的角色进行相关的业务管理。各租户用户只能访问该租户选择的 SaaS 平台的功能模块。一个系统用户如果有多个角色，则他只能看到当前角色下的数据，通过角色切换，可以达到查看所属其他角色下的数据信息。
• 租户角色：根据业务功能分由租户管理员进行角色划分，划分好角色后，租户管理员可以对相应的角色进行权限分配。角色有上下级关系，上级可以查看下级的数据，下级不能访问上级的数据，平级之间不能相互访问。角色上层可再加入分组层（如分部门或团队等），不同组别的数据范围不同，资源、操作可以共享也可以隔离。

2.1.2 需求分析

在应用系统中，权限是以什么样的形式展现出来的？对菜单的访问，页面上按钮的可见性，后端接口的控制，都要进行充分考虑

• 前端 前端菜单：根据是否有请求菜单权限进行动态加载 按钮：根据是否具有此权限点进行显示/隐藏的控制
• 后端 前端发送请求到后端接口，有必要对接口的访问进行权限的验证

3.2 权限设计

针对这样的需求，在有些设计中可以将菜单，按钮，后端API请求等作为资源，这样就构成了基于RBAC的另一种授权模型（用户-角色-权限-资源）。在SAAS-HRM系统的权限设计中我们就是才用了此方案

11464886-b047c9190a16ef10.png

针对此种权限模型，其中权限究竟是属于菜单，按钮，还是API的权限呢？那就需要在设计数据库权限表的时候添加类型加以区分（如权限类型： 1为菜单 2为功能 3为API）。

2.2 表结构分析

11464886-aba0e1d687674291.png

这里要注意的是，权限表与权限菜单表、页面元素表与API接口表都是一对一的关系 与传统的RBAC模型对比不难发现此种设计的好处：

1. 不需要区分哪些是操作，哪些是资源
2. 方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的资源表，并确定这类权限的权限类型标识即可。