Single sign-on integrated agent implementation method, electronic device and storage medium

Abstract

The present invention discloses a single sign-on integrated proxy implementation method, an electronic device and a storage medium, and belongs to the technical field of integrated portal, unified identity authentication and single sign-on integrated proxy. The technical problem to be solved by the present invention is that the development cost of the process of connecting existing products or systems to a new single sign-on protocol is high, the connection efficiency is low, and the user experience is poor. The technical solution is: using the login module of the current single sign-on system A as a carrier for protocol conversion, the SDK module of the new single sign-on system B is embedded into the login module of the current single sign-on system A; when the application system triggers the OAuth2.0-based single sign-on process, it jumps to the login module of the current single sign-on system A, and the login module of the current single sign-on system A triggers the single sign-on process with the new single sign-on system B; after the single sign-on process ends, protocol data conversion is implemented based on the OIDC protocol and the application system is called back to end the single sign-on integrated proxy process.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated portal, unified identity authentication and single sign-on integrated agent, in particular to a single sign-on integrated agent implementation method, electronic equipment and storage medium. Background Art

[0002] Single Sign-On (SSO) is an authentication and authorization mechanism that allows users to log in once when accessing multiple applications or services, and then access other trusted applications or services without having to re-enter their credentials. This improves user convenience, reduces the burden of having to remember multiple usernames and passwords, and improves security because users only need to log in in one place instead of having to store their credentials in multiple different systems.

[0003] OAuth 2.0 (Open Authorization 2.0) is a protocol for authorizing access to resources, commonly used for authentication and authorization between web applications and mobile applications. OAuth 2.0 allows users to grant limited, conditional access to third-party applications without providing their username and password directly to the third-party application. This gives users better control over their data and privacy. OIDC (OpenID Connect) is an authentication and authorization protocol built on top of OAuth 2.0, designed to enhance the authentication capabilities of OAuth 2.0. OIDC focuses on authentication, allowing applications to verify the identity of end users and obtain information related to users, while continuing to use OAuth2.0 to authorize applications to access APIs and resources.

[0004] An integration portal is a unified user interface or platform that integrates multiple applications, services, information, and workflows. Its goal is to provide users with a centralized access point, enabling them to easily view and utilize information and functionality from diverse sources without switching between multiple systems. Integration portals are commonly used in organizations such as businesses and academic institutions to improve work efficiency and user experience.

[0005] As the level of informatization within organizations or enterprises continues to improve, more and more systems are emerging. The emergence of integrated portals has greatly improved the user experience. However, in the process of upgrading integrated portals or introducing new platforms, different single sign-on protocols cause each application system to face a lot of development pressure such as single sign-on protocol adaptation and docking.

[0006] In summary, the process of connecting existing products or systems to the new single sign-on protocol has disadvantages such as high development cost, low connection efficiency, and poor user experience. Summary of the Invention

[0007] The technical task of the present invention is to provide a single sign-on integrated agent implementation method, electronic device and storage medium to solve the problems of high development cost, low docking efficiency and poor user experience in the process of docking existing products or systems with new single sign-on protocols.

[0008] The technical task of the present invention is achieved in the following way: a single sign-on integrated proxy implementation method, which uses the login module of the current single sign-on system A as the carrier of protocol conversion, and embeds the SDK module of the new single sign-on system B into the login module of the current single sign-on system A; when the application system triggers the OAuth2.0-based single sign-on process, it jumps to the login module of the current single sign-on system A, and the login module of the current single sign-on system A triggers the single sign-on process with the new single sign-on system B, that is, the current single sign-on system A and the downstream application implement a user data synchronization mechanism based on the OAuth2.0 protocol; after the single sign-on process is completed, the protocol data conversion is implemented based on the OIDC protocol and the application system is called back to end the single sign-on integrated proxy process.

[0009] Preferably, the data object entities of the single sign-on protocol in the login module of the current single sign-on system A include the following two types:

[0010] ①The data entity is an OIDC protocol object;

[0011] ②The data entity is the protocol object to be connected.

[0012] Better yet, one-to-one attribute mapping is performed based on object entities to achieve protocol data conversion;

[0013] Among them, attribute mapping is that after the current single sign-on system A obtains the current user information structure from the new single sign-on system B, each attribute is parsed one by one and placed into the user information structure of the current single sign-on system A; specifically: the user ID in the current single sign-on system A is named userld, and is named uid in the new single sign-on system B. After the current single sign-on system A obtains uid, userld=uid.

[0014] As a preference, when connecting to a new single sign-on system B, it is only necessary to synchronize the two points based on the synchronization method published by the new single sign-on system B. After the synchronization is completed, data synchronization is performed based on the OIDC protocol.

[0015] As a preferred option, after connecting to the new single sign-on system B, multiple applications are integrated into the new integrated portal in the form of independent links without any development;

[0016] or,

[0017] Integrate the old integration portal into the new portal as a whole application.

[0018] Preferably, the sdk module specifically refers to a code package, that is, an sdk jar package that introduces a new single sign-on system B under the spring boot framework under java.

[0019] An electronic device comprising: a memory and at least one processor;

[0020] Wherein, the memory stores a computer program;

[0021] The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the above-mentioned single sign-on integration agent implementation method.

[0022] A computer-readable storage medium stores a computer program, and the computer program can be executed by a processor to implement the single sign-on integration agent implementation method as described above.

[0023] The single sign-on integrated proxy implementation method, electronic device, and storage medium of the present invention have the following advantages:

[0024] (1) The present invention combines the single sign-on system of the OAuth2.0 and OIDC protocols with a method for uniformly adapting to other single sign-on protocols in an integrated proxy manner, solving the problems of high development costs, low docking efficiency, and poor user experience in the process of docking existing products or systems with new single sign-on protocols;

[0025] (2) The present invention achieves single sign-on and user experience consistency across different single sign-on protocol platforms through features such as single sign-on protocol conversion and user data synchronization, and is widely used in the informationization upgrade of large-scale portal platforms within organizations and enterprises and the compatibility of different internal protocol ecosystems;

[0026] (3) This invention covers areas such as integrated portals, unified identity authentication, and single sign-on integrated agents. It allows applications to form a small platform using a single single sign-on protocol. This small platform can then be added to an integrated portal under another single sign-on protocol as a larger application, thereby improving development efficiency and system maintainability. However, the integrated architecture also introduces a series of new challenges, including communication efficiency between applications and integrated portals, initial loading time, and application management.

[0027] (IV) The present invention uses the login module of the current single sign-on system as the carrier of protocol conversion, embeds the SDK module of the new single sign-on system into the login module, and realizes the single point protocol conversion between the current single sign-on system and the new single sign-on system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0029] Attachment Figure 1 A flowchart of a method for implementing a single sign-on integration agent. DETAILED DESCRIPTION

[0030] The single sign-on integrated proxy implementation method, electronic device, and storage medium of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.

[0031] Example 1:

[0032] As attached Figure 1 As shown, this embodiment provides a single sign-on integrated proxy implementation method, which uses the login module of the current single sign-on system A as a carrier for protocol conversion, and embeds the SDK module of the new single sign-on system B into the login module of the current single sign-on system A; when the application system triggers the OAuth2.0-based single sign-on process, it jumps to the login module of the current single sign-on system A, and the login module of the current single sign-on system A triggers the single sign-on process with the new single sign-on system B, that is, the current single sign-on system A and the downstream application implement a user data synchronization mechanism based on the OAuth2.0 protocol; after the single sign-on process is completed, the protocol data conversion is implemented based on the OIDC protocol and the application system is called back to end the single sign-on integrated proxy process; the details are as follows:

[0033] (1) Enter the URL http: / / www.app.com on the browser to access the application system, and then proceed to step (2);

[0034] (2) Application system performs authentication:

[0035] ①If passed, the access is successful;

[0036] ② If it fails, jump to the current single sign-on system A and execute step (3) next;

[0037] (3) The current single sign-on system A determines whether the user has logged in:

[0038] ①If yes, proceed to step (4);

[0039] ②If not, jump to step (6);

[0040] (4) The browser carries the temporary code and calls back the application system, and then executes step (5);

[0041] (5) The application system creates a local session;

[0042] (6) The browser carries the service ID and session ID and jumps to the new single sign-on system B, and then executes step (7);

[0043] (7) The new single sign-on system B determines whether the user has logged in:

[0044] ①If not, proceed to step (8);

[0045] ②If yes, proceed to step (9);

[0046] (8) Use the browser to log in to the new single sign-on system B, and then proceed to step (9);

[0047] (9) Carry the ticket to call back the current single sign-on system A, and then execute step (10);

[0048] (10) The current single sign-on system A obtains the user ID based on the ticket and service identifier, and then executes step (11);

[0049] (11) The new single sign-on system B verifies the ticket and service ID, returns the user ID, and then executes step (12);

[0050] (12) The current single sign-on system A is called back based on the user representation and session identifier, and then executes step (4).

[0051] In this embodiment, the data object entities of the single sign-on protocol in the login module of the current single sign-on system A include the following two types:

[0052] ①The data entity is an OIDC protocol object;

[0053] ②The data entity is the protocol object to be connected.

[0054] In this embodiment, one-to-one attribute mapping is performed based on the object entity to achieve protocol data conversion;

[0055] Among them, attribute mapping is that after the current single sign-on system A obtains the current user information structure from the new single sign-on system B, each attribute is parsed one by one and placed into the user information structure of the current single sign-on system A; specifically: the user ID in the current single sign-on system A is named userld, and is named uid in the new single sign-on system B. After the current single sign-on system A obtains uid, userld=uid.

[0056] In this embodiment, when connecting to the new single sign-on system B, it is only necessary to synchronize the two points based on the synchronization method published by the new single sign-on system B. After the synchronization is completed, data synchronization is performed based on the OIDC protocol.

[0057] In this embodiment, after connecting to the new single sign-on system B, multiple applications are integrated into the new integrated portal as independent links without any development;

[0058] or,

[0059] Integrate the old integration portal into the new portal as a whole application.

[0060] In this embodiment, the SDK module specifically refers to a code package, that is, the SDK jar package that introduces the new single sign-on system B under the Spring Boot framework in Java. The key code is as follows:

[0061]

[0062]

[0063] Although both the OIDC-based SSO system and the CAS (Central Authentication Service)-based SSO system in this embodiment aim to achieve unified authentication and authorization for users across multiple application systems, they differ significantly in their protocol design, architectural features, and implementation details. The following compares the differences between the two in terms of protocol and architecture:

[0064] (1) Differences at the protocol level

[0065] OIDC (OpenID Connect)

[0066] Design principles and specifications:

[0067] Based on OAuth 2.0: OIDC is an extension of the OAuth 2.0 protocol to provide identity authentication services. It uses the OAuth 2.0 authorization mechanism and adds a standard for identity information exchange.

[0068] Standardization: OIDC is an open standard developed and maintained by the OpenID Foundation. It has detailed specification documents (such as "OpenID Connect Core 1.0" and "OpenID Connect Discovery 1.0"), which ensure cross-platform and cross-language interoperability.

[0069] Key features and concepts:

[0070] Identity Token: OIDC introduces JSON Web Tokens (JWT) as identity tokens, which contain the user's basic identity information (such as username, email, user ID, etc.), as well as signed metadata to ensure the integrity and credibility of the information.

[0071] Discovery Document: OIDC provides a standard endpoint (.well-known / openid-configuration) through which clients can automatically obtain relevant configuration information of the identity provider (IdP), simplifying the integration process.

[0072] Authorization Type and Process: Multiple authorization types are supported, such as the authorization code mode and implicit flow. A typical login process involves redirecting the user to the IdP. After authentication is complete, an authorization code is returned or an ID token is directly returned to the client. The client then requests an access token and a refresh token from the IdP.

[0073] Extensibility: Meet more complex identity management and authentication needs through optional extension mechanisms (such as Claims Request, Session Management, and Federation).

[0074] CAS (Central Authentication Service)

[0075] Design principles and specifications:

[0076] Independent design: As an independent SSO solution, CAS is not built based on other existing protocols, but has its own dedicated specifications and implementations.

[0077] Relatively closed: Although the CAS community is active, its specifications and implementations are not as widely accepted and standardized as OIDC, and are mainly applicable to specific ecosystems or internal system integration.

[0078] Key features and concepts:

[0079] Ticketing system: CAS uses tickets (such as service tickets and proxy tickets) as credentials for authentication and authorization. The client application sends a request to the CAS server, obtains a service ticket, and then returns the ticket to the client application to prove that the user has passed authentication.

[0080] Service Registration: Each client application (Service) that needs to be integrated into the CAS system needs to register on the CAS Server, defining its unique identifier and service URL. The CAS Server processes the authentication request and generates the corresponding ticket based on this information.

[0081] Simple HTTP protocol interaction: The CAS protocol is mainly based on the HTTP request / response mechanism. The client application interacts with the CAS Server through redirection and callback URLs to complete the login, logout and verification process.

[0082] Proxy authentication support: CAS natively supports multi-level proxy authentication, that is, an authenticated service can initiate authentication requests to other services on behalf of the user, which is particularly useful for complex multi-layer application architectures.

[0083] (2) Differences at the architectural level

[0084] OIDC Architecture

[0085] Components and roles:

[0086] Client (Relying Party, RP): An application system that wants to use OIDC for authentication.

[0087] Identity Provider (IdP): A server responsible for verifying user identity and issuing identity tokens and access tokens, such as Alibaba Cloud IDaaS and Google.

[0088] User Agent (browser): The medium through which users interact with RPs and IdPs, usually involving browser redirects and callbacks.

[0089] Resource Server (RS) (optional): holds protected resources and verifies access tokens to determine whether access is allowed.

[0090] Communication Mode:

[0091] Indirect interaction: The authentication process between the user and the RP usually needs to be carried out through the IdP. The user interacts directly with the IdP to provide credentials. After successful authentication, the IdP passes the identity information to the RP in a secure manner.

[0092] CAS Architecture

[0093] Components and roles:

[0094] Client (Service): An application system that wants to use CAS for authentication.

[0095] CAS Server: Central authentication server, responsible for receiving and verifying user credentials and issuing service tickets.

[0096] User agent (browser): The medium through which users interact with the Service and CAS Server, also involving redirection and callback.

[0097] CAS Client (optional): A library embedded in the Service that helps the Service interact with the CAS Server and simplifies the integration process.

[0098] Communication Mode:

[0099] Direct interaction: When a user initially interacts with a service, they are redirected to the CAS server for login. After successful login, the CAS server directly redirects the user back to the service with a service ticket. The service verifies the validity of the ticket to complete the authentication.

[0100] Agreement:

[0101] OIDC is based on the OAuth 2.0 standard, emphasizing open standards, standardized identity information representation (JWT) and discovery mechanisms, and is suitable for a wide range of Internet environments and cross-organizational collaboration.

[0102] CAS is an independently designed SSO protocol that focuses on simple HTTP interactions, ticket systems, and flexible proxy authentication support. It is more suitable for integration within enterprise intranets or specific ecosystems.

[0103] Architecture:

[0104] OIDC adopts an indirect interaction mode, where users interact directly with identity providers, and identity information is passed to client applications in a standardized and secure manner.

[0105] CAS adopts a direct interaction mode. After the user interacts with the central authentication server, the service ticket is directly returned to the client application to complete the authentication. Additional CAS Client libraries may be required to assist in integration.

[0106] In this embodiment, the user enters the application system access address in the browser address bar. After receiving the request, the application system backend performs internal authentication. If authentication fails, the browser directly redirects to the current single sign-on system A. The current single sign-on system A then determines whether the current browser process has logged in. If not, it begins the single sign-on proxy process. The current single sign-on system A, carrying the service identifier registered with the new single sign-on system B and the current session identifier, triggers a redirect from the browser to the new single sign-on system. The new single sign-on system then determines whether the current browser process has logged in. If not, it initiates the user login process. After login, the browser redirects to the current single sign-on system A again, carrying the authentication ticket. After obtaining the ticket, the current single sign-on system A requests single sign-on system B in the backend to obtain the user ID. The browser then redirects to the application system with the user ID and session identifier. The application system then creates a local session based on the user ID, temporary code, and other information. The process is now complete, and the user can access the application system normally.

[0107] Example 2:

[0108] This embodiment also provides an electronic device, including: a memory and at least one processor;

[0109] wherein the memory stores computer-executable instructions;

[0110] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the single sign-on integration agent implementation method in any embodiment of the present invention.

[0111] Example 3:

[0112] This embodiment also provides a computer-readable storage medium storing a plurality of instructions, which are loaded by a processor and cause the processor to execute the single sign-on integrated proxy implementation method according to any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, wherein the storage medium stores software program code that implements the functions of any of the above-described embodiments, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0113] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.

[0114] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RYMs, DVD-RWs, DVD+RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer via a communications network.

[0115] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.

[0116] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. 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 invention.

Claims

1. A method for implementing a single sign-on integrated agent, characterized in that: This method uses the login module of the current single sign-on system A as the carrier of protocol conversion, and embeds the SDK module of the new single sign-on system B into the login module of the current single sign-on system A. When the application system triggers the OAuth2.0-based single sign-on process, it jumps to the login module of the current single sign-on system A. The login module of the current single sign-on system A triggers the single sign-on process with the new single sign-on system B, that is, the current single sign-on system A and the downstream application implement a user data synchronization mechanism based on the OAuth2.0 protocol. After the single sign-on process is completed, the protocol data conversion is implemented based on the OIDC protocol and the application system is called back, ending the single sign-on integration proxy process. The data object entities of the single sign-on protocol in the login module of the current single sign-on system A include the following two types: ①The data entity is an OIDC protocol object; ②The data entity is the protocol object to be connected; One-to-one attribute mapping based on object entities to achieve protocol data conversion; Attribute mapping is when the current single sign-on system A obtains the current user information structure from the new single sign-on system B, each attribute is parsed one by one and placed into the user information structure of the current single sign-on system A. Specifically, the user ID in the current single sign-on system A is named userld, and in the new single sign-on system B it is named uid. After the current single sign-on system A obtains uid, userld=uid is set. When connecting to the new single sign-on system B, you only need to synchronize the two points based on the synchronization method published by the new single sign-on system B. After the synchronization is completed, data synchronization is performed based on the OIDC protocol; After connecting to the new single sign-on system B, multiple applications are integrated into the new integrated portal as independent links without any development required; or, Integrate the old integration portal into the new portal as a whole application; The SDK module specifically refers to a code package, that is, the SDK jar package that introduces the new single sign-on system B under the Spring Boot framework under Java.

2. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the single sign-on integration agent implementation method according to claim 1 .

3. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the single sign-on integration agent implementation method according to claim 1.

Images