A multi-tenant user management method and system supporting permission inheritance

Abstract

A multi-tenant user management method and system supporting permission inheritance, relating to the field of electronic digital data processing, in which a permission inheritance mapping table is created according to a role authorization request, and a permission inheritance relationship is written; a bidirectional mapping cache including a first mapping table and a second mapping table is generated; when a change in the permission of a source tenant role is detected, a target tenant user set associated with the source tenant role is queried based on the first mapping table; a permission update message is constructed for the target tenant user set, and the permission update message is asynchronously sent to each user in the target tenant user set; a permission verification request is received, and the source tenant role information inherited by the target tenant user is obtained according to the second mapping table; the current operation permission of the source tenant role corresponding to the source tenant role information is merged with the operation permission of the target tenant user to obtain the real-time permission data of the target tenant user. This application improves the real-time and accuracy of permission management.

Description

Technical Field

[0001] The present application belongs to the field of electronic digital data processing, and in particular, relates to a multi-tenant user management method and system supporting permission inheritance. Background Art

[0002] With the development of cloud computing technology, multi-tenant platforms have become an important infrastructure for enterprise information construction, among which user management and permission control are key links to ensure the safe operation of the platform. Traditional multi-tenant user management systems usually adopt an independent permission allocation mechanism, and each tenant needs to configure access rights for its users separately. This method not only increases the workload of managers when there are a large number of users and a complex organizational structure, but is also prone to inconsistent or missing permission configuration problems.

[0003] In related technologies, multi-tenant user rights management can be optimized through the role-based access control (RBAC) model, which implements unified management and batch allocation of rights by defining roles and associating rights with roles. Once a user is assigned a specific role, he or she will automatically obtain all the rights corresponding to the role, which simplifies the rights configuration process and improves management efficiency.

[0004] However, when a tenant needs to grant its specific role and related permissions to users of other tenants, it is difficult for the system to dynamically perceive and automatically maintain this authorization relationship. As a result, when the role permissions of the source tenant change, the user permissions of the authorized tenant cannot be updated in real time, reducing the real-time and accuracy of permission management. Summary of the invention

[0005] The present application provides a multi-tenant user management method and system supporting permission inheritance, which are used to improve the real-time and accuracy of permission management.

[0006] In a first aspect, the present application provides a multi-tenant user management method supporting permission inheritance, receiving a role authorization request from a source tenant, the role authorization request including identification information of a target tenant and role information to be authorized, the role information including a role identification and operation permissions associated with the role identification;

[0007] Create a permission inheritance mapping table based on the role authorization request, and write the permission inheritance relationship in the permission inheritance mapping table. The permission inheritance relationship includes the source tenant ID that initiates the authorization, the target tenant ID that receives the authorization, the role ID, and the authorization time for establishing the permission inheritance relationship;

[0008] Generate a bidirectional mapping cache including a first mapping table and a second mapping table, wherein the first mapping table is used to store a mapping relationship between a source tenant role and a target tenant user, and the second mapping table is used to store a mapping relationship between a target tenant user and a source tenant role;

[0009] When it is detected that the permission of the source tenant role has changed, querying the target tenant user set associated with the source tenant role based on the first mapping table;

[0010] Construct a permission update message for the target tenant user set, and asynchronously send the permission update message to each user in the target tenant user set through a message queue;

[0011] When receiving a permission verification request sent by the target tenant user, obtaining the source tenant role information inherited by the target tenant user according to the second mapping table;

[0012] The current operation permission of the source tenant role corresponding to the source tenant role information is combined with the operation permission of the target tenant user to obtain the real-time permission data of the target tenant user.

[0013] By adopting the above technical solution, a permission inheritance mapping table is established to record the permission inheritance relationship between the source tenant and the target tenant, and a bidirectional mapping cache is used to store the mapping relationship from the source tenant role to the target tenant user and the mapping relationship from the target tenant user to the source tenant role. When the permission of the source tenant role changes, the system can quickly locate the affected set of target tenant users based on the first mapping table, and asynchronously push permission update messages through the message queue. When the target tenant user initiates permission verification, the system can quickly obtain the source tenant role information inherited by the user according to the second mapping table, and merge the current operation permissions of the source tenant role with the target tenant user's own operation permissions, so as to obtain accurate real-time permission data, improve the real-time and accuracy of permission data, reduce the response delay of the system, and improve the efficiency of permission management.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, creating a permission inheritance mapping table according to a role authorization request specifically includes:

[0015] Collect the associated tenant information of the source tenant, which includes a list of tenant identifiers that have a direct permission inheritance relationship with the source tenant;

[0016] A tenant relationship directed graph is constructed based on the associated tenant information. The nodes of the tenant relationship directed graph represent tenants, and the directed edges between nodes represent the permission inheritance relationship.

[0017] Generate an alarm if a circular inheritance path is detected in the tenant relationship directed graph;

[0018] When it is detected that there is no cyclic inheritance path in the tenant relationship directed graph, a permission inheritance mapping table is constructed based on the inheritance relationship between the source tenant and the target tenant.

[0019] By adopting the above technical solution, by collecting the associated tenant information of the source tenant to build a tenant relationship directed graph, and detecting whether there is a circular inheritance path in the graph, it is possible to discover potential circular inheritance problems before the permission inheritance relationship is established, thereby improving the stability and controllability of the tenant permission inheritance system, while also simplifying the maintenance of the permission inheritance relationship and reducing the system's operation and maintenance costs. When it is confirmed that there is no circular inheritance path in the tenant relationship directed graph, the system will establish the actual permission inheritance mapping relationship, thereby improving the efficient operation of the permission inheritance system.

[0020] In conjunction with some embodiments of the first aspect, in some embodiments, generating a bidirectional mapping cache including a first mapping table and a second mapping table specifically includes:

[0021] Read all the permission inheritance relationships of the source tenant from the permission inheritance mapping table;

[0022] For each permission inheritance relationship, extract the user information of the target tenant, which includes the user ID and user permissions;

[0023] Filling a first mapping table according to the correspondence between the source tenant role and the target tenant user;

[0024] Based on the corresponding relationship in the first mapping table, the second mapping table is constructed in reverse order to obtain a bidirectional mapping cache including the first mapping table and the second mapping table.

[0025] By adopting the above technical solution, a two-way mapping cache is constructed by reading all the source tenant's permission inheritance relationships from the permission inheritance mapping table and extracting the target tenant's user information, so that the system can maintain the complete mapping relationship from the source tenant role to the target tenant user in memory, and the reverse mapping relationship from the target tenant user to the source tenant role. The design of the two-way mapping cache enables the system to quickly locate relevant data when processing permission changes and permission verification, reducing database query operations. Since the mapping relationship is cached in memory, the system can achieve fast response when performing permission inheritance related operations, improving the performance of the system.

[0026] In combination with some embodiments of the first aspect, in some embodiments, before receiving the role authorization request of the source tenant, the method further includes:

[0027] Get the target tenant's authorization receiving configuration, which includes the source tenant whitelist that allows receiving permissions to be inherited;

[0028] When the source tenant is in the source tenant whitelist, verify the authorization qualification of the source tenant;

[0029] The step of receiving the role authorization request of the source tenant is performed only if the source tenant is qualified for authorization.

[0030] By adopting the above technical solution, by introducing the authorization receiving configuration and source tenant authorization qualification verification mechanism before receiving the role authorization request, precise control of the source of permission inheritance is achieved. The system limits the scope of source tenants allowed to receive permission inheritance through the whitelist mechanism, and strictly verifies the authorization qualifications of the source tenants to prevent unauthorized tenants from performing unauthorized operations. By conducting qualification review before permission inheritance, the system can control the legitimacy of permission inheritance from the source, reduce the risk of permission leakage, and while ensuring the flexibility of permission inheritance, it also improves the security and controllability of the permission inheritance process, enhancing the security protection capabilities of the entire multi-tenant system.

[0031] In conjunction with some embodiments of the first aspect, in some embodiments, verifying the authorization qualification of the source tenant specifically includes:

[0032] Read the source tenant's qualification level information, which is used to identify the source tenant's authorized capability range;

[0033] Get the role information to be authorized in the role authorization request;

[0034] Match the role information with the source tenant's qualification level information;

[0035] When the role information does not exceed the authorization scope allowed by the qualification level, it is determined that the source tenant is qualified for authorization;

[0036] When the role information exceeds the authorization range allowed by the qualification level, the role authorization request is rejected.

[0037] By adopting the above technical solution, by reading the source tenant's qualification level information and matching it with the role information to be authorized, the system can determine whether the source tenant has the corresponding authorization capability before the authorization operation is performed. When the role information exceeds the authorization scope allowed by the qualification level, the system will directly reject the role authorization request, avoiding the occurrence of unauthorized authorization, and can accurately control the authorization scope of source tenants of different levels. By implementing strict qualification level management and authorization scope control, the system can reduce the risk of permission leakage and unauthorized operation, and ensure the security and controllability of the permission inheritance mechanism in a multi-tenant environment.

[0038] In combination with some embodiments of the first aspect, in some embodiments, after verifying the authorization qualification of the source tenant, the method further includes:

[0039] Record the source tenant's authorization request time, authorization object, authorization content, and verification results;

[0040] Statistics on the number of authorizations and the authorization success rate of the source tenant within the preset time window;

[0041] When the number of authorizations exceeds the preset threshold or the authorization success rate is lower than the preset standard, the authorization limit of the source tenant is reduced.

[0042] By adopting the above technical solution, when the source tenant's authorization behavior is found to be abnormal within the preset time window, the system will automatically reduce its authorization limit, thereby suppressing potential abuse of authorization or malicious authorization behavior, and being able to timely discover and handle abnormal authorization modes, reducing system risks caused by frequent authorization or low-quality authorization. By quantitatively analyzing the authorization behavior characteristics of the source tenant, the system realizes intelligent and automated authorization management, reduces the need for manual intervention, and improves the security and reliability of the system.

[0043] In conjunction with some embodiments of the first aspect, in some embodiments, reducing the authorization limit of the source tenant specifically includes:

[0044] Read the current authorization limit of the source tenant;

[0045] Calculate the adjustment coefficient of the authorization limit based on the number of authorizations and the authorization success rate;

[0046] Multiply the current authorization limit by the adjustment factor to obtain the new authorization limit.

[0047] By adopting the above technical solution and introducing the calculation method of the authorization limit adjustment coefficient, the system can achieve accurate adjustment of the source tenant's authorization limit. The adjustment coefficient calculated based on the number of authorizations and the authorization success rate can objectively reflect the quality of the source tenant's authorization behavior, and accordingly make corresponding dynamic adjustments to the authorization limit. The system obtains a new authorization limit by multiplying the current authorization limit by the adjustment coefficient, ensuring the continuity and smoothness of the limit adjustment.

[0048] In a second aspect, an embodiment of the present application provides a multi-tenant user management system that supports permission inheritance, and the multi-tenant user management system that supports permission inheritance includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and one or more processors call the computer instructions to enable the system to execute the method described in the first aspect and any possible implementation method of the first aspect.

[0049] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a system, causes the system to execute the method described in the first aspect and any possible implementation of the first aspect.

[0050] In a fourth aspect, an embodiment of the present application provides a computer program product. When the computer program product runs on a system, the system executes the method described in any possible implementation manner in the first aspect.

[0051] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0052] 1. The present application provides a multi-tenant user management method that supports permission inheritance, by establishing a permission inheritance mapping table to record the permission inheritance relationship between the source tenant and the target tenant, and using a two-way mapping cache to store the mapping relationship from the source tenant role to the target tenant user and the mapping relationship from the target tenant user to the source tenant role. When the permissions of the source tenant role change, the system can quickly locate the affected set of target tenant users based on the first mapping table, and asynchronously push permission update messages through the message queue. When the target tenant user initiates permission verification, the system can quickly obtain the source tenant role information inherited by the user according to the second mapping table, and merge the current operation permissions of the source tenant role with the target tenant user's own operation permissions, thereby obtaining accurate real-time permission data, improving the real-time and accuracy of permission data, reducing the response delay of the system, and improving the efficiency of permission management.

[0053] 2. This application provides a multi-tenant user management method that supports permission inheritance. By introducing the authorization reception configuration and source tenant authorization qualification verification mechanism before receiving the role authorization request, precise control of the source of permission inheritance is achieved. The system limits the scope of source tenants allowed to receive permission inheritance through a whitelist mechanism, and strictly verifies the authorization qualifications of the source tenants to prevent unauthorized tenants from performing unauthorized operations. By conducting a qualification review before permission inheritance, the system can control the legitimacy of permission inheritance from the source, reduce the risk of permission leakage, and while ensuring the flexibility of permission inheritance, it also improves the security and controllability of the permission inheritance process, enhancing the security protection capabilities of the entire multi-tenant system.

[0054] 3. This application provides a multi-tenant user management method that supports permission inheritance. When the source tenant's authorization behavior is found to be abnormal within the preset time window, the system will automatically reduce its authorization limit, thereby suppressing potential abuse of authorization or malicious authorization behavior, and can promptly detect and handle abnormal authorization modes, reducing system risks caused by frequent authorization or low-quality authorization. The system realizes intelligent and automated authorization management by quantitatively analyzing the authorization behavior characteristics of the source tenant, reducing the need for manual intervention and improving the security and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 It is a flow chart of a multi-tenant user management method supporting permission inheritance in an embodiment of the present application.

[0056] Figure 2 It is a flow chart of an optimization method based on authorization qualification management in an embodiment of the present application.

[0057] Figure 3 It is a schematic diagram of the physical device structure of a multi-tenant user management system supporting permission inheritance provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to any or all possible combinations comprising one or more listed items.

[0059] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0060] The following uses an embodiment and combines Figure 1 , a multi-tenant user management method supporting permission inheritance in an embodiment of the present application is described:

[0061] See also Figure 1 , which is a flow chart of a multi-tenant user management method supporting permission inheritance in an embodiment of the present application.

[0062] S101. Receive a role authorization request from a source tenant;

[0063] The system receives a role authorization request from a source tenant, the role authorization request includes identification information of a target tenant and role information to be authorized, the role information includes a role identifier and operation permissions associated with the role identifier.

[0064] In this step, the system receives a role authorization request initiated by the source tenant. The request contains two key pieces of information: the target tenant's identification information and the role information to be authorized. The target tenant identification information is used to specify the tenant object that receives the permission authorization, while the role information includes the unique identification of the role and a series of operation permissions associated with the role. With this information, the system can clearly identify the initiator, recipient, and specific content of this authorization.

[0065] The system can receive the role authorization request from the source tenant in a variety of ways, such as providing a Web interface for permission management, and the source tenant submits the authorization request by filling out a form; or the system provides a corresponding API interface, and the source tenant initiates authorization to the system by sending an HTTP request. At the same time, to ensure the security of the authorization request, the system can perform necessary verification on the request, such as verifying the legitimacy of the identity of the request sender, checking the integrity and correctness of the request parameters, etc.

[0066] S102: Create a permission inheritance mapping table according to the role authorization request, and write the permission inheritance relationship into the permission inheritance mapping table;

[0067] The system creates a permission inheritance mapping table based on the role authorization request, including:

[0068] Collect the associated tenant information of the source tenant, which includes a list of tenant identifiers that have a direct permission inheritance relationship with the source tenant;

[0069] A tenant relationship directed graph is constructed based on the associated tenant information. The nodes of the tenant relationship directed graph represent tenants, and the directed edges between nodes represent the permission inheritance relationship.

[0070] Generate an alarm if a circular inheritance path is detected in the tenant relationship directed graph;

[0071] When it is detected that there is no cyclic inheritance path in the tenant relationship directed graph, a permission inheritance mapping table is constructed based on the inheritance relationship between the source tenant and the target tenant. After that, the permission inheritance relationship is written into the permission inheritance mapping table, and the permission inheritance relationship includes the source tenant ID that initiates the authorization, the target tenant ID that receives the authorization, the role ID, and the authorization time for establishing the permission inheritance relationship.

[0072] After confirming that a legal and valid role authorization request has been received, the system needs to create a permission inheritance mapping table based on the request content and write the permission inheritance relationship generated by the authorization into the mapping table. The permission inheritance mapping table can be used to record and manage the permission transfer between tenants, where the permission inheritance relationship includes information such as the source tenant ID that initiated the authorization, the target tenant ID that received the authorization, the role ID that the authorization was transferred to, and the time when the authorization occurred. Through the permission inheritance mapping table, the system can clearly present and trace the permission inheritance context between tenants.

[0073] The process of building a permission inheritance mapping table can be divided into several key links. First, the system needs to collect the associated tenant information of the source tenant, that is, the list of identifiers of other tenants that have a direct permission inheritance relationship with the source tenant. Then, the system builds a tenant relationship directed graph based on the associated tenant information obtained. The nodes in the graph represent tenants, and the directed edges between the nodes represent the direction of permission inheritance. It is worth noting that the system needs to detect whether there is a circular inheritance in the tenant relationship graph. For example, tenant A grants permissions to tenant B, and tenant B in turn grants permissions to tenant A. If such a circular inheritance occurs, it may cause confusion in the permission relationship. Once a circular inheritance path is found, the system should generate an alarm message to prompt the administrator to handle it in time. After confirming that there is no circular inheritance, the system can build a permission inheritance mapping table based on the authorization relationship between the source tenant and the target tenant, and write the permission inheritance relationship generated by this authorization into the table.

[0074] The creation and writing process of the permission inheritance mapping table may encounter data concurrency issues, that is, multiple source tenants initiate role authorization to the same target tenant at the same time. At this time, the system needs to ensure the atomicity when writing the permission inheritance relationship. It can use the transaction mechanism of the database to control it, encapsulate the write operation in a transaction, and ensure that only one transaction is executing the write at the same time to avoid dirty data. In addition, when processing authorization requests, the system must also consider changes in the tenant hierarchy. Adjustments to the tenant organizational structure may cause the existing permission inheritance relationship to become invalid. Therefore, the system needs to establish a complete mechanism that can dynamically perceive changes in the tenant hierarchy and update the permission inheritance mapping table in a timely manner to ensure that the authorization relationship is synchronized with the actual organizational structure of the tenant.

[0075] S103, generating a bidirectional mapping cache including a first mapping table and a second mapping table;

[0076] The system generates a bidirectional mapping cache including a first mapping table and a second mapping table, wherein the first mapping table is used to store the mapping relationship between the source tenant role and the target tenant user, and the second mapping table is used to store the mapping relationship between the target tenant user and the source tenant role. Specifically, it includes:

[0077] Read all the permission inheritance relationships of the source tenant from the permission inheritance mapping table;

[0078] For each permission inheritance relationship, extract the user information of the target tenant, which includes the user ID and user permissions;

[0079] Filling a first mapping table according to the correspondence between the source tenant role and the target tenant user;

[0080] Based on the corresponding relationship in the first mapping table, the second mapping table is constructed in reverse order to obtain a bidirectional mapping cache including the first mapping table and the second mapping table.

[0081] The main task of this step is to generate a bidirectional mapping cache to speed up the permission query and verification process. This bidirectional cache consists of two mapping tables: the first mapping table is used to store the mapping relationship between the source tenant role and the target tenant user, and the second mapping table stores the mapping relationship between the target tenant user and the source tenant role in reverse. Through this bidirectional mapping mechanism, the system can quickly find the target tenant user with corresponding permissions based on the role information of the source tenant, and vice versa. The purpose of introducing the mapping cache is to improve the performance of the system in permission management, avoiding the need to traverse the complete permission inheritance mapping table for each permission verification, thereby affecting the response speed.

[0082] The process of building a bidirectional mapping cache can be summarized as the following steps: First, the system needs to read all the permission inheritance relationship data of the source tenant from the permission inheritance mapping table. Then, for each permission inheritance relationship, the system extracts the user information of the target tenant, where the user information mainly includes the user's unique identifier and the set of permissions that the user has. After obtaining the correspondence between the source tenant role and the target user, the system fills the first mapping table accordingly. Next, the system traverses each correspondence in the first mapping table, uses the source tenant role as the value and the target tenant user as the key, and reversely constructs the second mapping table. At this point, the bidirectional mapping cache containing two mapping tables has been generated. The system can choose to store the mapping cache in memory to ensure the efficiency of permission queries.

[0083] Although the introduction of bidirectional mapping cache can speed up permission query, it may also cause data consistency problems. Since the cache data comes from the permission inheritance mapping table, when the inheritance relationship in the mapping table changes, the data in the cache also needs to be updated synchronously, otherwise the cache data will be inconsistent with the actual permission status, which will affect the accuracy of permission control. To solve this problem, the system can maintain the mapping cache through several strategies such as preloading, real-time update and data expiration. For example, the system can design a scheduled task to periodically load the full amount of data from the permission inheritance mapping table and refresh the mapping cache; or publish a message notification when the inheritance relationship changes to trigger the real-time update of the cache; or set an expiration time for the cache, and the cache data that exceeds the time threshold will be marked as invalid and reloaded from the mapping table. Through these processing strategies, the system can obtain the benefits of cache acceleration while reducing the error rate of permission judgment caused by cache inconsistency.

[0084] S104: when it is detected that the authority of the source tenant role has changed, query the target tenant user set associated with the source tenant role based on the first mapping table;

[0085] When the system detects that the permission data of a source tenant role has been modified, it needs to find all target tenant users associated with the role based on the first mapping table. The first mapping table provides the mapping relationship from the source tenant role to the target tenant user, so the system can quickly obtain all target user information that inherits the permissions of the current role by querying the table. The purpose of this step is to prepare for subsequent permission change notifications and ensure that all affected target users can receive permission update messages.

[0086] The system can monitor changes in the source tenant's role permissions in a variety of ways. For example, a listener can be embedded in the role permission management module. When a request to add, delete, or modify role permissions is received and executed, the listener is immediately triggered to pass the changed role identifier to the subsequent process; or a database trigger can be set for the role permission table to automatically call the trigger function when the table data changes, and perform subsequent queries and notification operations. Regardless of the monitoring method used, the system needs to access the first mapping table after capturing a permission change event. Since the first mapping table is a KV structure, where the Key is the source tenant role identifier and the Value is the target tenant user set, the changed role identifier can be directly used as the query condition, and a complete list of target users can be obtained through a single KV query.

[0087] S105, constructing a permission update message for the target tenant user set, and asynchronously sending the permission update message to each user in the target tenant user set through a message queue;

[0088] After obtaining the set of all target users affected by the source tenant's role permission changes, the system needs to construct permission update messages for these users and send the messages to the users to keep their permission data consistent with the source tenant. The constructed permission update message needs to contain the specific content of the change, such as a list of role operation permissions that have been added, deleted, or adjusted. Since the number of target users may be large, if a synchronous method is used to notify them one by one, the main process may be blocked, affecting the system's concurrent performance. Therefore, this step uses a message queue to implement an asynchronous notification mechanism. The system pushes the constructed permission change message to the message queue, and then the message queue is responsible for reliably delivering the message to each target user, thereby achieving decoupling of the notification process.

[0089] The construction of permission update messages needs to rely on the latest permission data of the source tenant role. The system can encapsulate the addition, deletion and modification operations of role permissions into atomic events, and store the events persistently in a database or other storage medium. In this way, when constructing an update message, you only need to query the latest event record of the role to restore the latest permission status of the role. The message format can adopt a common data exchange format such as JSON, and design a reasonable field structure to ensure the readability and scalability of the message. When selecting a message queue, you need to consider factors such as its reliability, performance, and difficulty of integration with the system. Common message queue middlewares include Kafka, RabbitMQ, RocketMQ, etc. The system can select a suitable middleware product according to actual needs. When sending a message, the system can generate a message for each target user, or merge multiple users into a group and generate a batch message to reduce the number of messages.

[0090] S106: When receiving a permission verification request sent by the target tenant user, obtaining source tenant role information inherited by the target tenant user according to the second mapping table;

[0091] This step describes the process of verifying the permissions of the target tenant user. When the target tenant user accesses system resources or performs specific operations, the system needs to verify the user's permissions in real time to determine whether the user has the corresponding operation permissions. In order to complete the permission verification as quickly as possible, the system will first query the second mapping table. The second mapping table provides a reverse mapping relationship from the target tenant user to the source tenant role, so the system can quickly locate the role information inherited by the user from the source tenant based on the user ID carried in the request. After obtaining the role information, the system uses it as the input for subsequent permission operations, compares it with the resources and operations requested by the user, and finally determines whether the user has sufficient permissions.

[0092] Permission verification requests are usually generated when users access system resources, such as when users request to view a page, download a specific file, or submit a form. The system can set a permission interceptor at the entrance of the user request to perform permission checks on each request. The interceptor extracts the identification information of the target tenant user from the request, and then queries the second mapping table based on the identification. Since the user identification exists as a key in the second mapping table, the KV query can be used to quickly match the corresponding source tenant role Value. The role information is usually a list that contains all the roles that the user inherits from the source tenant. After obtaining the role list, the interceptor compares the resources and operations requested by the user with the roles in the list one by one to check whether the user has the corresponding operation permissions. The comparison process can be performed by mapping resources and operations to permission points one by one. If a record matching the permission point is found in the role list, it means that the user has the permission, otherwise it is considered that the user does not have the permission and the request is rejected.

[0093] S107: Combine the current operation permission of the source tenant role corresponding to the source tenant role information with the operation permission of the target tenant user to obtain real-time permission data of the target tenant user.

[0094] After completing the target tenant user's permission verification, this step dynamically merges and adjusts the target tenant user's permissions according to the latest permission status of the source tenant role, and finally generates the user's actual operation permission data at the current time point. The merging processing logic here needs to take into account two aspects: one is that the target tenant user may have some of his own permissions in this tenant, and the other is the role permissions inherited by the user from the source tenant. The system needs to superimpose these two parts of permissions, remove duplication, and finally determine the user's access rights to resources and operations. The real-time user permission data obtained after the merger will be used as the basis for subsequent permission judgment until the next permission verification request arrives and the user permissions are recalculated.

[0095] The process of permission merging can be divided into several specific steps. First, the system extracts the latest operation permission list corresponding to the role from the source tenant role information. Since the permissions of the source tenant role may be the result of the update after step S104 and step S105, the system needs to ensure that the latest permission status of the role is obtained. Then, the system queries the target tenant user's own permission information in the tenant, and this part of the permissions can be stored in the user's permission table or role table. After obtaining the source tenant role permissions and the user's own permissions, the system needs to merge the two. The basic strategy of merging is to follow the principle of permission superposition and the highest, that is, the permissions of the same resources and operations are subject to the more restrictive ones; permissions of different resources are directly superimposed. The merging process can be carried out by mapping permissions into bit vectors, and each bit of each vector represents a fine-grained permission point. By performing operations such as AND and OR operations on the vectors, the merged permission vector can be obtained. Finally, the permission vector calculated by merging is converted into an actual resource operation permission list to form the user's real-time permission data.

[0096] In the above embodiment, a permission inheritance mapping table is established to record the permission inheritance relationship between the source tenant and the target tenant, and a bidirectional mapping cache is used to store the mapping relationship between the source tenant role and the target tenant user and the mapping relationship between the target tenant user and the source tenant role. When the permission of the source tenant role changes, the system can quickly locate the affected set of target tenant users based on the first mapping table, and asynchronously push permission update messages through the message queue. When the target tenant user initiates permission verification, the system can quickly obtain the source tenant role information inherited by the user according to the second mapping table, and merge the current operation permission of the source tenant role with the target tenant user's own operation permission, so as to obtain accurate real-time permission data, improve the real-time and accuracy of permission data, reduce the response delay of the system, and improve the efficiency of permission management.

[0097] The first embodiment describes the basic process of a multi-tenant user management method that supports permission inheritance, including the establishment of permission inheritance relationships, the generation of a two-way mapping cache, the propagation of permission changes, and the implementation of permission verification. In order to further improve the security and controllability of the system, the present application also provides an optimization method based on authorization qualification management. This method implements more stringent and intelligent permission inheritance management by adding a source tenant qualification verification link before executing a role authorization request and combining it with a dynamic authorization behavior monitoring mechanism. Figure 2 , an optimization method based on authorization qualification management in an embodiment of the present application is described:

[0098] See also Figure 2 , which is a flow chart of an optimization method based on authorization qualification management in an embodiment of the present application.

[0099] S201, obtaining the authorization receiving configuration of the target tenant;

[0100] The system obtains the target tenant's authorization receiving configuration, which includes a whitelist of source tenants that are allowed to inherit receiving permissions.

[0101] Authorization receiving configuration is a strategy used by the target tenant to manage and restrict external permission inheritance, which contains a whitelist of source tenants that are allowed to receive permission inheritance. The whitelist records the list of source tenants that the target tenant trusts and can grant permissions to. By obtaining the authorization receiving configuration, the system can quickly determine whether the current authorization request comes from a source tenant recognized by the target tenant, and then perform the corresponding authorization processing.

[0102] The authorization reception configuration is usually set and maintained by the administrator of the target tenant. The system can provide a configuration management interface for the target tenant, and the administrator can flexibly define the authorization reception policy and whitelist through user-friendly interaction. For example, a tenant list is provided, allowing the administrator to check or manually enter the allowed source tenant identifiers. The system stores the configuration information persistently in a database or configuration file. When an authorization request is received, the system can quickly obtain the authorization reception configuration of the target tenant by accessing the storage medium. At the same time, the system can also design a caching mechanism for configuration information. After the configuration is obtained for the first time, it is cached in memory, and subsequent authorization requests directly access the cache, reducing frequent IO operations and improving authorization efficiency.

[0103] S202: When the source tenant is in the source tenant whitelist, verify the authorization qualification of the source tenant;

[0104] When the source tenant is in the source tenant whitelist, the system verifies the authorization qualification of the source tenant, specifically: reads the qualification level information of the source tenant, which is used to identify the scope of the source tenant's authorization capability;

[0105] Get the role information to be authorized in the role authorization request;

[0106] Match the role information with the source tenant's qualification level information;

[0107] When the role information does not exceed the authorization scope allowed by the qualification level, it is determined that the source tenant is qualified for authorization;

[0108] When the role information exceeds the authorization range allowed by the qualification level, the role authorization request is rejected.

[0109] After confirming that the source tenant belongs to the target tenant's whitelist, the system needs to further verify whether the source tenant has actual authorization qualifications. Authorization qualifications here refer to the scope and degree of authority that the source tenant can grant. By verifying authorization qualifications, the system can control the authorization behavior of the source tenant to prevent the source tenant from abusing authority or over-authorizing. The core basis for verification is the source tenant's qualification level information. The qualification level is the result of the system's classification and assessment of source tenants. Source tenants of different levels have different authorization capacity limits. The system compares the authorization content requested by the source tenant with its qualification level to determine whether the request is within its authority to determine the source tenant's authorization qualifications.

[0110] The qualification level information of the source tenant can be obtained in a variety of ways, such as manually assigned by the system administrator, or dynamically calculated based on the behavior of the source tenant. For the manual assignment method, the system can design a management interface that allows the administrator to set a level label for each source tenant and associate the level with the authorization scope. For the dynamic calculation method, the system can design a set of evaluation rules and algorithms to comprehensively consider factors such as the source tenant's registration information, usage time, and behavior records, and regularly evaluate the source tenant's level. The level calculation process can be completed through offline batch processing, and the results are synchronized to the online service. When verifying the authorization qualification, the system first compares whether the role requested by the source tenant is within the authorization scope corresponding to its level. This can be achieved by establishing a many-to-many mapping relationship between roles and levels, or using an authorization scope expression. If the request does not exceed the authorization scope, it passes the verification and continues the authorization process; otherwise, the authorization request is rejected and the corresponding error prompt is returned to the source tenant.

[0111] The verification of the source tenant's authorization qualifications may face two problems: untimely configuration updates and coarse authorization decision granularity. When the source tenant level changes or the authorization scope of the role is adjusted, the system needs to synchronize the latest mapping relationship to the authorization verification link in a timely manner. Otherwise, it may happen that the source tenant level has been upgraded, but the authorization cannot be completed. To address this problem, on the one hand, the system needs to design a complete configuration synchronization and monitoring mechanism to ensure the timeliness of the data on which the authorization decision depends; on the other hand, technical means such as version control or cache invalidation can be used to avoid the authorization verification module from using expired configuration data. In addition, authorization qualification control based on role granularity may not meet some complex requirements in actual business scenarios. The system can also consider introducing more fine-grained authorization evaluation methods, such as resource-based authorization application content, specific attributes of the source tenant, etc., and by defining a series of authorization decision rules, dynamic authorization qualification judgment deeply integrated with business logic can be realized to improve the flexibility and precision of authorization management.

[0112] S203, record the source tenant's authorization request time, authorization object, authorization content and verification result;

[0113] After completing the source tenant authorization qualification verification, regardless of whether the verification result is passed or rejected, the system needs to record the key information related to this authorization request. This information usually includes: the time when the authorization request was initiated, the identification of the authorization object, i.e. the target tenant, the authorization content, i.e. the role information requested, and the final authorization qualification verification result. Under the premise of legality and compliance, by fully recording the authorization request history, it is helpful for the system to trace back and audit the authorization behavior afterwards, discover potential authorization anomalies, and provide data support for the continuous optimization of authorization strategies. At the same time, these records can also serve as irrefutable evidence, providing evidence and basis when authorization disputes occur between tenants.

[0114] The system can use one or more tables in the database to store authorization request logs. The table structure needs to include fields such as timestamp, source tenant ID, target tenant ID, authorization role, and authorization qualification verification results. In order to facilitate post-analysis and problem location, the system can index key fields, such as using a combination of time and source tenant and target tenant as a composite index to speed up the retrieval of authorization history. Log writing can be performed synchronously with the authorization request, or asynchronously, sending the authorization request event to an independent logging service through a message queue to achieve decoupling of authorization processing and logging. Considering that the amount of data in the authorization log may be large, the system can also use the big data platform to perform offline analysis and mining of the log, and regularly generate authorization behavior reports and trend charts for administrators to monitor and analyze.

[0115] S204. Count the number of authorizations and the authorization success rate of the source tenant within a preset time window;

[0116] In this step, the system conducts statistical analysis on the authorization behavior of the source tenant within a preset time window. It mainly focuses on two indicators: one is the number of authorizations, that is, the total number of authorization requests initiated by the source tenant within the time window; the other is the authorization success rate, that is, the proportion of requests that successfully complete authorization through authorization qualification verification among these requests. By tracking the changing trends of these two indicators, the system can grasp the authorization behavior characteristics of the source tenants in real time and discover abnormal authorization attempts. For example, a large number of authorization requests are initiated continuously but the success rate is extremely low, which often means that the authorization behavior may be risky. Based on the authorization statistical data, the system can implement some policy controls, such as actively limiting the number of authorizations of abnormal source tenants, to achieve adaptive authorization management and control.

[0117] The statistics of the number of authorizations and the authorization success rate can be obtained by performing real-time or quasi-real-time aggregation calculations on the authorization request logs. When designing the system, it is necessary to balance real-time performance and computing costs. Technologies such as streaming computing or incremental computing can be considered to trigger calculations when new authorization requests arrive, and continuously update the statistical indicators of source tenants. Specifically, the system can maintain a counter in memory for each active source tenant, recording the total number of authorization requests and the number of successes. When a new authorization request comes in, the corresponding counter is updated according to the verification result. At the same time, the system also needs to regularly snapshot the counters and persist the statistical results to the database. On the one hand, this can avoid memory data loss. On the other hand, the database's aggregation function can be used to perform secondary statistics on the snapshot data by time window to obtain authorization behavior analysis results within a longer time span.

[0118] S205. When the number of authorizations exceeds a preset threshold or the authorization success rate is lower than a preset standard, reduce the authorization limit of the source tenant;

[0119] When the number of authorizations exceeds the preset threshold or the authorization success rate is lower than the preset standard, the system reduces the authorization limit of the source tenant. Specifically: read the current authorization limit of the source tenant;

[0120] Calculate the adjustment coefficient of the authorization limit based on the number of authorizations and the authorization success rate;

[0121] Multiply the current authorization limit by the adjustment coefficient to obtain the new authorization limit.

[0122] Based on the authorization statistics data of the source tenant obtained in the previous step, in this step, the system compares the statistical results with the preset monitoring thresholds and standards. Once it is found that the number of authorizations of the source tenant exceeds the preset upper limit of reasonable request quantity, or the authorization success rate is lower than expected, the system will automatically trigger the adjustment of the authorization limit and reduce the authorization quota of the source tenant. Here, the authorization limit refers to the upper limit of the number of authorization requests that the source tenant is allowed to initiate within a control period, or the maximum scope of permissions that can be granted. Through authorization limit control, the system can actively curb the abnormal authorization behavior of the source tenant, prevent a single tenant from exhausting the system's authorization resources, and can also timely reduce the authorization scope and lower the risk when the authorization qualification of the source tenant may not meet expectations.

[0123] The authorization times threshold and success rate standard can be configured by the system administrator based on experience, or reasonable control values can be automatically generated through machine learning of the historical behavior of the source tenant. When the authorization statistics of the source tenant trigger the threshold, the system can automatically modify the authorization configuration or send a warning to the administrator, suggesting that they adjust the authorization limit. Specifically, the adjustment range of the limit can be proportional to the degree of deviation from the threshold or standard. The greater the deviation, the greater the adjustment range. To achieve continuous controllability of the authorization limit, the system can also dynamically calculate the adjustment value of the authorization quantity through the PID control algorithm, which not only avoids the sudden stop of the authorization behavior but also can quickly converge when the abnormality intensifies. In addition, the system can set different limit control periods and inspection frequencies for different source tenants, conduct more frequent authorization statistics and shorter-period limit control for high-risk source tenants, while relaxing the control intensity for trustworthy source tenants to balance the system control cost and authorization risk.

[0124] S206: Only when the source tenant has the authorization qualification, execute the step of receiving the role authorization request of the source tenant.

[0125] Only when the source tenant has passed a series of authorization qualification checks, the system allows the actual role authorization logic to be entered and starts processing role authorization requests. The authorization qualification check here includes multiple dimensions: whether the source tenant is in the whitelist of the target tenant, whether the source tenant's qualification level matches the authorization role, whether the source tenant's authorization behavior exceeds the limit, etc. Only when the checks in all dimensions are passed can it be confirmed that the source tenant has legal and compliant authorization qualifications to avoid illegal abuse of the authorization process. Through the strong prior verification of authorization qualifications, the system builds a protective barrier that can effectively reduce the risk of illegal penetration of authorization requests, ensure the reliability of subsequent authorization behaviors, and maintain the effectiveness of the authorization mechanism of the multi-tenant system.

[0126] In the above embodiment, by introducing the authorization receiving configuration and the source tenant authorization qualification verification mechanism before receiving the role authorization request, precise control of the source of permission inheritance is achieved. The system limits the scope of source tenants allowed to receive permission inheritance through the whitelist mechanism, and strictly verifies the authorization qualifications of the source tenants to prevent unauthorized tenants from performing unauthorized operations. By conducting a qualification review before permission inheritance, the system can control the legitimacy of permission inheritance from the source, reduce the risk of permission leakage, and while ensuring the flexibility of permission inheritance, it also improves the security and controllability of the permission inheritance process, enhancing the security protection capabilities of the entire multi-tenant system.

[0127] The following describes the system in the embodiment of the present invention from the perspective of hardware processing. Figure 3 , which is a schematic diagram of the physical device structure of a multi-tenant user management system supporting permission inheritance provided in an embodiment of the present application.

[0128] It should be noted that Figure 3 The structure of the system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0129] like Figure 3 As shown, the system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 302 or the program loaded from the storage part 308 to the random access memory (RAM) 303, such as executing the method in the above embodiment. In RAM 303, various programs and data required for system operation are also stored. CPU 301, ROM 302 and RAM 303 are connected to each other through a bus 304. Input / output (I / O) interface 305 is also connected to bus 304.

[0130] The following components are connected to the I / O interface 305: an input section 306 including a camera, an infrared sensor, etc.; an output section 307 including a liquid crystal display (LCD) and a speaker, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as needed. A removable medium 311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 310 as needed so that a computer program read therefrom is installed into the storage section 308 as needed.

[0131] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 309, and / or installed from a removable medium 311. When the computer program is executed by the central processing unit (CPU) 301, various functions defined in the present invention are performed.

[0132] It should be noted that the computer-readable medium shown in the embodiment of the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. Among them, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0134] As another aspect, the present invention further provides a computer-readable storage medium, which may be included in the system described in the above embodiment; or may exist independently without being assembled into the system. The above storage medium carries one or more computer programs, and when the above one or more computer programs are executed by a processor of a system, the system implements the method provided in the above embodiment.

[0135] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[0136] As used in the above embodiments, the term "when..." may be interpreted as "if..." or "after..." or "in response to determining..." or "in response to detecting...", depending on the context. Similarly, the phrases "upon determining..." or "if (the stated condition or event) is detected" may be interpreted as "if determining..." or "in response to determining..." or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)", depending on the context.

[0137] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.

[0138] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. A multi-tenant user management method supporting permission inheritance, characterized in that: include: Receive a role authorization request from a source tenant, the role authorization request including identification information of a target tenant and role information to be authorized, the role information including a role identifier and an operation permission associated with the role identifier; A permission inheritance mapping table is created according to the role authorization request, and a permission inheritance relationship is written in the permission inheritance mapping table, wherein the permission inheritance relationship includes a source tenant identifier initiating the authorization, a target tenant identifier receiving the authorization, the role identifier, and an authorization time for establishing the permission inheritance relationship. The creation of the permission inheritance mapping table according to the role authorization request specifically includes: Collecting associated tenant information of the source tenant, wherein the associated tenant information includes a list of tenant identifiers that have a direct authority inheritance relationship with the source tenant; Constructing a tenant relationship directed graph based on the associated tenant information, wherein the nodes of the tenant relationship directed graph represent tenants, and the directed edges between the nodes represent permission inheritance relationships; When a circular inheritance path is detected in the tenant relationship directed graph, generating an alarm message; In the case where it is detected that the cyclic inheritance path does not exist in the tenant relationship directed graph, constructing a permission inheritance mapping table based on the inheritance relationship between the source tenant and the target tenant; Generate a bidirectional mapping cache including a first mapping table and a second mapping table, wherein the first mapping table is used to store a mapping relationship between a source tenant role and a target tenant user, and the second mapping table is used to store a mapping relationship between the target tenant user and the source tenant role, specifically including: Read all the permission inheritance relationships of the source tenant from the permission inheritance mapping table; Extracting user information of the target tenant for each permission inheritance relationship, where the user information includes a user identifier and user permissions; Filling the first mapping table according to the correspondence between the source tenant role and the target tenant user; Based on the corresponding relationship in the first mapping table, reversely construct a second mapping table to obtain a bidirectional mapping cache including the first mapping table and the second mapping table; When it is detected that the permission of the source tenant role has changed, querying the target tenant user set associated with the source tenant role based on the first mapping table; Constructing a permission update message for the target tenant user set, and asynchronously sending the permission update message to each user in the target tenant user set through a message queue; When receiving a permission verification request sent by a target tenant user, obtaining source tenant role information inherited by the target tenant user according to the second mapping table; The current operation permission of the source tenant role corresponding to the source tenant role information is combined with the operation permission of the target tenant user to obtain real-time permission data of the target tenant user.

2. The method according to claim 1, characterized in that Before receiving the role authorization request of the source tenant, the method further includes: Obtain the target tenant's authorization receiving configuration, where the authorization receiving configuration includes a source tenant whitelist that allows inheritance of receiving permissions; When the source tenant is in the source tenant whitelist, verifying the authorization qualification of the source tenant; The step of receiving the role authorization request of the source tenant is performed only when the source tenant has the authorization qualification.

3. The method according to claim 2, characterized in that The verifying the authorization qualification of the source tenant specifically includes: Reading the qualification level information of the source tenant, where the qualification level information is used to identify the authorized capability range of the source tenant; Obtaining the role information to be authorized in the role authorization request; Matching the role information with the qualification level information of the source tenant; When the role information does not exceed the authorization scope allowed by the qualification level, determining that the source tenant has the authorization qualification; When the role information exceeds the authorization range allowed by the qualification level, the role authorization request is rejected.

4. The method according to claim 2, characterized in that: After verifying the authorization qualification of the source tenant, the method further includes: Record the authorization request time, authorization object, authorization content and verification result of the source tenant; count the number of authorizations and authorization success rate of the source tenant within the preset time window; When the number of authorizations exceeds a preset threshold or the authorization success rate is lower than a preset standard, the authorization limit of the source tenant is reduced.

5. The method according to claim 4, characterized in that The reducing the authorization limit of the source tenant specifically includes: Read the current authorization limit of the source tenant; The adjustment coefficient of the authorization limit is calculated according to the number of authorizations and the authorization success rate; and the current authorization limit is multiplied by the adjustment coefficient to obtain a new authorization limit.

6. A multi-tenant user management system supporting permission inheritance, characterized in that: The system comprises: One or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the system to execute the method as described in any one of claims 1-5.

7. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on a system, the system is caused to execute the method according to any one of claims 1 to 5.

8. A computer program product, characterized in that When the computer program product is run on a system, the system is caused to execute the method according to any one of claims 1 to 5.

Images