1. Permission control

1. Business Background

In complex business systems, authority management is the most basic module. It manages users’ accessible and operable boundaries in products through various authorization structure models to achieve the purpose of system and data security management:

There is usually some level of permission control involved at any level of the system:

  • Page layer: menu, component, operation interface;
  • Gateway layer: blacklist and whitelist management, traffic control;
  • Control layer: platform, service, API;
  • Data layer: database, business table, field;

Different levels of permission management are used to meet the requirements of different scenarios, such as background system pages, whitelist in open platform, general API access restrictions, and field dimensions of core data.

It is not easy to use a reasonable strategy to manage resource permissions. Generally, with the continuous expansion of services and systems, the permission system will have a direct impact. Therefore, when designing the structure, it is necessary to be relatively complex but to avoid excessive complexity. In distributed systems, feasible solutions are usually considered from three aspects: system layer, organization structure and authority relationship.

2. RBAC model

In the model of permission Control, role-based-access-Control (RBAC) is a widely used model:

  • There are three core elements in the model: user, role and authority;
  • The model can be simplified to manage resources only at the user level.
  • Upgrade model structure, do inheritance merge or selective separation of responsibilities;

The RBAC permission system can be managed in fine detail, and the corresponding structure design is complex. It is usually used in distributed systems with multiple services and scenarios. In lightweight applications with few users, permission management can be simplified.

Second, organizational structure

1. Organizational model

Common organizational structures are as follows:

2. Role management

Different organizational nodes correspond to different roles:

At the level of organizational structure, hierarchical relationship of roles is brought, and then there will be a situation where a user has multiple roles. There are usually two handling strategies:

  • Merge roles: Merge the permissions of all user roles.
  • Role separation: After a user logs in to the system, the user switches roles based on the role selection and loads corresponding permissions.

Third, resource management

1. Resource hierarchy

System level: in a large and complex architecture, the system is divided into applications and the console is used to manage various general services. For example, the console is used to manage account opening and service authorization of various business applications, so as to form a system level structure. In this way, multiple applications can avoid repeated implementation of basic functions, and it is also more reasonable from the design level.

Resource granularity: the finely designed permission system can flexibly manage the scope of resource opening, from the direct opening of the application platform (platform administrator) to the opening of the function points of a page in the application (business personnel), and even to the control of library table field level, which can greatly improve data security.

Operation type: Generally, resource operations are defined as adding, deleting, modifying, and viewing operations, which affect data. Rights are described as read, write, and delete operations. Roles and resources are defined to authorize different actions.

2. Authorization association

  • Create roles and users around the organizational structure, and form the binding relationship between users and roles.
  • Define the management level of resources, and the corresponding operation types, and form the link between pages and data;
  • Based on the role subject, bind corresponding resources and operable types to construct the role permission set.

Based on the relationship between users and roles in the organizational structure and the operation rights of roles and resources, users can control resource management. Its core principle is RBAC model, which only makes complex designs for different nodes in different scenarios to better adapt to business.

In the permission system, most of the scenarios are less authorization actions and more loading process of permission point query. In the implementation process, redundant table association structure can be properly considered to simplify the query process.

Source code address

Application of warehouse: https://gitee.com/cicadasmile/butte-flyer-parent components encapsulation: https://gitee.com/cicadasmile/butte-frame-parentCopy the code