[Interview] How to design data permissions for SaaS products?

foreword

A set of system permissions can be divided into two categories, data permissions and functional permissions. Today we will discuss how to design data permissions from the following points.

What are data permissions?

This question should be answered from three aspects.

• One is to control the scope of data accessed by the registrant, and not to be able to see what should not be seen;
• The second is to control the registrant's behavior of operating data, and what should not be managed cannot be managed;
• The third is to control the business object attributes that the login person can view, and sensitive attributes must be controlled.

Design Principles

The design of data permissions should follow two principles:安全性、灵活性

• Security is fundamental. Under this set of data permission system, all data permissions must be truly controlled;
• And flexibility means that it cannot be "written to death". A system often requires a lot of data that requires permission control, which requires strong flexibility. Otherwise, it will affect the user experience and be troublesome for the technical team.

Overall program

• A new menu is added, which is specially used for the data authority control and maintenance of the system, which can be designed according to user name + menu + field + content.
• Of course, if a complete system includes many subsystems, the system needs to be added when designing.
• It should be noted that menus and fields must be verified whether they exist in the system, or they will be maintained in vain.
• When the user opens a menu, it will call the information of the data permission maintenance, judge the fields inside, and the displayed content is maintained by these fields. If it is not found, all the data can be displayed by default (because the user can enter the menu to indicate that he already has the menu view function permissions).

RBAC model

• RBAC is Role-BasedAccess Controlthe abbreviation of RBAC, which means role-based access control.

• RBAC will define different roles in the system in advance, and different roles have different permissions. A role is actually a set of permissions. All users of the system will be assigned to different roles, and a user may have multiple roles. Using RBAC can greatly simplify the management of permissions.

• The RBAC model can also be subdivided into RBAC0, RBAC1, RBAC2, and RBAC3. Here we will not discuss the differences between them. Interested students can do their own research. We mainly focus on the common RBAC0 model.

• The following figure is a database design of a classic RBAC0 model.
  
  
  

Under the RBAC model, the system only verifies whether user A belongs to role RoleX, and does not judge whether user A can access data DataB that only belongs to user B. We call this kind of problem "horizontal authority management problem".

How to control data permissions?

Let's take a look at how to control the data permissions of the registrant, which can be divided into data range permission control, data operation permission control and business object field permission control.

1. Data scope permission control

The business objects within the B-end customers are usually divided into jurisdictions according to the management level. For example, the property platform I have worked on, they will be divided into five levels: district (also called property project), area, branch, region and headquarters to divide the scope of jurisdiction.

The community here is actually a basic authorized business object, and then a collection of multiple communities will form a district. At the same time, the operator of the community will be the main body with legal personality, that is, the branch company. Multiple branches will be divided into different regions according to geographical regions, and finally all business data will be managed by the headquarters. At this time, we need to support data authorization from basic business objects to a wider range.

For example, the following scenarios:

• The property project manager of community A authorizes community A, and he can only see various business data of community A (repair, complaint, charging, etc.);
• The property area manager of Area B authorizes Area B, and he can see all kinds of business data of all communities under Area B, including the newly added communities in Area B in the future.
• The general manager of company C's property branch authorizes company C to see all kinds of business data of all communities under company C, including the communities that will be added in company C in the future.
• The property manager of District D authorizes District D, and he can see all kinds of business data of all communities under District D, including the newly added communities of various branches under District D in the future.
• The group leaders at the headquarters can see all kinds of business data in the community.

Generally speaking, the authorization methods at different levels are mutually exclusive, that is, one person cannot be authorized at both the community level and the district level. At the same time, the same level supports multiple authorizations.

For the external business objects of B-side customers, because there is no jurisdiction level, it is often done through allocation. That is, one or more business objects are assigned to a certain type of role or an employee, and the login person can only see the business objects assigned to him. A typical example is the customer public sea resource of the CRM system, and employees can only see the customers assigned to them.

2. Business object operation authority control

Business object operation permissions refer to the operations that can be performed on business objects and business object attributes. Typical operations of business objects are adding, deleting, editing, viewing, exporting, changing the status of business objects (such as converting market leads to sales leads) and so on. For example, we control that employee A can only view customer information, but cannot add, edit, delete and export customer information.

3. Business object field permission control

The granularity of the business object field is a little smaller. It is for a certain type of business object and restricts which attributes of the business object the registrant can view, edit, or export. Business object properties technically correspond to the fields of the data table.

For example, the business object "customer" in the CRM system will have information such as name, address, phone number, level, industry, etc. We can control that employee A (or role) can only view the customer's name, level and industry, and is not allowed to view the address and phone number.

Summarize

In general, the authorization of data permissions is divided into three aspects, business object scope authorization, business object operation authorization and business object field authorization.

In order to realize the authorization of these three methods, we need to support the division of business object scope, the definition of business object operations, and the definition of business object fields in product design, as shown in the following figure. After that, we can configure the data permissions of a role or person.

Data permission is an essential function of SaaS products. A lot of enterprise data involves sensitive information, including commercial confidential information, etc. Therefore, it is necessary to clarify the granularity of authority control and how to manage data authority at the beginning of product planning.