大型SaaS系统的数据范围权限设计与实现

芋道源码 2023-03-24 1066

电子说

1.3w人已加入

描述

toB 的系统，除了普通的权限管理之外，往往还需要数据范围权限。本文介绍一种，简单的易实现的 Saas 多租户数据范围权限系统的简单设计与实现。

权限的概述

我们一般说权限的时候是在说「功能权限和数据权限」 。

功能权限指用「户登陆系统后能看到什么模块，能看到哪些页面」 ，

而数据权限指的「是用户在某个模块里能看到几条数据，能看到哪些数据」 。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

视频教程：https://doc.iocoder.cn/video/

功能权限

在企业系统中，通过配置用户的功能权限可以解决不同的人分管不同业务的需求，基于RBAC模型，RBAC（Role Based Access Control)模型，它的中文是基于角色的访问控制，主要是将功能组合成角色，再将角色分配给用户，也就是说「角色是功能的合集。」

为何要基于RBAC

企业A一共有12个功能，需要创建100个用户，这些用户中有管财务的、有管人事的、有管销售的等等。如果不引入RBAC模型，我们需要每创建一个用户就要分配一次功能，至少（每个用户只有一个功能）操作100次，如果人数增加到1000甚至10000，并且一个用户可能会有多个功能的时候，操作会非常繁琐，如图：

为何要基于RBAC

经过多次操作发现：分配给某些人的功能都是相同的，比如分配给A、B等10个用户的功能都是客户管理、订单管理及供应商管理这几个模块，那是不是可以把这几个功能模块打成一个包整体分给需要的用户呢？

这个包就叫做角色。由于角色和功能的对应关系相对固定，给用户分配权限的时候只分配角色即可。

为何要基于RBAC

总结：

解耦用户和功能，降低操作错误率；
降低功能权限分配的繁琐程度。

为何要基于RBAC

功能粒度

功能的粒度从粗到细一般分为：「模块级->页面级->接口级（接口级的功能权限指的是哪个角色能调用哪些接口）。」

从后台角度：为了系统安全，代码肯定都会实现到接口级。那我们做粒度选择的意义是什么？当然是为用户降本增效。只是粒度越粗，用户操作越简单，灵活性却越低。

用户的优先级

我们常用的优先级顺序是查看「详情>查看列表>增加、删除、编辑、其他操作按钮」 。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud

视频教程：https://doc.iocoder.cn/video/