CN114417300A - Multi-tenant user access control system and method - Google Patents

Abstract

The invention discloses a multi-tenant user access control system and a method, belonging to the technical field of web, aiming at solving the technical problems of realizing tenant isolation among application systems and tenant user access authority control and ensuring the safety of the application systems, and adopting the technical scheme that: the system comprises a tenant management module, a multi-application system and a user authentication module, wherein an independent database is adopted between the tenant management module and the multi-application system; single sign-on can be realized among multiple application systems, and each application system has a unique application identifier; the tenant management module is used for tenant management of the multi-application system; the tenant management of the multi-application system comprises the creation of the tenant and the application access authorization of the tenant; the multi-application system is used for providing services for tenant users; the user authentication module is used for being embedded into each application system, and data isolation of different tenants and authority control of different users are achieved by adopting Keycoak. The invention also discloses a multi-tenant user access control method.

Description

Multi-tenant user access control system and method

technical field

The invention relates to the technical field of Web applications, in particular to a multi-tenant user access control system and method.

Background technique

With the rapid development of Internet technology, more and more application software manufacturers provide SaaS services. At present, security problems emerge in an endless stream, and with the enhancement of everyone's security awareness, people have higher and higher requirements for the security of application systems. Multi-tenancy technology is a measure to achieve tenant isolation and improve application system security. Usually, the implementation of multi-tenancy includes adding a tenant attribute field in the application system data table or deploying different application systems for different tenants. The former is more intrusive to the application system, and due to the shared database resources, for the application system with high database resource consumption, the performance of tenants will be affected by each other. The implementation of deploying separate application systems for different tenants has higher costs.

Therefore, how to realize tenant isolation between application systems and control of access rights of tenant users to ensure the security of each application system is a technical problem that needs to be solved urgently at present.

SUMMARY OF THE INVENTION

The technical task of the present invention is to provide a multi-tenant user access control system and method to solve the problem of how to implement tenant isolation between application systems and control of tenant user access rights to ensure the security of each application system.

The technical task of the present invention is achieved in the following manner: a multi-tenant user access control system, the system includes a tenant management module, a multi-application system and a user authentication module, and an independent database is used between the tenant management module and the multi-application system ;Single sign-on can be realized between multiple application systems, and each application system has a unique application ID;

Among them, the tenant management module is used for the tenant management of the multi-application system; the tenant management of the multi-application system includes the creation of the tenant and the application access authorization of the tenant;

Multi-application systems are used to provide services to tenant users;

The user authentication module is used to embed each application system, and uses Keycloak to realize data isolation for different tenants and permission control for different users.

Preferably, when the tenant management module creates a tenant, it adds authorizedApps, tenantCode, tenantId, expiredTime and userType to the user attributes of Keycloak, where authorizedApps, tenantCode, tenantId, expiredTime and userType respectively represent the application system, tenant ID, Tenant unique ID, tenant expiration time and user type;

Among them, tenantCode is an 8-bit unique random string; tenantId is 36, UUID; expiredTime is the expiration time when the tenant is allowed to access the application; userType is the user type, which is tenant for tenants, and the value for users under the tenant is user.

More preferably, when creating a user, the tenant management module creates an application database of each application system and a tenant user database for the tenant according to the application system authorized to access the user, and initializes the application configuration information and the tenant configuration information; The application system shares a tenant user database;

Application configuration information includes application dictionary configuration, application menu permissions and application interface permissions;

The tenant configuration information includes the default role of the tenant; the default role of the tenant includes the administrator role of each application system, and the management role of each application system has all the menu and interface permissions of the corresponding application system;

The tenant user database is used to save the resource access control configuration information of tenant users and each application system, and save the resource access control configuration information of tenant users and each application system, including application menu permissions, application interface permissions, roles, the corresponding relationship between roles and permissions, and user Correspondence with roles;

Wherein, the application database of each tenant application system The application database name of each application system is composed of two parts, an application identifier and a tenantCode, and the application identifier and tenantCode are separated by an underscore;

The name of the tenant user database is composed of the fixed identifier user and tenantCodde. The fixed identifier user and tenantCodde are separated by an underscore.

More preferably, each application system has a tenant access control filter, and the tenant access control filter is used to switch to the tenant application database corresponding to the user and the user database corresponding to the tenant when the tenant user accesses each application system, and to authenticate the tenant access. ;

The tenant access control filter is implemented using Spring's Filter, as follows:

(1) The tenant access control filter obtains the user login Token from the Authorization request header requested by the user;

(2), parse the authorizedApps attribute in Token;

(3), determine whether the attribute contains the current application ID:

①, if not, the user is prohibited from accessing;

②, if yes, execute step (4);

(4), check whether the expiredTime attribute in the token is after the current time:

①, if not, deny access;

②, if yes, then execute step (5);

(5), determine whether the current request path contains the sys prefix:

①, if so, switch the data source to the tenant user database;

②. If not, switch the data source to the tenant application database.

More preferably, when creating a user, each application system obtains the attributes authorizedApps, tenantCode, tenantId, expiredTime and userType from the token:

If userType is user, the tenantId of the created user is set to the tenantId in the token;

If userType is tenant, the tenantId of the created user is set to the ID of the currently logged in user;

The userType of the currently created user is set to user, and the user attributes authorizedApps, tenantCode, tenantId and expiredTime are consistent with the corresponding parsed values in the token.

More preferably, each application system adopts a structure in which the front-end page and the back-end of the application are separated; when the user accesses the front-end page, the front-end page calls the application back-end interface to obtain the menu and interface authorization rights of the user's current application, and saves it in a global variable;

The front-end page includes routing control. When the user requests any menu path, first check whether the user authorization menu in the front-end global variable contains the current access path:

If yes, allow access;

If not, jump to the default forbidden access page;

The interface authorization authority is implemented by SpringSecurity. The PreAuthorize annotation is added to all Controllers, and the custom interface authority verification method is called through the Spel expression in the annotation. The interface authority verification method parameter is the interface authority identifier corresponding to the interface.

A multi-tenant user access control method, the method is as follows:

S1. Create a tenant: specify the applications that the tenant authorizes to access and the authorization expiration time;

S2. Create a user for each tenant;

S3, front-end page loading initialization and front-end routing control;

S4. Execute the tenant access control filter:

Preferably, the creation of the tenant in the step S1 is as follows:

S101. Generate a unique tenantCode of 8 for the tenant, that is, the tenant code. When creating the tenant application database and user database, the tenantCode will be used as the suffix of the database name;

S102. Set the tenant attribute userType to tenant;

S103. Set tenant authorized application attributes authorizedApps and expiredTime;

S104, calling the user creation interface of keycloak to complete the creation of the user;

S105, initialize the tenant user database;

S106, initialize the corresponding application database and user database for the authorized applications in turn according to authorizedApps; the initialization process of the application database and the user database is completed by executing the preset DDL statement script (Data Definition Language) and DML (Data Manipulation Language) statement script , the execution script adopts Mybatis' ScriptRunner;

The details of creating a user for each tenant in the step S2 are as follows:

S201. Obtain a login user resolution token;

S202. Determine whether the tenantType is tenant:

①, if yes, execute step S203;

②. If not, set the user tenantId attribute to the tenantId in the token, and jump to step S204;

S203, the user tenantId attribute is set to the ID of the user in the token;

S204, the user attributes authorizedApps, tenantCode, tenantId and expiredTime are consistent with the corresponding parsed values in the token;

S205, the user userType attribute is set to user.

Preferably, the step S3 front-end page loading initialization and front-end routing control are as follows:

S301. When the user accesses the front-end page, the front-end page calls the application back-end interface to obtain the menu and interface authorization permissions of the user's current application, and saves them in a global variable to complete the page initialization; wherein, when the front-end framework adopts angular, define a service to authorize The menu is stored in the properties of the service to realize the preservation of global variables, avoiding the risk of user tampering when stored in cookies or web storage, such as session storage or localstorage;

S302, when the user requests a certain menu path, obtain the authorized menu path from the global variable;

S303. Check whether the user authorization menu in the front-end global variable contains the current access path:

①, if yes, allow access and jump to the request menu page;

②. If not, jump to the default forbidden access page.

Among them, for the angular project, routing control is implemented through routing guards; the user can define a class to implement the CanActivateChild and CanActivate interfaces, and then configure the canActivateChild and canActivate attributes when configuring the routing.

Preferably, the execution of the tenant access control filter in the step S4 is as follows:

S401, the tenant access control filter obtains the user login token from the Authorization request header requested by the user;

S402, parsing token;

S403. Determine whether the authorizedApps attribute in the parsing token contains the current application identifier:

①, if not, the user is prohibited from accessing;

②, if yes, then execute step S404;

S404. Check whether the expiredTime attribute in the token is after the current time:

①, if not, the user is prohibited from accessing;

②, if yes, then execute step S405;

S405. Determine whether the current request path contains the sys prefix:

①. If not, switch the data source to the tenant application database;

②, if so, switch the data source to the tenant user database;

Among them, the data source switching is implemented by the multi-data source library dynamic-datasource-spring-boot-starter, and compile group:'com.baomidou',name:'dynamic-datasource-spring-boot-starter' is introduced in build.gradle ,version:'2.5.4' depends on it;

Execute the DynamicDataSourceContextHolder.push(datasourceName) command to switch the data source;

Execute the DynamicDataSourceContextHolder.poll() command to cancel the data source setting;

Among them, dataSourceName is the data source name. For the application database, the data source name is appa_tenant01; for the user database, the data source name is user_tenant01; where appa is the application ID, and tenant01 is the tenant code or tenantCode.

The multi-tenant user access control system and method of the present invention has the following advantages:

(1) The present invention realizes tenant isolation and access authority control between application systems, and realizes flexible tenant user access authority control through front-end menu authority control and back-end interface authority control, and ensures the security of the system;

(2) The present invention realizes the isolation before tenants by creating different tenant application databases and tenant user databases for different tenants, sharing the tenant user database among the application systems, and improving the system performance through the control of front-end menu authority and back-end interface authority. safety.

Description of drawings

The present invention will be further described below with reference to the accompanying drawings.

Accompanying drawing 1 is the architecture diagram of multi-tenant user access control system;

Accompanying drawing 2 is the flow chart of tenant access control filter execution;

Accompanying drawing 3 is the flow chart of front-end page loading initialization;

Accompanying drawing 4 is the flow chart of front-end routing control execution;

Accompanying drawing 5 is the flow chart of creating tenant;

FIG. 6 is a flowchart of creating a tenant user.

Detailed ways

With reference to the drawings and specific embodiments of the description, a multi-tenant user access control system and method of the present invention will be described in detail below.

Example 1:

As shown in FIG. 1, the multi-tenant user access control system of the present invention includes a tenant management module, a multi-application system and a user authentication module, and an independent database is used between the tenant management module and the multi-application system; the multi-application system Single sign-on can be achieved between applications, and each application system has a unique application identifier;

Among them, the tenant management module is used for the tenant management of the multi-application system; the tenant management of the multi-application system includes the creation of the tenant and the application access authorization of the tenant;

Multi-application systems are used to provide services to tenant users;

The user authentication module is used to embed each application system, and uses Keycloak to realize data isolation for different tenants and permission control for different users.

When the tenant management module in this embodiment creates a tenant, it adds authorizedApps, tenantCode, tenantId, expiredTime, and userType to the user attributes of Keycloak, where authorizedApps, tenantCode, tenantId, expiredTime, and userType represent the application system, tenant ID, Tenant unique ID, tenant expiration time and user type;

Among them, tenantCode is an 8-bit unique random string; tenantId is 36, UUID; expiredTime is the expiration time when the tenant is allowed to access the application; userType is the user type, which is tenant for tenants, and the value for users under the tenant is user.

When creating a user, the tenant management module in this embodiment creates an application database of each application system and a tenant user database for the tenant according to the application system authorized to access the user, and initializes the application configuration information and the tenant configuration information; The system shares a tenant user database;

Application configuration information includes application dictionary configuration, application menu permissions and application interface permissions;

The tenant configuration information includes the default role of the tenant; the default role of the tenant includes the administrator role of each application system, and the management role of each application system has all the menu and interface permissions of the corresponding application system;

The tenant user database is used to save the resource access control configuration information of tenant users and each application system, and save the resource access control configuration information of tenant users and each application system, including application menu permissions, application interface permissions, roles, the corresponding relationship between roles and permissions, and user Correspondence with roles;

Wherein, the application database of each tenant application system The application database name of each application system is composed of two parts, an application identifier and a tenantCode, and the application identifier and tenantCode are separated by an underscore;

The name of the tenant user database is composed of the fixed identifier user and tenantCodde. The fixed identifier user and tenantCodde are separated by an underscore.

The application database and user database can be created on different database instances or on the same database instance according to the size of the application business data.

Each application system in this embodiment has a tenant access control filter. When a tenant user accesses each application system, the tenant access control filter is used to switch to the tenant application database corresponding to the user and the user database corresponding to the user, and to authenticate the tenant access. right;

As shown in Figure 2, the tenant access control filter in this embodiment is implemented by using Spring's Filter, as follows:

(1) The tenant access control filter obtains the user login Token from the Authorization request header requested by the user;

(2), parse the authorizedApps attribute in Token;

(3), determine whether the attribute contains the current application ID:

①, if not, the user is prohibited from accessing;

②, if yes, execute step (4);

(4), check whether the expiredTime attribute in the token is after the current time:

①, if not, deny access;

②, if yes, then execute step (5);

(5), determine whether the current request path contains the sys prefix:

①, if so, switch the data source to the tenant user database;

②. If not, switch the data source to the tenant application database.

When creating a user, each application system in this embodiment obtains the attributes authorizedApps, tenantCode, tenantId, expiredTime and userType from the token:

If userType is user, the tenantId of the created user is set to the tenantId in the token;

If userType is tenant, the tenantId of the created user is set to the ID of the currently logged in user;

The userType of the currently created user is set to user, and the user attributes authorizedApps, tenantCode, tenantId and expiredTime are consistent with the corresponding parsed values in the token.

Each application system in this embodiment adopts a structure in which the front-end page and the application back-end are separated; when the user accesses the front-end page, the front-end page calls the application back-end interface to obtain the menu and interface authorization rights of the user's current application, and saves them in a global variable;

The front-end page includes routing control. When the user requests any menu path, first check whether the user authorization menu in the front-end global variable contains the current access path:

If yes, allow access;

If not, jump to the default forbidden access page;

The interface authorization authority is implemented by SpringSecurity. The PreAuthorize annotation is added to all Controllers, and the custom interface authority verification method is called through the Spel expression in the annotation. The interface authority verification method parameter is the interface authority identifier corresponding to the interface.

Example 2:

The multi-tenant user access control method of the present invention is specifically as follows:

S1. Create a tenant: specify the applications that the tenant authorizes to access and the authorization expiration time;

S2. Create a user for each tenant;

S3, front-end page loading initialization and front-end routing control;

S4. Execute the tenant access control filter:

As shown in FIG. 5 , the details of creating a tenant in step S1 in this embodiment are as follows:

S101. Generate a unique tenantCode of 8 for the tenant, that is, the tenant code. When creating the tenant application database and user database, the tenantCode will be used as the suffix of the database name;

S102. Set the tenant attribute userType to tenant;

S103. Set tenant authorized application attributes authorizedApps and expiredTime;

S104, calling the user creation interface of keycloak to complete the creation of the user;

S105, initialize the tenant user database;

S106, initialize the corresponding application database and user database for the authorized applications in turn according to authorizedApps; the initialization process of the application database and the user database is completed by executing the preset DDL statement script (Data Definition Language) and DML (Data Manipulation Language) statement script , the execution script adopts Mybatis' ScriptRunner;

As shown in FIG. 6 , in step S2 in this embodiment, the details of creating a user for each tenant are as follows:

S201. Obtain a login user resolution token;

S202. Determine whether the tenantType is tenant:

①, if yes, execute step S203;

②. If not, set the user tenantId attribute to the tenantId in the token, and jump to step S204;

S203, the user tenantId attribute is set to the ID of the user in the token;

S204, the user attributes authorizedApps, tenantCode, tenantId and expiredTime are consistent with the corresponding parsed values in the token;

S205, the user userType attribute is set to user.

As shown in FIGS. 3 and 4 , the step S3 front-end page loading initialization and front-end routing control in this embodiment are as follows:

S301. When the user accesses the front-end page, the front-end page calls the application back-end interface to obtain the menu and interface authorization permissions of the user's current application, and saves them in a global variable to complete the page initialization; wherein, when the front-end framework adopts angular, define a service to authorize The menu is stored in the properties of the service to realize the preservation of global variables, avoiding the risk of user tampering when stored in cookies or web storage, such as session storage or localstorage;

S302, when the user requests a certain menu path, obtain the authorized menu path from the global variable;

S303. Check whether the user authorization menu in the front-end global variable contains the current access path:

①, if yes, allow access and jump to the request menu page;

②. If not, jump to the default forbidden access page.

Among them, for the angular project, routing control is implemented through routing guards; the user can define a class to implement the CanActivateChild and CanActivate interfaces, and then configure the canActivateChild and canActivate attributes when configuring the routing.

As shown in FIG. 2 , the execution of the tenant access control filter in step S4 in this embodiment is as follows:

S401, the tenant access control filter obtains the user login token from the Authorization request header requested by the user;

S402, parsing token;

S403. Determine whether the authorizedApps attribute in the parsing token contains the current application identifier:

①, if not, the user is prohibited from accessing;

②, if yes, then execute step S404;

S404. Check whether the expiredTime attribute in the token is after the current time:

①, if not, the user is prohibited from accessing;

②, if yes, then execute step S405;

S405. Determine whether the current request path contains the sys prefix:

①. If not, switch the data source to the tenant application database;

②, if so, switch the data source to the tenant user database;

Among them, the data source switching is implemented by the multi-data source library dynamic-datasource-spring-boot-starter, and compile group:'com.baomidou',name:'dynamic-datasource-spring-boot-starter' is introduced in build.gradle ,version:'2.5.4' depends on it;

Execute the DynamicDataSourceContextHolder.push(datasourceName) command to switch the data source;

Execute the DynamicDataSourceContextHolder.poll() command to cancel the data source setting;

Among them, dataSourceName is the data source name. For the application database, the data source name is appa_tenant01; for the user database, the data source name is user_tenant01; where appa is the application ID, and tenant01 is the tenant code or tenantCode.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features thereof can be equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention. scope.

Claims (10)

1. A multi-tenant user access control system is characterized by comprising a tenant management module, a multi-application system and a user authentication module, wherein an independent database is adopted between the tenant management module and the multi-application system; single sign-on can be realized among multiple application systems, and each application system has a unique application identifier;

the tenant management module is used for tenant management of the multi-application system; the tenant management of the multi-application system comprises the creation of the tenant and the application access authorization of the tenant;

the multi-application system is used for providing services for tenant users;

the user authentication module is used for being embedded into each application system, and data isolation of different tenants and authority control of different users are achieved by adopting Keycoak.

2. The multi-tenant user access control system according to claim 1, wherein when the tenant management module creates a tenant, authezedapps, tenatcode, tenantId, expiredTime, and userType are added to user attributes of keylock, and the authezedapps, tenatcode, tenantId, expiredTime, and userType respectively represent an application system, tenant identity, tenant unique ID, tenant expiration time, and user type that the tenant authorizes access;

wherein, the tenantCode is an 8-bit unique random character string; tentId is 36 is UUID; expiredTime is the expiration time that the tenant allows access to the application; the userType is a user type, the value of the userType is tentant for the tenant, and the value of the userType is user for the user under the tenant.

3. The multi-tenant user access control system according to claim 1 or 2, wherein the tenant management module creates an application database of each application system and a tenant user database for the tenant according to the application system to which the tenant is authorized to access when creating the user, and initializes application configuration information and tenant configuration information; the multi-application system which is authorized to be accessed by the tenant shares a tenant user database;

the application configuration information comprises application dictionary configuration, application menu authority and application interface authority;

the tenant configuration information comprises a tenant default role; the default roles of the tenants comprise administrator roles of each application system, and the management roles of each application system have all menus and interface authorities of the corresponding application system;

the tenant user database is used for storing resource access control configuration information of tenant users and each application system, and the resource access control configuration information of the tenant users and each application system comprises application menu authority, application interface authority, roles, role and authority corresponding relations and user and role corresponding relations;

the application database name of each application system of the application database of each tenant application system consists of an application identifier and a tentcode, and the application identifier and the tentcode are divided by underlining;

the tenant user database name is composed of a fixed identifier user and a tentacodde, and the fixed identifier user and the tentacodde are separated through underlining.

4. The multi-tenant user access control system of claim 3, wherein each application system has a tenant access control filter, and the tenant access control filter is used for switching to a tenant application database corresponding to the user and a user database of a tenant corresponding to the user and authenticating the tenant access when the tenant user accesses each application system;

the tenant access control Filter is implemented by using Spring Filter, which specifically includes:

(1) the tenant access control filter acquires a user login Token from an Authorization request header of a user request;

(2) analyzing authorizedApps attribute in Token;

(3) judging whether the attribute contains the current application identifier:

if not, forbidding the user to access;

if yes, executing the step (4);

(4) check if the expiredTime attribute in token is located after the current time:

if not, access is denied;

if yes, executing the step (5);

(5) judging whether the current request path contains sys prefix:

if yes, switching the data source to a tenant user database;

and if not, switching the data source to the tenant application database.

5. The multi-tenant user access control system of claim 4, wherein each application system obtains authezedapps, tenatcode, tenantId, expiredTime, and userType attributes from token when creating a user:

if the userType is the user, setting tenANTId of the creating user as tenANTId in token;

if the userType is tentant, setting tentANTId of the created user as the ID of the current login user;

the userType of the current creation user is set as user, and the corresponding resolution values in the user attributes authzedApps, tenantCode, tenantId, expiredTime and token are kept consistent.

6. The multi-tenant user access control system of claim 5, wherein each application system employs a front-end page and application back-end separated architecture; when a user accesses a front-end page, the front-end page calls an application rear-end interface to obtain a menu and an interface authorization authority of the current application of the user, and the menu and the interface authorization authority are stored in a global variable;

the front-end page comprises routing control, when a user requests any menu path, whether a user authorization menu in the front-end global variable contains a current access path is checked firstly:

if yes, allowing access;

if not, jumping to a default access prohibition page;

the interface authorization authority is realized by using SpringSecurity, PreAuthorize annotations are added to all controllers, a custom interface authority verification method is called through a Spel expression in the annotations, and interface authority verification method parameters are interface authority identifiers corresponding to the interface.

7. A multi-tenant user access control method is characterized by comprising the following specific steps:

s1, creating the tenant: specifying applications authorized for access by the tenant and an authorization expiration time;

s2, creating users for each tenant;

s3, front-end page loading initialization and front-end routing control;

and S4, executing the tenant access control filter.

8. The multi-tenant user access control method according to claim 7, wherein the created tenant in the step S1 is specifically as follows:

s101, generating a 8-unique tentacode for the tenant, namely a tenant code, wherein the tentacode is used as a suffix of a database name when a tenant application database and a user database are created;

s102, setting a tenant attribute userType as a tent;

s103, setting tenant authorization application attributes authazedApps and expiredTime;

s104, calling a user creating interface of the keylog to complete the creation of the user;

s105, initializing a tenant user database;

s106, initializing a corresponding application database and a corresponding user database for authorized applications in sequence according to authazedApps; the initialization process of the application database and the user database is completed by executing a preset DDL statement script and a preset DML statement script, and the executed script adopts script runner of Mybatis;

in step S2, the user creation details for each tenant are as follows:

s201, obtaining a login user analysis token;

s202, judging whether the tentTYPE is tentant:

if yes, executing step S203;

if not, setting the tennantId attribute of the user as tennantId in token, and jumping to the step S204;

s203, setting a tenntid attribute of the user as the ID of the user in the token;

s204, corresponding analysis values in user attributes authazedApps, tenantCode, tenantId, expiredTime and token are kept consistent;

s205, setting the user userType attribute as user.

9. The multi-tenant user access control method according to claim 7, wherein the step S3 is specifically performed as follows:

s301, when a user accesses a front-end page, the front-end page calls an application rear-end interface to obtain a menu and an interface authorization authority of the current application of the user, and the menu and the interface authorization authority are stored in a global variable to complete page initialization; when the front-end framework adopts the angular, defining service, storing the authorization menu in the attribute of the service to realize the storage of the global variable;

s302, when a user requests a certain menu path, obtaining an authorized menu path from the global variable;

s303, checking whether the user authorization menu in the global variable of the front end contains the current access path:

if yes, allowing access and jumping to a request menu page;

and if not, skipping to a default access-forbidden page.

10. The multi-tenant user access control method according to claim 7, wherein the executing tenant access control filter in step S4 is specifically as follows:

s401, a tenant access control filter acquires a user login token from an Authorization request header of a user request;

s402, analyzing token;

s403, judging whether the authazedApps attribute judgment in the token contains the current application identifier:

if not, forbidding the user to access;

if yes, executing step S404;

s404, checking whether the expiredTime attribute in the token is positioned after the current time:

if not, forbidding the user to access;

if yes, executing step S405;

s405, judging whether the current request path contains sys prefix:

if not, switching the data source into a tenant application database;

if yes, switching the data source to the tenant user database;

the data source switching is realized by utilizing a multi-data source library dynamic-data-spring-boot-starter, and a complex group is introduced into the build.

Execute a dynamicdatasourcecontextholder push (datasourceName) command to switch data sources;

execute a dynamicdatasourcecontextholder () command to cancel the data source setting;

wherein, the dataSourceName is a data source name, and the data source name of the application database is apa _ latent 01; its data source name is user _ tent 01 for the user database; where appa is the application identifier and tenant01 is the tenant code, namely tenantCode.

Images