preface

Authority management is an important part involved in all background systems, the main purpose is to control the access to resources by different people, to avoid the risk caused by the lack of authority control or improper operation, such as operation errors, privacy data leakage and other problems.

Currently, I am in charge of the permission section of the company, so I am familiar with the design of the permission section. The company adopts the micro-service architecture, and the permission system is naturally independent. Other business systems include commodity center, order center, user center, warehouse system, small programs, several apps and more than a dozen systems and terminals.

1. Permission model

By far the most popular permission design model is RBAC model, role-based Access Control.

1.1 RBAC0 model

RBAC0 model is as follows:

​

This is the most basic and core model of permissions, which includes users/roles/permissions. Users and roles are many-to-many, and roles and permissions are many-to-many.

Users initiate operations and can be classified into 2B and 2C users by type. They can be background management system users, OA system internal employees, or C-terminal users, such as Aliyun users.

A role serves as a bridge between users and rights. Each role can be associated with multiple rights. If a user is associated with multiple roles, the user has multiple rights of multiple roles.

One might ask why users don’t associate permissions directly? In a system with a small user base, such as a small system with 20 people, the administrator can directly associate users with permissions. The workload is not large, so it is all right to select a user and check the required permissions.

However, in the actual enterprise system, the user base is relatively large, and many of them have the same permissions, which are ordinary access permissions. If the administrator grants authorization to 100 or more people, the workload will be huge.

This introduces the concept of “Role”. A Role can be associated with multiple users, and the administrator only needs to assign the Role to the user, so that the user can have all the permissions under the Role. In this way, the design not only improves efficiency, but also greatly expands.

• Jurisdiction:

Resources accessible to users, including page permissions, operation permissions, and data permissions:

• Page Permissions:

That is, the page that the user can see when logging in to the system is controlled by the menu. The menu includes the first-level menu and the second-level menu. As long as the user has the permission of the first-level menu and the second-level menu, the user can access the page

• Operation permission:

Function buttons on the page include view, Add, Modify, Delete, and review. When a user clicks the delete button, the background verifies whether all permissions under the user role include the delete permission. If yes, go to the next step. Otherwise, no permission is displayed.

Some system requirements “visible to operation”, which means if the page can see the action button, so the user can operate, in order to achieve this requirement, there is need to cooperate, the front-end front-end development of the user permission information cache, judge whether the user containing the permissions on the page, if you have, will display the button, if not, Hide the button.

The user experience is improved to some extent, but it is optional to do so in real scenarios

• Data permissions:

The data permission means that the user can see different data on the same page. For example, the financial department can only see the user data of its department, while the purchasing department can only see the data of the purchasing department.

In some large companies, there are many cities and branches in the country. For example, the user login system in Hangzhou can only see the data in Hangzhou, and the user login system in Shanghai can only see the data in Shanghai. The solution is generally to associate the data with the specific organizational structure.

For example, when the user is authorized again, if the user chooses a role and binds to the organization such as finance Department or Hefei Branch, the user will have the data rights of the finance Department or Hefei Branch under the role.

​

This is the core design and model analysis of RBAC, also known as RBAC0, which provides extended patterns based on the core concepts. Including RBAC1,RBAC2,RBAC3 models. These three types are described below.

1.2 RBAC1 model

​

This model introduces the concept of Hierarchical Role, that is, roles have Hierarchical relationships. The Hierarchical relationships among roles can be divided into general and restricted Hierarchical relationships.

The general inheritance relationship only requires that the role inheritance relationship be an absolute partial order relationship, allowing multiple inheritance between roles.

The restricted inheritance relationship further requires that the role inheritance relationship be a tree structure to achieve single inheritance between roles. This design can group and layer roles, which simplifies permission management to a certain extent.

1.3 RBAC2 model

Based on the core model, the role constraint control is carried out, and the relationship of responsibility separation is added in RBAC2 model.

It specifies mandatory rules to follow when permissions are assigned to roles or roles are assigned to users, and when a user activates a role at a certain point.

Separation of responsibility includes static separation of responsibility and dynamic separation of responsibility. Mainly includes the following constraints:

• Mutually exclusive roles:

A user can be assigned to only one role in a set of mutually exclusive roles, which supports the principle of responsibility separation.

A mutually exclusive role refers to two roles whose rights restrict each other. For example, the financial Department has two roles, accounting and auditor, which are mutually exclusive, so users cannot have both roles, which reflects the principle of separation of responsibilities

• Cardinality constraint:

The number of users assigned to a role is limited; The number of roles a user can have is limited; The number of access permissions corresponding to a role should also be limited to control the allocation of advanced permissions in the system

• Prerequisites Role:

That is, to obtain a superior role, the user must obtain the role at the next level

1.4 RBAC3 model

The most comprehensive permission management, based on RBAC0, RBAC1 and RBAC2 are integrated.

1.5 user group

When the platform user base increases and role types increase, and some people have the same attributes, such as all the employees of the finance department, if the role is directly assigned to users, the workload of the administrator will be huge.

If the same user classification of attributes to a certain group of users, so the administrator directly assign roles to the user group, user groups in each user can have the role, after other users to join groups of users, can automatically get all the role of user groups, exit the user groups, at the same time also revoked the user role under the group, no administrator manual management role.

User groups can be classified into user groups with upstream and downstream users and common user groups based on the relationship between the upstream and downstream users:

• User groups with superior and subordinate relationships:

The most typical example is departments and jobs, which most people probably don’t associate with user groups.

Of course, user groups can be expanded, and departments and positions are often used for internal management systems, if c-oriented systems. Attention to the public account Java journey reply manual to receive the Java interview

For example, merchants on Taobao.com have their own organizational structure, such as purchasing department, sales department, customer service department, logistics department, etc. Some of them have the customer service authority, some of them have the shelf authority, etc., so the user group can be expanded

• Common User Group:

That is, there is no relationship between superiors and subordinates, and it has nothing to do with organizational structure and position, that is to say, it can cross departments and positions.

For example, in the background management system of an e-commerce company, there is a group activity management role. We can set up a group user group, which can include background developers in the R&D department, operation personnel in the operation department, purchasing personnel and so on.

Every company involves organizations and positions, and these two are highlighted below.

1.5.1 organization

The common organizational structure is as follows:

​

We can associate organizations with roles. After users join the organization, they will automatically acquire all roles of the organization without the administrator’s manual authorization, which greatly reduces the workload. Meanwhile, when users change positions, they only need to adjust the organization and their roles can be adjusted in batches.

Another function of an organization is to control data permissions. By associating a role with an organization, the role can see only the data permissions of the organization.

1.5.2 position

Assume the position of finance department as shown below:

​

There are multiple positions under each organization department. For example, the financial Department has director, accountant, cashier and other positions. Although they are all in the same department, each position has different authority, and the higher position has more authority.

The director has all authority, and the accountant and cashier have some authority. In special cases, one person may wear more than one job.

1.6 Models with organization/position/user group

Based on the above scenario, a new permission model can be designed, as shown below:

​

The many-to-many and one-to-one relationships may vary depending on the complexity of the system

1, in the case of a single system and the user type single, users and organizations is a one-to-one relationship, organization and the position is a one-to-many relationship, the user and the position is a one-to-one relationship, organization and role is a one-to-one relationship, the position and role is a one-to-one relationship, users and user groups is more on relationship, user groups and roles is a one-to-one relationship, Of course, these relationships can also be adjusted according to the specific business.

Model design is not dead, if the small system does not need the user group, this can be removed.

2. In the case of distributed system and single user type, the authority system will become very complicated here, so the concept of “system” will be introduced here.

3. At this time, the system architecture is a distributed system, and the permission system is independent and responsible for the permission control of all systems. Other business systems, such as commodity center, order center and user center, each system has its own roles and permissions, so the permission system can configure the roles and permissions of other systems.

4. In the case of a distributed system with multiple user types, such as Taobao.com, its user types include internal users, businesses, ordinary users, internal users logging in to multiple background management systems, and businesses logging in to the business center. How should you design it as an architect? God can leave a message in the comments section!

2. Authorization process

Authorization is to grant roles to users. It can be divided into manual authorization and approval authorization. The permission center can be configured with both types to improve authorization flexibility.

• Manual authorization:

The administrator can authorize users to log in to the rights center in either of the following ways: Adding a role to a user or adding a user to a role.

To add a role to a user, click a user to grant a role on the user management page. You can add multiple roles to a user at a time. To add users to a role, click a role on the role management page and select multiple users. In this way, users can be assigned roles in batches.

• Approval and Authorization:

That is, when a user applies for a role, the user applies for the role through the OA process and the role is approved by the superior. The user does not need to be granted the role manually by the system administrator.

3. The table structure

With the above permission model, it is not difficult to design the table structure, the following is the multi-system table structure, simple design, mainly provide ideas:

​

4. Authority framework

• Apache Shrio
• Spring Security

You can use one of these frameworks in your project, and their pros and cons and how to use them will be covered in more detail in a later article.

5. Conclusion

Permissions system is arguably the most foundation, the system can also be very complicated at the same time, in the actual project, will have multiple systems, multiple user types, multiple usage scenarios, which requires specific analysis, but the core RBAC model is the same, we can based on the extended to meet the demand.

Recommended reading

Why are Alibaba’s programmers growing so fast?

Enter big factory also this matter, work after 2 to 3 years enter big factory operation guide

Ali architect [Boxi] take you to reveal the actual architecture project and source code interpretation: Weibo +B station architecture design, JUC core, Mybatis source code

After watching three things

If you find this article helpful, I’d like to invite you to do three small favors for me:

Like, forward, have your “like and comment”, is the motivation of my creation.

Follow the public account “Java Doudi” to share original knowledge from time to time.

Also look forward to the follow-up article ing🚀