navigator
- prelude
- Scenario Sorting
- Role-Based Access Control (RBAC)
- Privilege design for multi-tenant systems
- Design of data permissions for the RuoYi system
- Final design
- consultation
This article was first publishedWizards Workshop - Saas Multi-Tenant Data Permission Design (Refer to RuoYi), totaling 3656 words and 5min reading time.
primer
Recently, the company intends to make the internal system into a commercialized Saas product, and our group has taken on the task of developing the product.
Theoretically, this system has been polished for 5 years + in our in-house business, and is already very mature for our industry segment, requiring only a slight modification to adapt to the multi-tenant model.
However, it was only when it was actually implemented into the project architecture design that I realized there was a lot of reorganization and reconsideration needed.
Today, the main focus is ondata privilegeThe design of this piece is shared with you.
Scenario Sorting
Design out of context always seems hollow.
In the IM chat scenario, a very important feature is that each user has to view his or her session (chat history).
For example.
- A regular counselor might just be able to view their own chat
- Supervisors can view group counselor chats
- CEO can view all counselor chats
- ...
How should such a requirement be realized in our system?
Role-Based Access Control (RBAC)
Role-based access control (RBAC), which refers to authorizing a user's relevant privileges through his or her role (Role), achieves a more flexible access control that is simpler, more efficient, and more scalable than granting privileges directly to users.
When using RBAC, you analyze the actual users of the system and grant them different roles based on common responsibilities and needs. You can grant users one or more roles, each with one or more permissions. This user-role and role-permission relationship eliminates the need to manage individual users individually, as users inherit the required permissions from the granted roles.
Privilege design for multi-tenant systems
Generally, we will categorize user permissions into menu permissions and data permissions.
Menu Permissions: Controls which menus or buttons the user can see.
Data permissions: Controls the range of data that a user can see.
Before we start the design, we can look at the process of user login + authorization, in the information returned by the user will contain the role (roleCodes), menu (permCodes) and data permission (dataCodes) information.
So, roles (roleCodes), menus (permCodes) and data permissions (dataCodes) are what we need to design in advance.
Based on IM's own business, we have designed the roles as follows:
- Counselor (counselor_role)
- Supervisor (manager_role)
- Administrator (admin_role)
Menu Permissions:
- Account Management (zhanghaoguanli)
- Public settings (gonggongshezhi)
- ... (as defined)
The headache is actually the design of the data permissions, where we expect to define a generic data permission.
So, here's where theRuoYi system。
Design of data permissions for the RuoYi system
Inadvertently, I came across an article describing the design and analysis of data permissions for the RuoYi system-An in-depth analysis of Ruoyi's data privilege @datascope (annotation+AOP+dynamic sql splicing) [Step-by-step, with analysis process]".。
So, I had an experience with this open source system. (Click here to go straight to it.) [/index]
Logging into the backend of the RuoYi system, you will be greeted by a bunch of familiar system menus.
- system management
- user management
- Role Management
- Menu Management
- Sectoral management
- Position Management
- Dictionary management
- ...
Check out the highlights hereRole Managementmenu in the list ofmanipulatecolumn, you can see that there is amorebutton to expand themorebutton.data privilegeThe button is exposed.
strike (on the keyboard)data privilegebutton to see the Data Rights Configuration window.
Here you can see the data permissions categorized as follows:
- Full data rights
- Customize data permissions
- Data permissions for this department
- Data permissions for this department and below
- Personal data access only
You can see that the data permissions here are designed based on the organizational structure.
It should be noted that here theCustomize data permissionsIt's actually also based on organizational choices, just with freedom of choice (e.g., adapting to cross-departmental scenarios).
Overall, the RuoYi system data permissions are designed to beconforming with the norms of societythat should fall into a more generalized design.
This is something to learn from the design of our current commercialization program.
Final design
There may be better design options out there, better suggestions are welcome.
consultation
- What is Role-Based Access Control (RBAC)?
- ruoyi official website
- RuoYi-Vue Source Code.
- An in-depth analysis of Ruoyi's data privilege @datascope (annotation+AOP+dynamic sql splicing) [Step-by-step, with analysis process]".