Method and system for implementing sso unified authentication for multi-tenancy

Abstract

The present disclosure provides a method and system for SSO unified authentication implementation for multi-tenancy, comprising: a data configuration service module configured to receive configuration data for tenants, users under the tenants, and SSO authentication proxy service modules, and use internal accounts to issue the configuration data to an IAM system module; wherein each tenant is associated with an sso-proxy client connected thereto; an SSO authentication proxy service module configured to request configuration information corresponding to a tenant to be authenticated from the IAM system module in response to an authentication request of the tenant, and return a tenant application to the user based on a token fed back by the IAM system module and the configuration information, and display a home page of the tenant application; and an IAM system module configured to receive a request for forwarding access requested by the SSO authentication proxy service module, and return a token to the SSO authentication proxy service module after a verification and authorization code process is passed.

Description

Technical Field

[0001] This disclosure belongs to the field of computer technology, and in particular relates to a method and system for implementing unified SSO authentication for multi-tenancy. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] In various cloud computing application scenarios, if it is necessary to integrate an IAM (Identity and Access Management) system for unified identity, credential, and access management based on the OpenID Connect (OIDC) protocol, each tenant application needs to manually apply on the cloud platform, obtain the parameters of the interface client, and then inject them into the application before it can be used, which involves a lot of manual operations. If tenant applications are developed using different languages, the same functions need to be repeatedly developed, and the corresponding language libraries are needed to complete the complex SSO process interaction. In addition, with the isolation of tenant data and user data, users under different tenants cannot use different APIs to divide API resources for tenants, and cannot effectively control the application authentication under specific tenants. At the same time, the existing implementation mechanism requires the implementation / modification of multiple basic services. The implementation details need to meet the following requirements: the IAM system needs to implement combined isolation; user and client data under different tenants need to be logically or physically isolated; the authentication entry URLs of different tenants need to be explicitly distinguished; and the SSO-Proxy service and the applications of each tenant need to provide security measures such as two-way authentication or API signature, which is quite complex to implement. Summary of the Invention

[0004] To address the aforementioned issues, this disclosure provides a unified SSO authentication implementation method and system for multi-tenant environments. The solution is based on IAM, Provisioning service, and SSO-Proxy components to implement SSO authentication in multi-tenant scenarios. It solves the problems of tenant API resource isolation, user data management, and how tenant applications can connect in cloud computing scenarios. Applications from different tenants can connect to the same SSO-Proxy service and complete authentication integration without needing to be aware of complex SSO process interactions. At the same time, users under different tenants are isolated from each other, and after completing SSO authentication, the corresponding application under the tenant can be accurately and quickly returned.

[0005] According to a first aspect of the present invention, a unified authentication implementation system for multi-tenant SSO is provided, comprising:

[0006] The data configuration service module is used to receive configuration data for tenants, users under tenants, and the attributes of the SSO authentication proxy service module, and to distribute the configuration data to the IAM system module using internal accounts; each tenant is associated with an sso-proxy client.

[0007] The SSO authentication proxy service module is used to respond to the authentication request of the tenant, request the configuration information corresponding to the tenant to be authenticated from the IAM system module, and return the tenant application to the user based on the token fed back by the IAM system module and the configuration information, and display the homepage of the tenant application.

[0008] The IAM system module receives requests from the SSO authentication proxy service module to forward access, verifies the authorization code, and returns a token to the SSO authentication proxy service module after the verification process is successful.

[0009] Furthermore, when a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module.

[0010] Furthermore, requesting the configuration information corresponding to the tenant to be authenticated from the IAM system module specifically involves obtaining the address of the authentication request and the client information of the SSO authentication proxy service module corresponding to the IAM system module. The client information includes the client ID, client key, token application address, and callback address.

[0011] Furthermore, the data configuration service module is also used to register an SSO-proxy client for each tenant and to cache client information for each tenant locally.

[0012] Furthermore, the SSO authentication proxy service module is also used to detect whether the user is logged in. If the user is not logged in, the system redirects to the login interface of the IAM system module and returns to the tenant's application homepage after successful login; if the user is already logged in, the system directly returns to the tenant's application homepage.

[0013] Furthermore, the tenant's web system proxies SSO authentication requests through the data configuration service module.

[0014] According to a second aspect of the present invention, a method for implementing unified SSO authentication for multi-tenancy is provided, which is based on the aforementioned unified SSO authentication system for multi-tenancy, the method comprising:

[0015] When a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module.

[0016] The SSO authentication proxy service module requests the configuration information corresponding to the tenant to be authenticated from the IAM system module, and determines whether the authentication is successful based on the token returned by the IAM system module. If the authentication is successful, the user is returned the tenant application based on the obtained configuration information, and the homepage of the tenant application is displayed.

[0017] According to a third aspect of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and running on the memory, wherein the processor executes the program to implement the aforementioned SSO unified authentication implementation method for multi-tenancy.

[0018] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the aforementioned method for implementing unified authentication for multi-tenant SSO.

[0019] Compared with the prior art, the beneficial effects of this disclosure are:

[0020] (1) This disclosure provides a unified SSO authentication implementation method and system for multi-tenant applications. The solution is based on IAM, Provisioning service and SSO-Proxy components to realize SSO authentication in multi-tenant scenarios. It solves the problems of tenant API resource isolation, user data management and how tenant applications can be connected in cloud computing scenarios. Applications of different tenants can connect to the same set of SSO-Proxy services. Authentication integration can be completed without being aware of the complex SSO process interaction. At the same time, users under different tenants are isolated from each other. After completing SSO authentication, the application under the corresponding tenant can be accurately and quickly returned.

[0021] (2) In this scheme, for tenant API resources defined on IAM, the Provisioning service ensures that SSO-Proxy clients are automatically detected, created, and maintained for each tenant. When a new tenant needs to be created, configuration data is submitted through the Provisioning service's interface. The Provisioning service performs data validity checks and checks whether the current policy configuration exceeds system specifications or license limitations. Upon successful detection, it asynchronously notifies IAM to create the tenant data. Additionally, the Provisioning service creates corresponding tenant resources and policy restrictions. This ensures that each tenant is allocated different API resources and has an internal account, allowing applications that the tenant needs to connect to communicate with IAM. The Provisioning service also creates monitoring tasks on IAM and starts timers to periodically track authentication statistics for tenant applications. When an application under a tenant requests authentication from IAM, IAM obtains the tenant information created by the Provisioning service client and distinguishes the API resources available to the tenant. Simultaneously, it obtains the corresponding SSO client connection attributes for user login authentication. In real-time, it collects metrics such as the number of authentication requests, request time, and request success or failure, and notifies applications that have subscribed to this data through the Provisioning service. The Provisioning service receives data reported by IAM and can control policies through internal policy configuration, notifying IAM to execute them promptly. For example, it can determine whether to revoke or grant authentication for a tenant's application, whether to block access from a logged-in user's IP address, or whether a user's account has been disabled.

[0022] (3) The proposed scheme allows users under different tenants to be authenticated through a unified authentication entry point, provided that tenant data and user data are isolated.

[0023] Advantages of this disclosure in additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0024] The accompanying drawings, which form part of this disclosure, are used to provide a further understanding of this disclosure. The illustrative embodiments of this disclosure and their descriptions are used to explain this disclosure and do not constitute an undue limitation of this disclosure.

[0025] Figure 1 This is a schematic diagram of the structure of a unified authentication system for multi-tenancy SSO as described in an embodiment of this disclosure;

[0026] Figure 2 This is a flowchart illustrating the SSO login process for a user under a tenant in a multi-tenant SSO unified authentication implementation method described in this embodiment of the present disclosure. Detailed Implementation

[0027] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0028] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0029] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0030] Where there is no conflict, the embodiments and features described herein can be combined with each other.

[0031] Example 1:

[0032] The purpose of this embodiment is to provide a unified authentication implementation system for multi-tenant SSO.

[0033] A unified authentication implementation system for multi-tenancy SSO includes:

[0034] The data configuration service module is used to receive configuration data for tenants, users under tenants, and the attributes of the SSO authentication proxy service module, and to distribute the configuration data to the IAM system module using internal accounts; each tenant is associated with an sso-proxy client.

[0035] The SSO authentication proxy service module is used to respond to the authentication request of the tenant, request the configuration information corresponding to the tenant to be authenticated from the IAM system module, and return the tenant application to the user based on the token fed back by the IAM system module and the configuration information, and display the homepage of the tenant application.

[0036] The IAM system module receives requests from the SSO authentication proxy service module to forward access, verifies the authorization code, and returns a token to the SSO authentication proxy service module after the verification process is successful.

[0037] In practice, when a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module.

[0038] In specific implementation, requesting the configuration information corresponding to the tenant to be authenticated from the IAM system module specifically involves obtaining the address of the authentication request and the client information of the SSO authentication proxy service module corresponding to the IAM system module. The client information includes the client ID, client key (clientSecret), token application address, and callback address.

[0039] In practice, the data configuration service module is also used to register an SSO-proxy client for each tenant and to cache client information for each tenant locally.

[0040] In specific implementation, the SSO authentication proxy service module is also used to detect whether the user is logged in. If the user is not logged in, the system redirects to the login interface of the IAM system module and returns to the tenant's application homepage after successful login; if the user is already logged in, the system directly returns to the tenant's application homepage.

[0041] In practice, the tenant's web system proxies the SSO authentication request through the data configuration service module.

[0042] For ease of understanding, the solution described in this embodiment will be explained in detail below with reference to the accompanying drawings:

[0043] The solution described in this embodiment mainly involves the following components:

[0044] IAM system (i.e., Identity and Access Management System, hereinafter referred to as IAM system module)

[0045] Provisioning service (IAM data configuration service module)

[0046] SSO-Proxy (SSO Authentication Proxy Service Module)

[0047] The following provides a detailed description of each module:

[0048] (1) IAM system

[0049] Identity and Access Management (IAM) systems are common infrastructure components that provide access control and authentication functions, and are also a secure and reliable solution that can be integrated into various platforms.

[0050] Tenant isolation is implemented on IAM, where tenants can also be abstracted as organizations / companies. API resources are defined for each tenant, and logical isolation is achieved at the API level. Within each tenant, personnel within the organization / company are created independently, without awareness of each other. Administrators for each tenant are responsible for managing the user, role, and permission definitions within their respective organizations.

[0051] For example, the authentication URL for organization A is: https: / / iam.domain / tenants / orgA / auth

[0052] For example, the authentication URL for organization B is: https: / / iam.domain / tenants / orgB / auth

[0053] Individuals within organization A cannot authenticate using the authentication URL of organization B, and similarly, individuals within organization B cannot authenticate using the authentication URL of organization A. Users within an organization can use standard authentication protocols such as OpenID Connect, SAML, and OAuth2.

[0054] (2) SSO-Proxy

[0055] SSO, short for Single Sign-On, is an authentication method that allows users to securely access multiple related applications and services by logging into a session once with a set of credentials and then logging in again during that session without needing to log in again. SSO is commonly used to manage authentication in various environments, including corporate intranets or extranets, public cloud services, and other environments where users need to use multiple applications to complete tasks.

[0056] For SSO authentication based on OpenID Connect, a fixed-format token issuance URL needs to be explicitly specified. Different tenants require different URLs for authentication. If the integrated application services use different backend languages ​​(Java / Python / Go, etc.), each needs to implement a similar integration process, requiring the current tenant's authentication URL, the client's ClientID, and Secret information during authentication. From a requirements perspective, providing a unified SSO proxy backend is ideal. The details related to proxy authentication do not need to be implemented by individual applications. This greatly simplifies code complexity and improves component reusability. SSO-Proxy provides these functionalities.

[0057] (3) Provisioning service

[0058] This service provides a series of API interfaces for system administrators to generate, verify, and distribute IAM configuration data. Through this service, system administrators can use a GUI-based visual interface for data configuration and maintenance. Normally, it allows the creation of different tenants, tenant-assigned users, user roles, and other information. Especially when each tenant has web applications requiring authentication, it can create interface application information to ensure that users can correctly return to the corresponding web application after successful login authentication.

[0059] like Figure 1 As shown, the specific steps performed by each module of a multi-tenant SSO unified authentication implementation system are as follows:

[0060] Step 1: The system administrator configures tenant data and users under each tenant using a GUI tool / configuration file. Simultaneously, the SSO-Proxy interface attributes are defined, including authentication request parameters such as clientId, clientSecret (client secret), issuer (token request address), and redirect_url (callback address).

[0061] Step 2: The Provisioning service uses an internal account to send configuration data to IAM. This service ensures that each newly created tenant has a connected SSO-proxy client. The tenant's own web system can use this service to proxy SSO authentication requests.

[0062] Step 3: After changes occur in the IAM data, update notifications should be received, and data synchronization should be performed. Necessary data statistics should also be available. Data changes include the following categories:

[0063] Regarding the tenant's application connection status, when a connection used by a tenant application is interrupted or reconnected, IAM needs to send asynchronous messages to the Provisioning service to control the policy. This determines whether to allow continuous retries or direct interruption, and the Provisioning service sends an alert message externally. Other monitoring applications subscribe to this message and register the anomaly in the logs or send SMS alerts.

[0064] When tenant data on IAM is modified, such as manual changes or modifications to configuration data like client parameters, the Provisioning service needs to be notified asynchronously to change the policy, thus avoiding the use of the old policy for control.

[0065] The tenant application's anomaly statistics include the number of currently authenticated users, the IP addresses of each user, and whether there is any abnormal attack traffic. The provisioning service implements policies such as anomaly traffic control and concurrent traffic control to ensure the security of the entire authentication process.

[0066] IAM can send notifications to the Provisioning service either via asynchronous HTTP interface or via message queues, which the Provisioning service can subscribe to and execute.

[0067] Step 4: Various applications under the tenant directly connect to the SSO-Proxy server, and ordinary users can be authenticated through the SSO-Proxy service when accessing the tenant's applications.

[0068] Step 5: The SSO-Proxy service checks if the user is logged in. If not, the system redirects to the IAM login page. Upon successful login, the user is returned to the tenant's application homepage. If the user is already logged in, the system directly returns to the tenant's application homepage.

[0069] The following example uses SSO login under a tenant to further illustrate the solution described in this embodiment. Figure 2 As shown, the user login process from a tenant's perspective includes the following steps:

[0070] Step 1: Users under tenant A access the web application under tenant A.

[0071] Step 2: Tenant A's application detects that the user is not logged in and requests the SSO-Proxy service to obtain a list of available tenants to display to the user. The user correctly selects Tenant A on the interface and clicks the SSO login button to apply for authentication.

[0072] Step 3: The SSO-Proxy service receives tenant A's authentication request, requests tenant information from IAM, obtains the authentication request address, and its corresponding client information on the IAM side (including clientId, clientSecret, issuer (token request address), redirect_url callback address, and other authentication request parameters). Then, it proceeds with the authorization code authentication process.

[0073] Step 4: After IAM completes the necessary verification and authorization code process, it returns a token to SSO-Proxy.

[0074] Step 5: After SSO-Proxy verifies that the authentication is successful, it returns the application to tenant A and then displays the application's homepage to the user.

[0075] Example 2:

[0076] The purpose of this embodiment is to provide a unified authentication method for multi-tenant SSO.

[0077] A method for implementing unified SSO authentication for multi-tenancy, based on the aforementioned unified SSO authentication system for multi-tenancy, the method comprising:

[0078] When a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module.

[0079] The SSO authentication proxy service module requests the configuration information corresponding to the tenant to be authenticated from the IAM system module, and determines whether the authentication is successful based on the token returned by the IAM system module. If the authentication is successful, the user is returned the tenant application based on the obtained configuration information, and the homepage of the tenant application is displayed.

[0080] Example 3:

[0081] The purpose of this embodiment is to provide an electronic device.

[0082] An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the memory. When the processor executes the program, it implements the aforementioned method for implementing unified authentication (SSO) for multi-tenancy.

[0083] Example 4:

[0084] The purpose of this embodiment is to provide a non-transitory computer-readable storage medium.

[0085] A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned SSO unified authentication implementation method for multi-tenancy.

[0086] The above embodiments provide a unified SSO authentication implementation method and system for multi-tenant systems, which can be implemented and has broad application prospects.

[0087] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A unified authentication implementation system for multi-tenant SSO, characterized in that, include: The data configuration service module is used to receive configuration data for tenants, users under tenants, and the attributes of the SSO authentication proxy service module, and to distribute the configuration data to the IAM system module using internal accounts; each tenant is associated with an sso-proxy client. When a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it retrieves and displays a list of tenants within the cloud platform based on the SSO authentication proxy service module, receives the user's selection of their corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module. The SSO authentication proxy service module responds to tenant authentication requests by requesting configuration information corresponding to the tenant to be authenticated from the IAM system module. Based on the token returned by the IAM system module and the configuration information, it returns the tenant application to the user and displays the homepage of the tenant application. Specifically, requesting the configuration information corresponding to the tenant to be authenticated from the IAM system module involves obtaining the address of the authentication request and the SSO-proxy client information corresponding to the IAM system module. The client information includes the client ID, client key, token request address, and callback address. The IAM system module receives requests from the SSO authentication proxy service module to forward access, verifies the authorization code, and returns a token to the SSO authentication proxy service module after the verification process is successful.

2. The SSO unified authentication implementation system for multi-tenancy as described in claim 1, characterized in that, The data configuration service module is also used to register an SSO-proxy client for each tenant and to cache client information for each tenant locally.

3. The SSO unified authentication implementation system for multi-tenancy as described in claim 1, characterized in that, The SSO authentication proxy service module is also used to detect whether the user is logged in. If the user is not logged in, the system redirects to the login interface of the IAM system module and returns to the tenant's application homepage after successful login. If the user is already logged in, the system directly returns to the tenant's application homepage.

4. The SSO unified authentication implementation system for multi-tenancy as described in claim 1, characterized in that, The tenant's web system proxies SSO authentication requests through the data configuration service module.

5. A method for implementing unified SSO authentication for multi-tenant systems, characterized in that, It is based on a unified authentication system for multi-tenancy SSO as described in any one of claims 1-4, wherein the method includes: When a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module. The SSO authentication proxy service module requests the configuration information corresponding to the tenant to be authenticated from the IAM system module, and determines whether the authentication is successful based on the token returned by the IAM system module. If the authentication is successful, the user is returned the tenant application based on the obtained configuration information, and the homepage of the tenant application is displayed.

6. The SSO unified authentication implementation method for multi-tenancy as described in claim 5, characterized in that, When a user accesses a tenant application, the tenant application checks whether the user is logged in. If not, it obtains and displays the list of tenants in the cloud platform based on the SSO authentication proxy service module, receives the user's selection of the corresponding tenant, and sends a tenant authentication request to the SSO authentication proxy service module.

7. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and running thereon, characterized in that, When the processor executes the program, it implements a unified authentication method for multi-tenancy SSO as described in any one of claims 5-6.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a unified authentication method for multi-tenancy SSO as described in any one of claims 5-6.

Images