Author | Baidu Smart Mini Program Team

guide

This article first introduces the introduction of Dolly Bear’s business, and introduces the pain points of Dolly Bear’s business construction authority system, then discusses the specific scheme and design in detail from the authority system model, authority system design, and Dolly Bear business application, and finally thinks about the design of the authority system , to throw bricks and sparks for data dimension construction, and let everyone think about solutions together.

The full text is 5212 words, and the expected reading time is 14 minutes.

Dolly Bear is a local life service platform under Baidu. Dolly Bear aims to provide users with high-quality services at low prices and preferential prices. Based on Baidu’s AI and dual-engine capabilities, it is rapidly advancing with the trend of changing the market structure, providing local businesses with rich marketing channels, and is determined to become a reshape of the local life market. sexual power.

Dolly Bear covers catering, hotels, scenic spots, leisure and entertainment, beauties and many other categories. Users can spend less money to enjoy the local quality of life services selected by Dolly Bear. Become a Dolly Bear distribution expert, you can save money by purchasing yourself, and you can earn commissions by sharing direct sales. The follower lock policy allows experts to earn long-term commissions for users to place orders by themselves, and develop downstream experts to form a team to earn team commissions.

How the Dolly Bear architecture supports the operation of the entire business ecosystem, as shown in the following figure: As shown in the figure, the entire business structure of Dolly Bear is divided into three layers. Including: ecological scene layer, platform support layer, and infrastructure layer.

• Dolly Bear ecological scene: In addition to distributing in Baidu’s dual engines, Baijia account, and private domain, Dolly Bear has also expanded to the WeChat ecosystem, and built a Dolly Bear WeChat mini-program for distribution in the WeChat ecosystem, sharing through WeChat groups and WeChat , Wechat talent drainage. In addition to self-construction, third-party service providers, self-developed merchants, and local life service platforms are also introduced through cooperation to create a diversified and multi-type local life service ecosystem.

• Dolly Bear Platform Support: Duolixiong has built a large number of platforms, including: merchant platform, operation platform, review platform, editorial platform, distribution platform, intervention platform, quality platform and so on. Through a rich platform, it reduces operating costs and improves merchant access efficiency, so as to better support the rapid development of business and rapid iteration.

• dolly bear foundation: The infrastructure layer of Dolly Bear quickly supports the rapid iteration of business through the integration of small programs and many precipitation systems in Baidu Zhongtai. Including: self-developed service-oriented governance solutions for small programs: Tianlu, Tianyan, BRCC; multi-dimensional analysis reports and stability construction monitoring and governance methods for data accumulated in small programs; and Baidu’s rich middle-end systems: trading middle-end, marketing Middle platform, interactive middle platform, audit middle platform, etc.

As can be seen from the figure, in the entire Dolly Bear business structure, there are many platform roles, and the authority system faces many challenges.

• There are many platforms, and there are differences in the account systems of each platform. How does the permission system support the isolation settings of each platform to ensure the compliance and security of platform data?

• There are many business roles in multiple platforms, and the roles have subordinate and subordinate relationships, and everyone needs to work together. How does the permission system support efficient configuration and ensure multi-role collaboration, efficient and convenient operation?

• Multiple platforms are developed based on different languages. How does the permission system ensure the convenience of access?

Specifically how do we build and solve these problems? It will be introduced in detail below.

2.1 Permission system model

RBAC(role-based access control): Role-based permission access control.

RBAC is an access control mechanism defined around roles and permissions. In RBAC, permissions are associated with roles, and users get the permissions of these roles by becoming members of appropriate roles. This greatly simplifies the management of permissions. In an organization, roles are created to accomplish various tasks, and users are assigned corresponding roles according to their responsibilities and qualifications. Users can be easily assigned from one role to another. Roles can be given new permissions according to new requirements and system integration, and permissions can also be withdrawn from a role as needed. Character-to-character relationships can be built to encompass broader objective situations.

The four core components of RBAC:

1. S (Subject): subject, a user or automated agent

2. R (Role): role information, which is defined as a job position or title of an authorized level

3. SE (Session): The expression of identity and authority at the session level, the mapping relationship between S, R or P

4. P (Permissions): permission, a way to access resources

RBAC defines three main rules:

1. Role Assignment: Only when the subject chooses or is assigned a role, the subject can exercise the authority

2. Role Authorization: The principal’s active role must be authorized for the principal.Using rule 1 above, this rule ensures that users can only assume roles for which they are authorized

3. Authority authorization: Only when the authority is authorized for the active role of the subject, the subject can exercise the authority.For rules 1 and 2, this rule ensures that users can only exercise the privileges they are authorized to

Four models of RBAC:

1. Flat RBAC: The basic RBAC model, the basic concept is that users are assigned to roles, permissions are also assigned to roles, and users obtain corresponding permissions through roles

2. Hierarchical RBAC: Roles are organized into hierarchies, where “higher”-level roles inherit all permissions from “lower”-level roles

3. Constrained RBAC: Adding an implementation of Separation of Duties (SOD) to roles

4. Symmetric RBAC: Added permission role review requirements, similar to user role review described in Flat RBAC

Grade and feature descriptions for the four models:

Flat RBAC model structure:

Hierarchical RBAC model structure:

Constrained RBAC model structure:

Static separation of duties:

1. Mutually exclusive roles: the same user can only choose one of the two mutually exclusive roles

2. Cardinality constraints: a user has limited roles, and a role has limited permissions

3. Prerequisite constraint: If a user wants to obtain a high-level role, he must first have a low-level role

Dynamic separation of duties:

1. Constraints between sessions and roles can dynamically constrain the roles owned by users. For example, a user can have two roles, but only one role can be activated at runtime.

Symmetric RBAC model structure:

2.2 Authority system design

How to select and transform the RBAC model in our actual scenarios is a matter of in-depth consideration. First of all, we need to delineate the core functions of the permission system based on our business scenarios.

We are doing local service tob business, so we will have a merchant platform for merchants. In addition to the merchant management platform, we also need to manage the o-end construction platform, as well as the intervention platform for our development students, etc. These platforms need Authority control. Each system has its own page, and each page has its own function implementation, ranging from the control of page permissions to the control of buttons, all of which need to be considered by our permission system in the future business development. Therefore, our authority management is relatively arduous.

In view of our above business scenarios and demand forms, we first finalized the core responsibilities of the authority system:

1. Management and control of page menu permissions

2. Function group authority control

3. Button function authority control

4. Support multiple lines of business

We designed the following RBAC model based on Flat RBAC:

Based on the RBAC model we designed, continue to consider the details

1. Support multiple business line access and business line business isolation

2. Need to support the management and control of menu permissions, function group permissions, and button permissions

First consider the business line support issue. For this matter, we use a separate table to express product line information. When designing the user, role and func tables, they all need to be associated with the business line information table.

So we think about how to support page menu permissions, function group permissions and button permissions.

Menu permissions, function group permissions, and button permissions all belong to functional permissions, so we use a table to express functional permissions, and map with the tree structure expression of the front-end page to construct a functional permission tree, so we finally landed on ER The picture is as follows:

Business Line

For different systems, their respective user systems, role management, and authority management are different, and the demands of different systems need to be met. The first thing to do is to isolate each system.

We have designed a table of business line information, the core fields are as follows:

This table mainly describes the basic information content of the business line for better management and configuration.

The essence of business line isolation is that the user table, role table, and permission table all need to specify the prod_id of the business line. In this way, business line isolation is achieved in the three core roles of the BRAC model, and each system uses its own data. You need to specify your own prod_id.

user

From a business point of view, the merchant platform is a user account system for merchants to log in to the outside world. For the o-end, it is an internal account system for the scenarios used by our operation students and bd students. Therefore, we have this here Different user login systems.

We are faced with a variety of user system forms, so we are compatible with different user system designs, so the core fields of the user table we designed are as follows:

prod_id, user_type and login_id form a joint unique key.

Role

The roles of the FLAT BRAC model do not involve role inheritance relationships. Our current business does not involve such complex role relationships, so we use the simplest way to express role information, thereby reducing the management and maintenance of role identities.

The core fields of a role are as follows:

prod_id and en_name form a joint unique construction.

permissions

Permissions is where we think the most. We hope that the functional permissions of the front-end pages can be agreed upon through a unified standard.

Let’s understand the design of the front-end. Whether it is the b-end or the o-end front-end, it is our own front-end team. They use a unified front-end framework and style for design, which is the best situation for our permission system. , the first thing we need to face is this style of authority control.

First look at the front-end page style of our b-side as follows:

Here, the left side is the page menu bar, and the right side is the page corresponding to the menu bar, which contains the various functional modules involved.

What we have to deal with here is:

1. Permission control of the menu bar: whether the menu is displayed, the menu hierarchy and the page permission content of the menu design

2. Page authority: the functional authority involved in the page

3. Function group: the function authority of certain function modules in the page

4. Button: Permissions for the button

So we are going to transform the permission table into a tree structure as shown in the figure:

Based on such a tree structure, we can describe the entire authority control content of the front end. The core fields of authority are as follows:

The overall core design is like this. Combined with our microservice framework concept, our overall business interaction diagram is as follows:

Now our authority system is already supporting the authority control of Dolly Bear B-end platform and O-end platform, and is supporting the Xiaobian platform. We will continue to serve the authority control of more platforms in the future.

2.3 Dolly Bear Business Application

Based on the design of the authority system above, Dolly Bear’s business can efficiently and flexibly realize authority management in the face of a huge personnel organization structure and complex business systems.

As shown in the application scenario of the business operation system in the figure below, the system is open to multiple internal teams, and each team has different functions, and even the teams are divided into different positions.

For this application scenario, the distribution and management of system permissions mainly include the following steps:

1. Clarify the role of the system: As shown in Figure 3.1 above, the business operation system includes multiple platforms including merchants, shops, orders, etc. For each platform, it is necessary to determine which roles are needed in the platform, and different roles undertake different tasks in the platform. For example, the merchant registration system includes roles to help merchants settle in, roles to help merchants manage members, and so on.

2. Clear role permissions: According to the specific tasks undertaken by the roles, the corresponding system operability permissions are also different, which requires each role to be assigned specific operation permissions. For example, the role that helps merchants settle in can have the authority to enter, query, modify merchant information and other interfaces and buttons.

3. Define the team structure: As shown in Figure 3.2 above, the audit management project requires multiple teams such as business, operation, and customer service, and there are corresponding positions under different teams to undertake different tasks. For example, the business team includes business editors, business administrators, and business leaders.

4. Assign system roles to team members: In order to combine the role permissions in the system with the organizational structure in the team, as shown in Figure 3.3 above, managers can assign the corresponding platform permissions to the personnel in the position through role configuration. For example, the business editor only has the role of product management, while the business can have the role of product management and merchant entry roles at the same time, so that the practical application of role-based authority management is realized.

With functional permissions, we should then think about another area, which is data permissions.

Data permission means having or not having access permission to certain data. The specific manifestation is when a user has operation permission, but it does not mean that he or she has viewing or management permission to all data. There are two manifestations of data permissions: one is row permissions, and the other is column permissions.

The so-called row authority is to restrict the user’s access to certain rows, for example: only the data of the person, the department, and the organization can be accessed; it can also be restricted according to the scope of the data, such as: the size of the contract to limit users Access to Data. The so-called column permission is to restrict the user’s access to certain columns, for example: the summary of some content can be viewed, but the detailed content can only be viewed by VIP users.

Through data permissions, users can be physically restricted from obtaining rows or columns of data. This method has many advantages over restricting certain rows or columns based on user permissions after all data is obtained. Taking list data permissions as an example, row data is mainly controlled through data permissions, so that different people have different rules for viewing data; to realize data permissions, the most important thing is to abstract data rules.

But data rules alone are not enough, we also need to bind data rules with resources and users. In this way, resources can be associated with data rules.

In terms of design, we need a separate data rule management function, which is convenient for us to enter data rules, and then on the resource management page, we can select the built-in data rules to bind resources and rules.

So how to let different users have different data rules?

In the RBAC model, users manage resources by granting different roles. Similarly, we can associate roles with data rules when granting permissions, so that different users have different data rules in the system. .

Based on this, we can basically realize the binding of RBAC and data rules; at the same time, data permissions are a relatively complex function to implement. In addition to expanding on the basis of the RBAC model, whether there are other more reasonable ideas are left for everyone to think about. .

——END——

References:

[1]https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents /sandhu-ferraiolo-kuhn-00.pdf

Recommended reading:

Distributed System Critical Path Latency Analysis Practice

Baidu engineers teach you how to play design mode (decorator mode)

Baidu engineers take you to experience nodejs in the engine

Demystifying the Practice of Baidu Intelligent Test in the Field of Test Positioning

Baidu engineers take you to explore C++ memory management (ptmalloc)

Why the video FPS calculated by OpenCV is wrong