A multi-tenant cross-tenant access method, system, device and medium

Abstract

The present invention discloses a cross-tenant access method, system, device, and medium for multi-tenant access, wherein the method comprises: S1 initializing the access control model in each tenant domain; S2 a gateway center determining the type of access request and forwarding the request to the corresponding module for processing; S3 verifying the access rights of the requesting user based on the tenant's internal access control model; S4 jointly processing the cross-tenant access request based on the cross-tenant mechanism and the tenant's internal access control model; S5 returning the corresponding resource based on the permission verification result. The present invention can realize cross-tenant access in multi-tenant applications, can meet the business needs of tenant collaboration, and is compatible with other access control models. The present invention can be widely used in the field of information security technology.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a multi-tenant cross-tenant access method, system, device and medium. Background Art

[0002] Cloud computing service models such as SaaS, PaaS, and IaaS typically provide cloud services to different tenants through a multi-tenant sharing model. However, while this multi-tenant model can reduce service delivery and software operating costs and increase revenue, it also requires data isolation to prevent interference between multiple tenants. Consequently, users can only access data within a single tenant domain. However, for large organizations with multiple tenant applications, cloud service resources can be used not only by the original tenant but also by users of other collaborating tenants. Cross-tenant data exchange among tenant applications in different business scenarios presents a challenge. Furthermore, cross-tenant data access must not disrupt existing tenant internal data access controls, which could impact the normal operation of multi-tenant applications. Therefore, the cross-tenant access mechanism must not only ensure the security of inter-tenant access in cross-tenant collaboration scenarios but also integrate with existing tenant internal access control models. Summary of the Invention

[0003] In order to at least solve one of the technical problems existing in the prior art to a certain extent, the present invention aims to provide a multi-tenant cross-tenant access method, system, device and medium.

[0004] The technical solution adopted in the present invention is:

[0005] A cross-tenant access method for multiple tenants includes the following steps:

[0006] S1 initializes the access control model in each tenant domain;

[0007] S2: The gateway center determines the type of access request and forwards the request to the corresponding module for processing: an ordinary user under a tenant application sends an access request, the gateway center receives the access request, and determines whether the requesting user belongs to the accessed tenant. If so, the access request belongs to intra-tenant access and the process proceeds to step S3; otherwise, the access request is considered a cross-tenant access and the process proceeds to step S4;

[0008] S3 verifies the access rights of the requesting user based on the tenant's internal access control model. For access within the same tenant domain, the tenant's internal access control policy function is directly called to perform the corresponding permission verification. It also determines whether the user has all or part of the permissions for the access request and outputs the result to step S5.

[0009] S4 The cross-tenant mechanism integrates and is compatible with the internal access control models of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center first needs to determine whether the tenant domain to which the requesting user belongs and the target tenant have established a valid cross-tenant mechanism. If so, the access request is forwarded to the target tenant for permission verification after cross-tenant verification, and then proceeds to step S3; otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong, and only after the cross-tenant mechanism is established can cross-tenant access to resources be performed; after verification is completed, the result is output to step S5;

[0010] S5 returns the corresponding resource based on the permission verification result: According to the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; otherwise, this user access is an illegal access, and the system automatically records this operation behavior in the log.

[0011] Furthermore, the initialization operation in step S1 includes initializing the access control policy in the access control model, allocating user rights, and configuring the access control model; each tenant domain has a set of default access control models, and after the tenant creates a tenant application, the tenant can select a different access control model.

[0012] Furthermore, the access request in step S2 includes a request identifier, the tenant to which the user belongs, the tenant to which the accessed resource belongs, an accessed resource identifier, etc.; the gateway center determines the type of user access based on the tenant to which the user belongs and the tenant to which the accessed resource belongs.

[0013] Furthermore, step S3 specifically includes:

[0014] Permission allocation within a tenant: There is a binary relationship between the Permissions set and the Users set in the tenant domain. There is a many-to-many relationship between users and permissions; one user can be assigned multiple permissions; one permission can be shared by multiple users. User-permission allocation within the tenant domain is configured by the tenant.

[0015] Tenant internal permission verification: Based on the tenant ID of the requesting user, obtain the user's permission set and perform a union of multiple permissions; determine whether the user has the access permission for this resource. If the user has the access permission for this resource, the user can continue to access the resource; otherwise, this access is considered an illegal access and the operation behavior is recorded in the log.

[0016] Furthermore, the cross-tenant mechanism in step S4 specifically includes:

[0017] The tenant domains involved in the cross-tenant process include the source tenant domain (the tenant domain to which the requesting user belongs) and the destination tenant domain (the tenant domain where the accessed resource is located);

[0018] The cross-tenant mechanism implementation process is as follows: the source tenant domain sends a cross-tenant access request to the destination tenant domain. After negotiation between the two parties, the destination tenant domain authorizes the given resources to the source tenant domain through the resource sharing mechanism. After the source tenant domain determines the resource sharing mechanism, it creates cross-tenant permissions for shared resources. Based on application requirements, the source tenant domain uses the permission mapping mechanism to map the permissions in the source tenant domain to the destination tenant domain, thereby realizing user allocation of cross-tenant permissions.

[0019] Furthermore, the resource sharing mechanism has the following characteristics:

[0020] The resource sharing mechanism is only applicable to resource sharing between tenants;

[0021] Resource sharing is unique and non-transferable;

[0022] The tenant to whom the resource belongs can terminate the authorization for the shared resource at any time.

[0023] Furthermore, the permission mapping mechanism has the following characteristics:

[0024] Tenants can configure permission mapping only when a specific resource sharing relationship exists between the tenant domain to which the resource belongs and the tenant domain to which the access user belongs.

[0025] Permission mapping is unique and non-transferable;

[0026] The platform will periodically maintain permission mapping relationships, detect and remove invalid mappings.

[0027] Another technical solution adopted in the present invention is:

[0028] A multi-tenant cross-tenant access system, comprising:

[0029] Initialization module, used to initialize the access control model in each tenant domain;

[0030] The access request module is used by the gateway center to determine the type of access request and forward the request to the corresponding module for processing: when an ordinary user under a tenant application sends an access request, the gateway center receives the access request and determines whether the requesting user belongs to the tenant being accessed. If so, the request enters the internal access module; otherwise, the request is regarded as a cross-tenant access and enters the cross-tenant access module;

[0031] The internal access module verifies the access rights of the requesting user based on the tenant's internal access control model. For access within the same tenant domain, the internal access control policy function is directly called to perform the corresponding permission verification. It also determines whether the user has all or part of the permissions for the access request and outputs the result to the resource return module.

[0032] The cross-tenant access module is used to integrate the cross-tenant mechanism and be compatible with the internal access control model of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center determines whether the tenant domain to which the requesting user belongs and the target tenant have established a cross-tenant mechanism. If so, the requesting user forwards the access request to the target tenant for permission verification after cross-tenant verification and then transfers it to the internal access module; otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong. Only after the cross-tenant mechanism is established can they access resources across tenants; after verification is completed, the result is output to the resource return module;

[0033] The resource return module is used to return the corresponding resource based on the permission verification result: According to the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; otherwise, the user access is considered an illegal access and the operation behavior is recorded in the log.

[0034] Another technical solution adopted in the present invention is:

[0035] A cross-tenant access device for multiple tenants, comprising:

[0036] at least one processor;

[0037] at least one memory for storing at least one program;

[0038] When the at least one program is executed by the at least one processor, the at least one processor implements the above method.

[0039] Another technical solution adopted in the present invention is:

[0040] A computer-readable storage medium stores a program executable by a processor, wherein the program executable by the processor is used to perform the method described above when executed by the processor.

[0041] The beneficial effects of the present invention are: the present invention can realize cross-tenant access in multi-tenant applications, can meet the business needs of tenant collaboration, and is compatible with other access control models. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following introduction is made to the drawings of the embodiments of the present invention or the related technical solutions in the prior art. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0043] Figure 1This is a flowchart of a cross-tenant access method for multiple tenants in an embodiment of the present invention;

[0044] Figure 2 is a schematic diagram of a cross-tenant mechanism provided in an embodiment of the present invention;

[0045] Figure 3 is a schematic diagram of a resource sharing mechanism provided in an embodiment of the present invention;

[0046] Figure 4 Schematic diagram of the permission mapping mechanism provided in an embodiment of the present invention;

[0047] Figure 5 This is a schematic diagram of a multi-tenant cross-tenant access system deployment according to an embodiment of the present invention;

[0048] Figure 6 This is an access control sequence diagram for a user requesting access to a resource in an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention. The step numbers in the following embodiments are provided for ease of explanation only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0050] In the description of the present invention, it should be understood that descriptions involving orientations, such as up, down, front, back, left, right, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on the present invention.

[0051] In the description of the present invention, "several" means one or more, "many" means more than two, "greater than," "less than," and "exceed" are understood to exclude the number itself, while "above," "below," and "within" are understood to include the number itself. The use of "first" and "second" in the description is solely for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, implicitly specifying the number of the indicated technical features, or implicitly specifying the order of the indicated technical features.

[0052] In the description of the present invention, unless otherwise clearly defined, terms such as setting, installing, and connecting should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in the present invention based on the specific content of the technical solution.

[0053] This embodiment provides a multi-tenant cross-tenant access method, such as Figure 1 As shown, the method includes the following steps:

[0054] S1. Initialize the access control model in each tenant domain;

[0055] S2. The gateway center determines the type of access request and forwards the request to the corresponding module for processing: A common user under a tenant application sends an access request. The gateway center receives the access request and determines whether the requesting user belongs to the tenant being accessed. If so, the access request is considered an intra-tenant access and the process proceeds to step S3. Otherwise, the access request is considered a cross-tenant access and the process proceeds to step S4.

[0056] S3. Verify the access rights of the requesting user based on the tenant's internal access control model: For access within the same tenant domain, directly call the tenant's internal access control policy function to perform the corresponding permission verification; and determine whether the user has all or part of the permissions for the access request, and output the result to step S5;

[0057] S4. The cross-tenant mechanism integrates and is compatible with the internal access control models of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center first needs to determine whether the tenant domain to which the requesting user belongs and the target tenant have established a valid cross-tenant mechanism. If so, the requesting user forwards the access request to the target tenant for permission verification after cross-tenant verification, and then proceeds to step S3. Otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong. Only after the cross-tenant mechanism is established can cross-tenant access to resources be performed. After verification is completed, the result is output to step S5.

[0058] S5. Return the corresponding resource based on the permission verification result: Based on the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; otherwise, the user access is considered an illegal access, and the system automatically records the operation behavior in the log.

[0059] In this embodiment, users can be divided into tenants and ordinary users. Among them, tenants can be individuals, enterprises, and organizations that use cloud services, denoted as Tenants = {t1, t2, ..., t n}, is the administrator of the tenant application, which is used to control resource access, user management, access control, etc. in the entire tenant domain; ordinary users are users under the tenant application, recorded as Users = {u1,u2,…,un}, is the subject that accesses tenant resources. Each ordinary user belongs to a unique tenant, and a tenant can have multiple ordinary users. Ordinary users access resources in the tenant domain based on the permissions assigned by the tenant and perform related business processing using the functional components provided by the tenant. Since ordinary users can have permissions in other tenants and access resources in other tenant domains across tenants, unlike traditional web application permissions, user permissions in the cross-tenant access mechanism are represented as a matrix P that stores tenant-user-permissions, which is defined as follows:

[0060]

[0061] Where n represents the total number of tenant domains, m represents the total number of common users; P ij represents the permissions of the jth user in the i-th tenant domain. The permission set of the user numbered i is {P 1i ∨P 2i ∨…∨P ni}.

[0062] In this embodiment, the initialization operation described in step S1 includes initializing the access control policy in the access control model, allocating user permissions, and configuring the access control model; each tenant domain has a set of default access control models, and after the tenant creates a tenant application, the tenant can select a different access control model.

[0063] In this embodiment, the user access request described in step S2 includes the request identifier, the user's tenant, the access resource's tenant, the access resource identifier, etc.; the gateway center determines the user access type based on the user's tenant and the access resource's tenant.

[0064] In this embodiment, the tenant internal access control to which step S3 belongs specifically includes:

[0065] (1) Permission allocation within a tenant: There is a binary relationship between the permission set Permissions and the user set Users in the tenant domain. There is a many-to-many relationship between users and permissions. One user can be assigned multiple permissions; one permission can be shared by multiple users; user-permission allocation within the tenant domain is customized by the tenant.

[0066] (2) Internal tenant permission verification: According to the tenant ID of the requesting user, obtain the user's permission set and take the union of multiple permissions; then determine whether the user has the access permission.

[0067] In this embodiment, the tenant domains involved in the cross-tenant process described in step S4 include the source tenant domain (the tenant domain to which the requesting user belongs) and the destination tenant domain (the tenant domain where the accessed resource is located). Figure 2As shown, the cross-tenant mechanism specifically includes: the source tenant domain sends a cross-tenant access request to the destination tenant domain. After negotiation between the two parties, the destination tenant domain authorizes the given resources to the source tenant domain through the resource sharing mechanism; after the source tenant domain completes the sharing through the resource sharing mechanism, it creates cross-tenant permissions for the shared resources; based on application requirements, the source tenant domain uses the permission mapping mechanism to map the permissions in the source tenant domain to the destination tenant domain to realize user allocation of cross-tenant permissions.

[0068] In this embodiment, to support tenants sharing resources at multiple levels and granularities, the sharing levels of the resource sharing mechanism described in step S4 can be divided into the following three categories:

[0069] (1) public: Shares the given resource with all tenants, which is the highest degree of sharing and has certain security risks;

[0070] (2) protected: Shares a given resource with a specified list of tenants. The degree of sharing is set by the tenants, which can prevent data leakage to a certain extent;

[0071] (3) Private: Indicates that the resource is privately owned by the tenant and is not shared with other tenants.

[0072] In this embodiment, Figure 3 As shown, the resource sharing mechanism described in step S4 also has the following characteristics:

[0073] (1) The resource sharing mechanism is only applicable to resource sharing between tenants;

[0074] (2) Resource sharing is unique and non-transferable;

[0075] (3) The tenant to whom the resource belongs can terminate the authorization for the shared resource at any time.

[0076] In this embodiment, Figure 4 As shown, the permission mapping mechanism described in step S4 has the following characteristics:

[0077] (1) A tenant can configure permission mapping only if there is a specific resource sharing relationship between the tenant domain to which the resource belongs and the tenant domain to which the access user belongs.

[0078] (2) Permission mapping is unique and non-transferable;

[0079] (3) The platform will periodically maintain permission mapping relationships and detect and remove invalid mappings.

[0080] In summary, the method of this embodiment has the following advantages and beneficial effects compared to the prior art:

[0081] (1) The present invention introduces resource sharing and permission mapping mechanisms into the access control model, so that ordinary users under one tenant application can access resources in other tenant domains after cross-tenant authorization and authentication, thereby meeting the needs of multi-tenant collaboration.

[0082] (2) The present invention is applicable to tenant collaboration business scenarios of multi-tenant application cloud platforms. It splits cross-tenant access control into the construction of cross-tenant mechanisms and tenant internal access control. It does not limit the specific implementation of the access control model in the tenant domain, and meets the diverse needs in the cloud environment.

[0083] (3) The cross-tenant access method provided by the present invention has the characteristics of flexible model configuration and reasonable mechanism implementation. Based on this method, the traditional access control model can be further expanded to adapt to the access control of multi-tenant applications.

[0084] like Figure 5 As shown, the embodiment of the present invention further proposes a multi-tenant cross-tenant access system, including:

[0085] Gateway Center: Responsible for format verification and request forwarding of user access requests. Format verification mainly verifies the parameters of user access requests, and request forwarding forwards the access request to the corresponding tenant domain to perform access control based on the tenant to which the user belongs.

[0086] Resource sharing module: Responsible for resource sharing between tenant domains. Tenants use this module to authorize the sharing of given resources with other tenants, enabling resource sharing among multiple tenants and serving as the basis for cross-tenant access.

[0087] Permission mapping module: responsible for permission mapping between tenants that have established resource sharing relationships. Through this module, permissions between tenants can be allocated by level and by resource.

[0088] Tenant internal access control module: responsible for access control of the tenant domain and verifies whether the requesting user has access rights to the corresponding resources;

[0089] Log module: records illegal access behaviors of users during cross-tenant access;

[0090] User module: manages users in each tenant domain.

[0091] In this embodiment, each module operates according to a multi-tenant cross-tenant access method.

[0092] Specifically, if Figure 6As shown in the figure, the system operation process is as follows: the user in the user management module initiates a resource access request, the gateway center verifies the access request, and directly rejects the access request if the format is incorrect. Otherwise, the access request is forwarded according to the access type; the tenant internal access control module receives access within the tenant domain and performs permission detection on the access request; cross-tenant access builds a cross-tenant mechanism through the resource sharing module and the permission mapping module, and then sends it to the corresponding tenant domain to perform access control; the log module records the user's illegal access to resources.

[0093] An embodiment of the present invention further provides a multi-tenant cross-tenant access system, including:

[0094] Initialization module, used to initialize the access control model in each tenant domain;

[0095] The access request module is used by the gateway center to determine the type of access request and forward the request to the corresponding module for processing: when an ordinary user under a tenant application sends an access request, the gateway center receives the access request and determines whether the requesting user belongs to the tenant being accessed. If so, the request enters the internal access module; otherwise, the request is regarded as a cross-tenant access and enters the cross-tenant access module;

[0096] The internal access module verifies the access rights of the requesting user based on the tenant's internal access control model. For access within the same tenant domain, the internal access control policy function is directly called to perform the corresponding permission verification. It also determines whether the user has all or part of the permissions for the access request and outputs the result to the resource return module.

[0097] The cross-tenant access module is used to integrate the cross-tenant mechanism and be compatible with the internal access control model of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center determines whether the tenant domain to which the requesting user belongs and the target tenant have established a cross-tenant mechanism. If so, the requesting user forwards the access request to the target tenant for permission verification after cross-tenant verification and then transfers it to the internal access module; otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong. Only after the cross-tenant mechanism is established can they access resources across tenants; after verification is completed, the result is output to the resource return module;

[0098] The resource return module is used to return the corresponding resource based on the permission verification result: According to the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; otherwise, the user access is considered an illegal access and the operation behavior is recorded in the log.

[0099] A cross-tenant access system for multiple tenants in this embodiment can execute a cross-tenant access method for multiple tenants provided by the method embodiment of the present invention, can execute any combination of implementation steps of the method embodiment, and has the corresponding functions and beneficial effects of the method.

[0100] An embodiment of the present invention further provides a multi-tenant cross-tenant access device, comprising:

[0101] at least one processor;

[0102] at least one memory for storing at least one program;

[0103] When the at least one program is executed by the at least one processor, the at least one processor implements Figure 1 The method shown.

[0104] A cross-tenant access device for multiple tenants in this embodiment can execute a cross-tenant access method for multiple tenants provided by the method embodiment of the present invention, can execute any combination of implementation steps of the method embodiment, and has the corresponding functions and beneficial effects of the method.

[0105] The present application also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs Figure 1 The method shown.

[0106] This embodiment also provides a storage medium storing instructions or programs that can execute a multi-tenant cross-tenant access method provided by an embodiment of the method of the present invention. When the instructions or program are run, any combination of implementation steps of the method embodiment can be executed, and the corresponding functions and beneficial effects of the method can be obtained.

[0107] In some optional embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operation and logic flow presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0108] Furthermore, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise indicated, one or more of the functions and / or features described may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It will also be understood that a detailed discussion of the actual implementation of each module is not necessary for understanding the present invention. More specifically, given the properties, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the module will be understood within the ordinary skill of an engineer. Therefore, a person skilled in the art using ordinary skill will be able to implement the present invention set forth in the claims without undue experimentation. It will also be understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0109] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0110] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0111] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering, or processing in another suitable manner as necessary, and then stored in a computer memory.

[0112] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0113] In the above description of this specification, reference to the terms "one embodiment / example," "another embodiment / example," or "certain embodiments / examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0114] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the claims and their equivalents.

[0115] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A cross-tenant access method for multiple tenants, characterized in that: The following steps are involved: S1. Initialize the access control model in each tenant domain; S2. The gateway center determines the type of access request and forwards the request to the corresponding module for processing: A common user under a tenant application sends an access request. The gateway center receives the access request and determines whether the requesting user belongs to the tenant being accessed. If so, the process proceeds to step S3. Otherwise, the access request is considered a cross-tenant access and the process proceeds to step S4. S3. Verify the access rights of the requesting user based on the tenant's internal access control model: For access within the same tenant domain, directly call the tenant's internal access control policy function to perform the corresponding permission verification; And determine whether the user has all / part of the permissions for the access request, and output the result to step S5; S4. The cross-tenant mechanism integrates and is compatible with the internal access control models of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center determines whether the tenant domain to which the requesting user belongs and the target tenant have established a cross-tenant mechanism. If so, the requesting user forwards the access request to the target tenant for permission verification after cross-tenant verification, and then proceeds to step S3; Otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong. Only after the cross-tenant mechanism is established can they access resources across tenants. After the verification is completed, the result is output to step S5; S5. Return the corresponding resource based on the permission verification result: Based on the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; Otherwise, the user access is considered illegal and the operation will be recorded in the log; Step S3 specifically includes: Permission allocation within a tenant: There is a binary relationship between the Permissions set and the Users set in the tenant domain. There is a many-to-many relationship between users and permissions; one user can be assigned multiple permissions; one permission can be shared by multiple users. User-permission allocation within the tenant domain is configured by the tenant. Tenant internal permission verification: Based on the tenant ID of the requesting user, obtain the user's permission set and perform a union of multiple permissions; determine whether the user has the access permission for this resource. If the user has the access permission for this resource, the user can continue to access the resource; otherwise, this access is considered illegal and the operation behavior is recorded in the log; The cross-tenant mechanism in step S4 includes: The tenant domains involved in the cross-tenant process include the source tenant domain and the destination tenant domain; The cross-tenant mechanism is implemented as follows: the source tenant domain sends a cross-tenant access request to the destination tenant domain. After negotiation, the destination tenant domain authorizes the given resources to the source tenant domain through the resource sharing mechanism. After the resource sharing mechanism is determined, the source tenant domain creates cross-tenant permissions for the shared resources. Based on application requirements, the source tenant domain uses the permission mapping mechanism to map the permissions in the source tenant domain to the destination tenant domain, thus implementing user allocation of cross-tenant permissions. The sharing levels of resource sharing mechanisms are divided into the following three categories: (1) public: Shares the given resource with all tenants. This is the highest degree of sharing, but it also poses certain security risks. (2) protected: Shares a given resource with a specified list of tenants. The degree of sharing is set by the tenants, which can prevent data leakage to a certain extent; (3) private: indicates that the resource is privately owned by the tenant and is not shared with other tenants; The resource sharing mechanism also has the following characteristics: (1) The resource sharing mechanism is only applicable to resource sharing between tenants; (2) Resource sharing is unique and non-transferable; (3) The tenant to whom the resource belongs can terminate the authorization for the shared resource at any time; The permission mapping mechanism has the following characteristics: (1) A tenant can configure permission mapping only if a specific resource sharing relationship exists between the tenant domain to which the resource belongs and the tenant domain to which the accessing user belongs. (2) Permission mapping is unique and non-transferable; (3) The platform will periodically maintain permission mapping relationships and detect and remove invalid mappings.

2. A multi-tenant cross-tenant access method according to claim 1, characterized in that: The initialization operation in step S1 includes initializing the access control policy in the access control model, allocating user permissions, and configuring the access control model. Each tenant domain has a default access control model. After a tenant creates a tenant application, the tenant can select a different access control model.

3. A multi-tenant cross-tenant access method according to claim 1, characterized in that: The access request in step S2 includes a request identifier, a tenant to which the user belongs, a tenant to which the accessed resource belongs, and an accessed resource identifier; the gateway center determines the type of user access based on the tenant to which the user belongs and the tenant to which the accessed resource belongs.

4. A multi-tenant cross-tenant access system, applied to a multi-tenant cross-tenant access method according to any one of claims 1 to 3, characterized in that: include: Initialization module, used to initialize the access control model in each tenant domain; The access request module is used by the gateway center to determine the type of access request and forward the request to the corresponding module for processing: when an ordinary user under a tenant application sends an access request, the gateway center receives the access request and determines whether the requesting user belongs to the tenant being accessed. If so, the request enters the internal access module; otherwise, the request is regarded as a cross-tenant access and enters the cross-tenant access module; The internal access module is used to verify the access rights of the requesting user based on the tenant's internal access control model: for access within the same tenant domain, the tenant's internal access control policy function is directly called to perform the corresponding permission verification; And determine whether the user has all / part of the permissions for the access request, and output the result to the resource return module; The cross-tenant access module is used to integrate the cross-tenant mechanism and be compatible with the internal access control model of each tenant to process cross-tenant access requests: For cross-tenant access, the multi-tenant access control center determines whether the tenant domain to which the requesting user belongs and the target tenant have established a cross-tenant mechanism. If so, the requesting user will be forwarded to the target tenant for permission verification after cross-tenant verification, and then transferred to the internal access module; Otherwise, the requesting user needs to submit a cross-tenant application to the tenant domain to which they belong. Only after the cross-tenant mechanism is established can they access resources across tenants. After verification is completed, the results are output to the resource return module; The resource return module is used to return the corresponding resource based on the permission verification result: According to the permission verification result, if the requesting user has full / partial access rights to the specified resource, the user can obtain the corresponding resource; otherwise, the user access is considered an illegal access and the operation behavior is recorded in the log.

5. A cross-tenant access device for multiple tenants, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method according to any one of claims 1 to 3.

6. A computer-readable storage medium storing a program executable by a processor, characterized in that: The processor-executable program is used to perform the method according to any one of claims 1 to 3 when executed by the processor.

Images