SaaS系统的权限管理

最近在设计一套面向票据中介的金融SaaS系统,又是一个从0到1的项目。虽然只是完成了第一期的设计,但是在系统设计的过程中有很多思考,权限管理就是其中重大的一环。权限管理作为系统的根基,就如房子的地基一样,是重中之重。如果地基不稳固,那么房子就可能要拆掉重建,而系统就有可能需要重构或者二次开发,非常浪费时间和精力。在系统设计之初,最好就按照未来公司‘做大做强’的规划进行设计,以保证这块功能的长期可用性。

权限管理,一言蔽之就是‘让不同的系统用户有不同的权限去看和操作’。在C端产品中,就如boss直聘,普通会员和付费会员在app中就会有不同的权限,就如之前写的文章《 BOSS直聘买VIP有用吗?》一样,平台会对普通会员和付费会员设置不同权限,以满足运营需求(只是有些甚是鸡肋,摊手);

而在面向企业经营的B端产品中,对于公司员工而言,就是让不同的部门和员工有不同的权限,就如运营部门和销售部门的权限是会不同的,而一线销售人员和销售总监的权限又是不同的。

说到权限管理,自然离不开RBAC模型。那么,什么是RBAC模型呢?

一、什么是RBAC模型?

RBAC模型(Role-Based Access Control)就是基于角色的访问控制。它基于“角色”这一核心理念,将用户权限的管理和分配与用户的具体身份解耦合,从而简化权限管理,以便维护和扩展。

简单来说,就是我将系统权限赋予‘角色’,用户再继承角色来获取权限。用类图来表示他们之间的关系的话,如下图:

SaaS系统的权限管理

  • 一个用户可以有0到多个角色。
  • 一个角色可以分配给0到多个用户。
  • 一个角色可以有0到多个权限。
  • 一个权限可以分配给0到多个用户。

当今的大部分B端系统的权限管理都会涉及到RBAC模型,只是功能的繁简程度不同而已。

二、RBAC模型的分类

RBAC模型分为RBAC0、RBAC1、RBAC2和RBAC3这四种,其中RBAC0为这四种分类中的基础,其他三类均是RBAC0基础上的变形。

1. RBAC0基本模型

我们先来聊聊RBAC模型中的基础,RBAC0模型。

RBAC0是基于角色的访问控制的完美体现,也就是把权限赋予角色,然后再把角色赋予用户,很多B端系统都是基于RBAC0搭建的权限管理。

从系统设计角度来说,角色管理设计也比较简单,如下图:

SaaS系统的权限管理

只需给对应的角色配置系统中的权限(菜单/操作/字段),完成角色创建后,再将角色赋予系统用户即可。这样在用户登录后,就能获取该用户的所属角色,然后通过角色来找到拥有的权限,再加载对应的权限资源。

完成RBAC0基本模型的搭建,基本就能满足当下绝大部分系统的权限管理的需求。

但是,如果一个部门人员很多,就如我前司,一级部门向下还有二级部门,二级部门向下才是员工,这样就导致如果采用RBAC0模型进行权限管理的话,则很有可能错配权限的问题。

那么,有什么方案解决呢?

有!那就是RBAC1角色分层模型。

2. RBAC1角色分层模型

RBAC1模型相较于RBAC0模型增加了角色继承的概念,有了角色继承就有父子的关系,即子角色可拥有父角色的权限。

从系统设计角度来看,如下图:

SaaS系统的权限管理

在配置角色的时候可以增加父角色的选择,可在父角色的基础上进行删减权限,以避免错配权限的问题。

在RBAC1模型中,我认为主要解决的就是同部门不同层级人员权限配置问题,以达到精准和快速配置权限。

就比如金融本部有一级部门负责人、二级部门负责人、小组长和专员,这样就可以在完成一级部门负责人的权限配置之后,再在一级部门负责人的基础上配置其他角色的权限,以实现其他角色的权限均在一级部门负责人的权限之内。

3. RBAC2角色限制模型

RBAC2模型是RBAC0的另一变种,对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

静态职责分离:

  • 互斥角色限制:一个用户不能同时分配互斥角色中的多个角色,即只能选择一个。
  • 基数限制:一个用户拥有的角色是有限的。
  • 先决条件限制:一个用户想获得更高级的角色,首先需先拥有低级角色。

动态职责分离:

动态限制:一个用户可以拥有两个角色,但是运行时只能激活一个角色。

其实RBAC2模型在我历史经历的系统中基本没有应用到了,静态和动态职责分离的限制条件,我感觉只满足了5%或者更少的应用场景。如果读者有设计过包含此模型的系统,也可和我沟通交流,我倒是想知道谁家这么变态。

4. RBAC3统一模型

RBAC3=RBAC1 RBAC2,既包含了角色分层,也包含了角色限制,不赘述。

三、RBAC模型之外的数据权限

就如文中所说,其实RBAC0基础模型已经满足了绝大部分的应用场景,是应该掌握的,其他三个模型了解即可。在RBAC模型之外,我想再聊聊数据权限。

角色管理系统中的资源,资源包括菜单(页面)权限、操作(按钮)权限和字段权限。那么,数据权限要通过什么进行管理?

没错,就是组织架构。通过角色管理用户在系统中能使用的资源,然后通过组织架构管理用户能看到的数据范围,这样就完整的搭建了SaaS系统的权限管理。

为什么通过组织架构能管理数据权限?

一般大型企业都是全国性质的,就如我的前司,作为中国头部的物流公司,产生的物流单是全国范围的,那么不同区域/不同层级对于数据的管理需求也就顺其自然产生了。

那么通过‘订单 门店’和组织架构就能管理数据权限,订单产生于不同的门店,不同的门店又隶属于不同的组织架构之下,不同的用户再在系统中配置对应的部门,即可实现数据权限。

这里为了数据权限控制的灵活度,在角色管理中还可以设置角色的数据权限范围,如下图:

SaaS系统的权限管理

SaaS系统的权限管理

数据权限可以限制为‘本人/本部门/下级部门/本部门和下级部门/自定义部门/全部’等属性,以控制用户对于不同范围的数据查看权限。

思考

以上就是SaaS系统的管理的全部内容,我认为‘RBAC0模型 数据权限’就可满足系统可见发展范围内的权限管理需求了。

当公司发展到一定程度,内部孵化的项目系统也会越来越多,那么将权限管理抽离,抽象成单独的「统一授权平台」也势在必行。

用统一的权限管理平台进行管理不同系统的权限,这部分的轮子抽象后是可以复用的。读者们也可以思考下要实现这部分的功能,要将系统的哪些模块进行抽离才可实现。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部