A cross-client single sign-on method based on local security proxy service

By using a local security proxy service to uniformly manage session information and dynamic key binding, the problems of password management across multiple systems and independent cross-client sessions are solved, enabling secure and efficient single sign-on and encrypted data transmission, thus reducing enterprise costs.

CN117240528BActive Publication Date: 2025-10-31AISINO CORPORATION
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202311150954.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-09-07
Publication Date
2025-10-31
Estimated Expiration
2043-09-07

AI Technical Summary

Technical Problem

In existing technologies, users need to remember multiple system passwords, which poses a risk of password leakage, issues with secure sharing of session information, independent session information across clients, low authentication security, and high development costs.

Method used

A local security proxy service is used to uniformly manage session information. SM2 and SM4 keys are dynamically generated and bound to enable cross-client single sign-on. Session sharing is supported across different browsers or clients, and network transmission data is encrypted.

Benefits of technology

It enables single sign-on across clients, reduces the risk of password leakage, improves session information security and data transmission security, and reduces development costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117240528B_ABST
    Figure CN117240528B_ABST
Patent Text Reader

Abstract

This invention discloses a cross-client single sign-on method based on a local security proxy service, comprising: when a user accesses a business system, the business system requests authentication from an authentication center; the front-end page calls the local security proxy service to verify the user's session; if a valid session exists, the existing session information is returned; if no valid session exists, a user authentication page is displayed, and the user selects an authentication method based on the user authentication page; the front-end page directly calls the local security proxy service for authentication; the local security proxy service parses the received authentication request and sends the parsed authentication request information to the authentication center server; the authentication center server returns the authentication result corresponding to the authentication request information; the local security proxy service parses the authentication result, and if the authentication result is successful, saves and manages the session information and returns it to the front-end page; the front-end page displays an authentication success page.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of single sign-on technology, and more specifically, to a cross-client single sign-on method based on a local security proxy service. Background Technology

[0002] With the development of informatization in various industries, the number of application systems is increasing year by year. These systems were built at different times, and due to the different construction periods, the operating environment requirements of various systems are also different. This leads to many problems in the later stages of informatization construction. The main problems are as follows:

[0003] 1. User login authentication: Users need to remember multiple usernames and passwords for multiple systems. Users often confuse these passwords, which leads most users to either set the same password for all systems or record them on paper or in electronic text, which increases the risk of password leakage.

[0004] 2. Session information security sharing issues: When multiple business systems with heterogeneous authentication mechanisms collaborate to complete tasks, authentication results cannot be transmitted, leading to repeated logins and easy leakage or forgetting of authentication information. Most people usually create the same account and password across multiple business systems.

[0005] 3. Cross-client issue: Different business systems use different browsers or different clients. When using single sign-on, the session information between different clients is independent and cannot be shared, making it impossible to achieve cross-client single sign-on.

[0006] 4. Authentication security issues: Most business systems transmit authentication data in plaintext. For information technology construction with high security requirements, it is necessary to improve authentication security. This requires customized development for each system. The more systems there are, the greater the development workload and the higher the enterprise cost. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a cross-client single sign-on method based on a local security proxy service.

[0008] According to one aspect of the present invention, a cross-client single sign-on method based on a local security proxy service is provided, comprising:

[0009] When a user accesses the business system, the business system requests authentication from the authentication center. The front-end page calls the local security proxy service to verify the user's session. If a valid session exists, the existing session information is returned.

[0010] If no valid session is found during session verification, the user authentication page is displayed. The user selects an authentication method on the user authentication page to perform authentication, and the front-end page directly calls the local security proxy service for authentication.

[0011] The local security proxy service parses the received authentication requests and sends the parsed authentication request information to the authentication center server.

[0012] The authentication center server returns the authentication result corresponding to the authentication request information;

[0013] The local security proxy service parses the authentication result, and if the authentication result is successful, saves and manages the session information and returns it to the front-end page;

[0014] The front-end page displays a successful authentication page.

[0015] Optionally, it also includes displaying an error message if the authentication result is that the authentication failed.

[0016] Optionally, before the front-end page calls the local security proxy service for authentication, the following steps are also included:

[0017] The front-end page calls the local security proxy service to obtain the SM2 public key information;

[0018] Upon receiving the request, the local security proxy service generates a pair of SM2 public and private keys and saves them to the local cache.

[0019] The local security proxy service carries the SM2 public key information and calls the authentication center server to request temporary SM4 key information;

[0020] After receiving the request, the authentication center server generates a random UUID and a 16-bit SM4 key, and stores them in the authentication center server's cache.

[0021] The authentication center server uses the SM2 public key information to encrypt the random number UUID and the 16-bit SM4 key information, and returns the encrypted message to the local security proxy service;

[0022] The local security agent service uses the private key information of the public and private keys to decrypt encrypted messages and obtain a random number UUID and a 16-bit SM4 key information;

[0023] The local security proxy service returns the SM2 public key information to the front-end page;

[0024] After obtaining the SM2 public key information, the front-end page encrypts the authentication message and sends the encrypted message request to the local security proxy service.

[0025] The local security agent service uses the SM2 private key information to decrypt the encrypted message request. After decryption, it uses the obtained SM4 key information to encrypt the plaintext of the authentication message using SM4, while carrying a random number UUID, and requests the authentication center server to authenticate.

[0026] After obtaining the random number UUID, the authentication center server retrieves the SM4 key information based on the random number UUID. It then decrypts the authentication message using the SM4 key information and performs authentication verification. Once the authentication verification is successful, it creates server session information and binds the SM4 key information to the session information. After binding, the SM4 key information for this session will not be changed.

[0027] Optionally, it also includes: the SM4 key information becomes invalid simultaneously after the current session expires.

[0028] Optionally, it also includes:

[0029] When a user accesses the first business system through the first client on the same terminal device, if the first business system is not logged in, the user will be redirected to the authentication center.

[0030] The front-end page of the authentication center calls the local security proxy service to make a single sign-on request. The local security proxy service verifies whether a valid session exists. If a valid session exists, it calls the relevant interface under different authentication protocols to request the authentication center server with the session information.

[0031] The authentication center server generates different return messages based on the request protocol;

[0032] The local security proxy service returns the message to the front-end page, which then redirects to the first business system requested based on the protocol and the returned message.

[0033] The first business system obtains the currently logged-in user information based on the returned message and completes the login process for the first business system.

[0034] When a user has already completed login authentication through the local security proxy service, and then accesses the second business system again using the second client on the terminal device, the second business system accesses the authentication center through the second client. The second client directly obtains the session information through the local security proxy service and forwards the single sign-on request to the authentication center server through the local security proxy service.

[0035] The authentication center server returns a response request message, and the local security proxy service then returns the message to the second client that made the current request.

[0036] The second client returns the request information to the second business system, which then obtains the currently logged-in user information based on the returned message and completes the login process for the second business system under the second client.

[0037] Optionally, it also includes: if no valid session exists, login authentication is completed first, and then the logic processing for a session is performed.

[0038] According to another aspect of the present invention, a cross-client single sign-on device based on a local security proxy service is provided, comprising:

[0039] The session verification module is used when a user accesses the business system. The business system requests authentication from the authentication center, and the front-end page calls the local security proxy service to verify the user's session. If a valid session exists, the existing session information is returned.

[0040] The authentication module is used to display the user authentication page when there is no valid session during session verification. The user selects an authentication method on the user authentication page to perform authentication, and the front-end page directly calls the local security proxy service for authentication.

[0041] The receiving module is used by the local security proxy service to parse the received authentication requests and send the parsed authentication request information to the authentication center server.

[0042] The first return module is used by the authentication center server to return the authentication result corresponding to the authentication request information;

[0043] The second return module is used by the local security proxy service to parse the authentication result, and if the authentication result is successful, save and manage the session information and return it to the front-end page;

[0044] The display module is used to show the authentication success page on the front-end page.

[0045] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the methods described in any of the above aspects of the present invention.

[0046] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the method described in any of the preceding aspects of the present invention.

[0047] Therefore, the cross-client single sign-on design based on local security proxy service in this application can realize cross-client single sign-on, support session sharing between different business systems through different browsers or different clients, effectively solve the problem of business systems using different browsers or different clients to complete secure single sign-on, and achieve true "one-time authentication, multiple services access". Attached Figure Description

[0048] Exemplary embodiments of the present invention can be more fully understood by referring to the following figures:

[0049] Figure 1 This is a flowchart illustrating a cross-client single sign-on method based on a local security proxy service provided in an exemplary embodiment of the present invention.

[0050] Figure 2 This is a schematic diagram of the login authentication process provided by an exemplary embodiment of the present invention;

[0051] Figure 3 This is a schematic diagram of the data encryption interaction process provided by an exemplary embodiment of the present invention;

[0052] Figure 4 This is a schematic diagram of a cross-client single sign-on process provided by an exemplary embodiment of the present invention;

[0053] Figure 5 This is a schematic diagram of the structure of a cross-client single sign-on device based on a local security proxy service provided in an exemplary embodiment of the present invention;

[0054] Figure 6 This is the structure of an electronic device provided in an exemplary embodiment of the present invention. Detailed Implementation

[0055] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0056] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0057] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of the present invention are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0058] It should also be understood that in the embodiments of the present invention, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[0059] It should also be understood that any component, data or structure mentioned in the embodiments of the present invention can generally be understood as one or more unless explicitly defined or given contrary instructions in the context.

[0060] Furthermore, the term "and / or" in this invention is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this invention generally indicates that the preceding and following related objects have an "or" relationship.

[0061] It should also be understood that the description of the various embodiments in this invention emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0062] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0063] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0064] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, they should be considered part of the specification.

[0065] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0066] The embodiments of this invention can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Well-known examples of terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0067] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0068] Exemplary methods

[0069] Figure 1 This is a flowchart illustrating a cross-client single sign-on method based on a local security proxy service, provided by an exemplary embodiment of the present invention. This embodiment can be applied to electronic devices, such as… Figure 1 As shown, the cross-client single sign-on method 100 based on a local security proxy service includes the following steps:

[0070] Step 101: When a user accesses the business system, the business system requests authentication from the authentication center. The front-end page calls the local security proxy service to verify the user's session. If a valid session exists, the existing session information is returned.

[0071] Step 102: If no valid session exists during session verification, display the user authentication page. The user selects an authentication method on the user authentication page and performs authentication. The front-end page directly calls the local security proxy service for authentication.

[0072] Step 103: The local security proxy service parses the received authentication request and sends the parsed authentication request information to the authentication center server.

[0073] Step 104: The authentication center server returns the authentication result corresponding to the authentication request information;

[0074] Step 105: The local security proxy service parses the authentication result, and if the authentication result is successful, saves and manages the session information and returns it to the front-end page;

[0075] Step 106: The front-end page displays the authentication success page.

[0076] Optionally, it also includes displaying an error message if the authentication result is that the authentication failed.

[0077] Optionally, before the front-end page calls the local security proxy service for authentication, the following steps are also included:

[0078] The front-end page calls the local security proxy service to obtain the SM2 public key information;

[0079] Upon receiving the request, the local security proxy service generates a pair of SM2 public and private keys and saves them to the local cache.

[0080] The local security proxy service carries the SM2 public key information and calls the authentication center server to request temporary SM4 key information;

[0081] After receiving the request, the authentication center server generates a random UUID and a 16-bit SM4 key, and stores them in the authentication center server's cache.

[0082] The authentication center server uses the SM2 public key information to encrypt the random number UUID and the 16-bit SM4 key information, and returns the encrypted message to the local security proxy service;

[0083] The local security agent service uses the private key information of the public and private keys to decrypt encrypted messages and obtain a random number UUID and a 16-bit SM4 key information;

[0084] The local security proxy service returns the SM2 public key information to the front-end page;

[0085] After obtaining the SM2 public key information, the front-end page encrypts the authentication message and sends the encrypted message request to the local security proxy service.

[0086] The local security agent service uses the SM2 private key information to decrypt the encrypted message request. After decryption, it uses the obtained SM4 key information to encrypt the plaintext of the authentication message using SM4, while carrying a random number UUID, and requests the authentication center server to authenticate.

[0087] After obtaining the random number UUID, the authentication center server retrieves the SM4 key information based on the random number UUID. It then decrypts the authentication message using the SM4 key information and performs authentication verification. Once the authentication verification is successful, it creates server session information and binds the SM4 key information to the session information. After binding, the SM4 key information for this session will not be changed.

[0088] Optionally, it also includes: the SM4 key information becomes invalid simultaneously after the current session expires.

[0089] Optionally, it also includes:

[0090] When a user accesses the first business system through the first client on the same terminal device, if the first business system is not logged in, the user will be redirected to the authentication center.

[0091] The front-end page of the authentication center calls the local security proxy service to make a single sign-on request. The local security proxy service verifies whether a valid session exists. If a valid session exists, it calls the relevant interface under different authentication protocols to request the authentication center server with the session information.

[0092] The authentication center server generates different return messages based on the request protocol;

[0093] The local security proxy service returns the message to the front-end page, which then redirects to the first business system requested based on the protocol and the returned message.

[0094] The first business system obtains the currently logged-in user information based on the returned message and completes the login process for the first business system.

[0095] When a user has already completed login authentication through the local security proxy service, and then accesses the second business system again using the second client on the terminal device, the second business system accesses the authentication center through the second client. The second client directly obtains the session information through the local security proxy service and forwards the single sign-on request to the authentication center server through the local security proxy service.

[0096] The authentication center server returns a response request message, and the local security proxy service then returns the message to the second client that made the current request.

[0097] The second client returns the request information to the second business system, which then obtains the currently logged-in user information based on the returned message and completes the login process for the second business system under the second client.

[0098] Optionally, it also includes: if no valid session exists, login authentication is completed first, and then the logic processing for a session is performed.

[0099] Specifically, the backend of this invention is developed using the JAVA language, the frontend uses the Vue framework, and the local security proxy service is developed using C#. During login authentication or single sign-on, the local security proxy service forwards the request to achieve cross-client single sign-on.

[0100] The present invention is designed as follows:

[0101] 1. Login authentication, such as Figure 2 As shown:

[0102] When a user accesses the business system and the business system requests authentication from the authentication center, the frontend calls the local security proxy service to verify the session. If a valid session exists, it returns the existing session information; otherwise, it displays the user authentication page. When the user selects an authentication method, the frontend directly calls the local security proxy service for authentication. The local security proxy service parses the received request, processes it, and forwards it to the authentication center server. The authentication center server returns the authentication result. If authentication fails, it returns an error message; if authentication succeeds, it issues the current user's session information. After receiving the returned message, the local security proxy service saves and manages the session information and returns it to the frontend page, which then displays a login authentication success page.

[0103] 2. Encrypted data interaction, such as Figure 3 As shown:

[0104] When the frontend calls the local security proxy service for authentication, it first calls the local security proxy service to obtain the SM2 public key information for encryption during subsequent interactions. After receiving the request, the local security proxy service generates a pair of SM2 public and private keys and saves them in the local cache. At the same time, it calls the authentication center server to request temporary SM4 key information, carrying the SM2 public key information. After receiving the request, the authentication center generates a random number UUID and a 16-bit SM4 key and places them in the authentication center's cache. After generation, it uses the SM2 public key to encrypt the returned UUID and 16-bit SM4 key and returns the encrypted message to the local security proxy service. The local security proxy service uses the SM2 private key to decrypt the message, obtain the UUID and SM4 key, saves the obtained UUID and SM4, and returns the SM2 public key information to the frontend page.

[0105] After obtaining the SM2 public key, the front-end page encrypts the authentication message and sends the encrypted message to the local security proxy service. The local security proxy service decrypts the message using the SM2 private key and then uses the obtained SM4 key to encrypt the plaintext, along with the UUID returned in the previous step, requesting authentication from the authentication center server. The authentication center server obtains the UUID and uses it to retrieve the SM4 key, decrypts the message using the SM4 key, and performs authentication verification. If the authentication verification is successful, a server-side session is created, and the SM4 key information is bound to the session information. Once bound, the SM4 key for this session will not change, and subsequent requests can obtain the SM4 key for encryption and decryption based on the session. The key becomes invalid when the session expires.

[0106] 3. Cross-client single sign-on, such as Figure 4 As shown:

[0107] When a user accesses business system A through client 1 on the same computer, if business system A is not logged in, the user is redirected to the authentication center. The authentication center's front-end page calls the local security proxy service to make a single sign-on request. The local security proxy service verifies whether a valid session exists. If a valid session exists, it calls the relevant interfaces under different authentication protocols to request the authentication center server, carrying the session information. The authentication center server generates different return messages according to the request protocol. After the authentication center returns the request message, the local security proxy service returns the message to the front-end. The front-end then redirects to the requested business system A according to the protocol and the return message. Business system A obtains the currently logged-in user information based on the return message and completes the login for business system A. If no valid session exists, login authentication is completed first, and then the logic processing for a session is performed.

[0108] After a user has already completed login authentication through the local security proxy service, when client 2 accesses business system B again, business system B accesses the authentication center under the current client. The current client can directly obtain session information through the local security proxy service and forward the single sign-on request to the authentication center server through the local security proxy service, without needing to log in again. The authentication center server returns a response request message, which the local security proxy service then returns to the requesting client 2. The current client 2 returns the request information to business system B, and business system B obtains the currently logged-in user information based on the returned message, completing the login for business system B under client 2.

[0109] The key points of this invention are as follows:

[0110] 1. A local security proxy service is used to uniformly manage session information, enabling different clients to obtain session information through the local security proxy service, thereby achieving session sharing among different clients on the same computer and enabling cross-client single sign-on;

[0111] 2. Each time a user logs in, a new SM2 public and private key and an SM4 encryption key are dynamically generated and bound to the login session. The key is only valid within the session's validity period. The dynamic and time-limited valid key greatly reduces the risk of the key being cracked.

[0112] Therefore, this application's cross-client single sign-on design based on local security proxy services enables cross-client single sign-on, supporting session sharing between different business systems using different browsers or clients. This effectively solves the problem of secure single sign-on for business systems using different browsers or clients, achieving true "one-time authentication, multiple services access." Simultaneously, by using a dynamic and time-valid random key to encrypt data transmitted over the network, it effectively prevents information leakage, theft, and data tampering during network data transmission, while reducing the risk of key brute-force attacks. This significantly improves data transmission security, enhances network information security, and safeguards the development of information technology.

[0113] Exemplary device

[0114] Figure 5 This is a schematic diagram of the structure of a cross-client single sign-on device based on a local security proxy service provided in an exemplary embodiment of the present invention. Figure 5 As shown, the device 500 includes:

[0115] The session verification module is used when a user accesses the business system. The business system requests authentication from the authentication center, and the front-end page calls the local security proxy service to verify the user's session. If a valid session exists, the existing session information is returned.

[0116] The authentication module is used to display the user authentication page when there is no valid session during session verification. The user selects an authentication method on the user authentication page to perform authentication, and the front-end page directly calls the local security proxy service for authentication.

[0117] The receiving module is used by the local security proxy service to parse the received authentication requests and send the parsed authentication request information to the authentication center server.

[0118] The first return module is used by the authentication center server to return the authentication result corresponding to the authentication request information;

[0119] The second return module is used by the local security proxy service to parse the authentication result, and if the authentication result is successful, save and manage the session information and return it to the front-end page;

[0120] The display module is used to show the authentication success page on the front-end page.

[0121] Optionally, the device 500 further includes a display module for displaying an error message if the authentication result is that the authentication failed.

[0122] Optionally, before the front-end page calls the local security proxy service for authentication, device 500 also includes:

[0123] The first acquisition module is used by the front-end page to call the local security proxy service to obtain the public key information of SM2;

[0124] The first generation module is used to generate a pair of SM2 public and private keys and save them to the local cache after the local security proxy service receives the request.

[0125] The calling module is used by the local security proxy service to carry the SM2 public key information and call the authentication center server to request temporary SM4 key information;

[0126] The second generation module is used to generate a random number UUID and a 16-bit SM4 key information after the authentication center server receives the request, and store them in the cache of the authentication center server.

[0127] The first encryption module is used by the authentication center server to encrypt the random number UUID and the 16-bit SM4 key information using the SM2 public key information, and then return the encrypted message to the local security proxy service.

[0128] The first decryption module is used by the local security agent service to decrypt encrypted messages using the private key information of the public and private keys, and obtain the random number UUID and 16-bit SM4 key information.

[0129] The third return module is used by the local security proxy service to return the SM2 public key information to the front-end page;

[0130] The second encryption module is used to encrypt the authentication message after the front-end page obtains the SM2 public key information, and then send the encrypted message request to the local security proxy service.

[0131] The second decryption module is used by the local security agent service to decrypt the encrypted message request using the SM2 private key information. After decryption, it uses the obtained SM4 key information to encrypt the plaintext of the authentication message using SM4, while carrying a random number UUID, and requests the authentication center server to authenticate.

[0132] The first verification module is used by the authentication center server to obtain the random number UUID, retrieve the SM4 key information based on the random number UUID, decrypt the authentication message using the SM4 key information, perform authentication verification after decryption, and create server session information after successful authentication verification. At the same time, the SM4 key information is bound to the session information. After binding, the SM4 key information of this session will not be changed.

[0133] Optionally, the device 500 further includes an invalidation module, which is used to invalidate the SM4 key information simultaneously after the current session is invalidated.

[0134] Optionally, the device 500 also includes:

[0135] The redirection module is used to redirect users to the authentication center when they access the first business system through the first client on the same terminal device and are not logged into the first business system.

[0136] The second verification module is used by the front-end page of the authentication center to call the local security proxy service to make a single sign-on request. The local security proxy service verifies whether a valid session exists. If a valid session exists, it calls the relevant interfaces under different authentication protocols to request the authentication center server with the session information.

[0137] The third generation module is used by the authentication center server to generate different return messages according to the request protocol.

[0138] The fourth return module is used by the local security proxy service to return the message to the front-end page, and the front-end page then jumps to the first requested business system according to the protocol and the returned message.

[0139] The second acquisition module is used by the first business system to obtain the currently logged-in user information based on the returned message and complete the login of the first business system.

[0140] The forwarding module is used when a user has already completed login authentication through the local security proxy service and then accesses the second business system again using the second client of the terminal device, the second business system accesses the authentication center through the second client, the second client directly obtains the session information through the local security proxy service, and forwards the single sign-on request to the authentication center server through the local security proxy service;

[0141] The fifth return module is used for the authentication center server to return a response request message, and the local security proxy service then returns the message to the second client that made the current request.

[0142] The login module is used by the second client to return request information to the second business system. The business system then obtains the currently logged-in user information based on the returned message and completes the login process for the second business system from the second client.

[0143] Optionally, the device 500 further includes a logic processing module, which performs login authentication first if no valid session exists, and then performs logic processing for sessions.

[0144] Exemplary electronic devices

[0145] Figure 6 This is the structure of an electronic device provided in an exemplary embodiment of the present invention. For example... Figure 6 As shown, the electronic device 60 includes one or more processors 61 and a memory 62.

[0146] The processor 61 may be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions.

[0147] The memory 62 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 61 may execute the program instructions to implement the methods of the software programs of the various embodiments of the present invention described above, and / or other desired functions. In one example, the electronic device may also include an input device 63 and an output device 64, these components being interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0148] In addition, the input device 63 may also include, for example, a keyboard, a mouse, etc.

[0149] The output device 64 can output various information to the outside. The output device 64 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0150] Of course, for the sake of simplicity, Figure 6 Only some of the components of this electronic device relevant to the present invention are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0151] Exemplary computer program products and computer-readable storage media

[0152] In addition to the methods and apparatus described above, embodiments of the present invention may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the methods according to various embodiments of the present invention described in the "Exemplary Methods" section above.

[0153] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of the present invention. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0154] Furthermore, embodiments of the present invention may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the methods according to various embodiments of the present invention described in the "Exemplary Methods" section above.

[0155] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0156] The basic principles of the present invention have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in the present invention are merely examples and not limitations, and should not be considered as essential features of each embodiment of the present invention. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the present invention to the necessity of employing the aforementioned specific details.

[0157] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0158] The block diagrams of devices, systems, devices, and systems involved in this invention are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, systems, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0159] The methods and systems of the present invention may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of the present invention are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, the present invention may also be implemented as a program recorded on a recording medium, the program comprising machine-readable instructions for implementing the methods according to the present invention. Thus, the present invention also covers recording media storing programs for performing the methods according to the present invention.

[0160] It should also be noted that in the systems, apparatus, and methods of the present invention, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered equivalents of the present invention. The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the invention. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of the invention. Therefore, the invention is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0161] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of the invention to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A cross-client single sign-on method based on a local security proxy service, characterized in that, include: When a user accesses the business system, the business system requests authentication from the authentication center. The front-end page calls the local security proxy service to verify the user's session. If a valid session exists, the existing session information is returned. Multiple clients on the same terminal device can call the local security proxy service to obtain the session information. If no valid session is found during the session verification, a user authentication page is displayed. The user selects an authentication method on the user authentication page to perform authentication. The front-end page directly calls the local security proxy service to perform authentication. After obtaining the SM2 public key information from the local security proxy service, the front-end page encrypts the authentication message and sends the encrypted message request to the local security proxy service. The local security proxy service uses the SM2 private key information to decrypt the encrypted message request. After decryption, it uses the obtained SM4 key information to encrypt the plaintext of the authentication message using SM4, while carrying a random number UUID, and requests the authentication center server to perform authentication. After obtaining the random number UUID, the authentication center server obtains the SM4 key information based on the random number UUID, decrypts the authentication message using the SM4 key information, performs authentication verification after decryption, and creates server session information after successful authentication verification. At the same time, the SM4 key information is bound to the session information. After binding, the SM4 key information for this session will not change. The authentication center server returns the authentication result corresponding to the authentication message; The local security proxy service parses the authentication result, and if the authentication result is successful, saves and manages the session information and returns it to the front-end page; The front-end page displays a successful authentication page.

2. The method according to claim 1, characterized in that, Also includes: If the authentication result is that the authentication failed, an error message will be displayed.

3. The method according to claim 1, characterized in that, Before the front-end page calls the local security proxy service for authentication, the following is also included: The front-end page calls the local security proxy service to obtain the SM2 public key information; Upon receiving the request, the local security proxy service generates a pair of SM2 public and private keys and saves them to the local cache. The local security proxy service carries the public key information of SM2 and calls the authentication center server to apply for temporary SM4 key information; After receiving the request, the authentication center server generates a random number UUID and a 16-bit SM4 key, and stores them in the cache of the authentication center server. The authentication center server uses the public key information of SM2 to encrypt the random number UUID and the 16-bit SM4 key information, and returns the encrypted message to the local security proxy service; The local security proxy service uses the private key information of the public and private keys to decrypt the encrypted message and obtain the random number UUID and the 16-bit SM4 key information; The local security proxy service returns the SM2 public key information to the front-end page.

4. The method according to claim 3, characterized in that, Also includes: The SM4 key information becomes invalid after this session expires.

5. The method according to claim 1, characterized in that, Also includes: When the user accesses the first business system through the first client on the same terminal device, if the first business system is not logged in, the user will be redirected to the authentication center. The front-end page of the authentication center calls the local security proxy service to make a single sign-on request. The local security proxy service verifies whether a valid session exists. If a valid session exists, it calls the relevant interfaces under different authentication protocols to request the authentication center server with the session information. The authentication center server generates different return messages according to the request protocol; The local security proxy service returns the message to the front-end page, and the front-end page then redirects to the requested first business system according to the protocol and the returned message. The first business system obtains the currently logged-in user information based on the returned message and completes the login process for the first business system. When the user has already completed login authentication through the local security proxy service, and then uses the second client of the terminal device to access the second business system again, when the second business system accesses the authentication center through the second client, the second client directly obtains the session information through the local security proxy service and forwards the single sign-on request to the authentication center server through the local security proxy service. The authentication center server returns a response request message, and the local security proxy service then returns the message to the second client that made the current request. The second client returns a response request message to the second business system. The business system then obtains the currently logged-in user information based on the returned message and completes the login process for the second business system under the second client.

6. The method according to claim 5, characterized in that, Also includes: If no valid session exists, login authentication will be completed first, and then the logic processing for sessions will proceed.

7. A cross-client single sign-on device based on a local security proxy service, characterized in that, include: The session verification module is used when a user accesses the business system, the business system requests authentication from the authentication center, the front-end page calls the local security proxy service to verify the user's session, and if a valid session exists, it returns the existing session information. Multiple clients under the same terminal device can call the local security proxy service to obtain the session information. The authentication module is used to display a user authentication page when the session verification does not have a valid session. The user selects an authentication method based on the user authentication page to perform authentication. The front-end page directly calls the local security proxy service to perform authentication. The second encryption module is used to encrypt the authentication message after the front-end page obtains the SM2 public key information from the local security proxy service, and then send the encrypted message request to the local security proxy service. The second decryption module is used by the local security agent service to decrypt the encrypted message request using the SM2 private key information, and after decryption, to encrypt the plaintext of the authentication message using the obtained SM4 key information, while carrying a random number UUID, and requesting the authentication center server to perform authentication. The first verification module is used by the authentication center server to obtain the random number UUID, obtain the SM4 key information based on the random number UUID, decrypt the authentication message using the SM4 key information, perform authentication verification after decryption, and create server session information after successful authentication verification. At the same time, the SM4 key information is bound to the session information. After binding, the SM4 key information of this session will not be changed. The first return module is used for the authentication center server to return the authentication result corresponding to the authentication message; The second return module is used by the local security proxy service to parse the authentication result, and if the authentication result is successful, to save and manage session information and return it to the front-end page; The display module is used to display the authentication success page on the front-end page.

8. The apparatus according to claim 7, characterized in that, Also includes: The display module is used to display error information when the authentication result is that the authentication fails.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program for performing the method described in any one of claims 1-6.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method described in any one of claims 1-6.

Citation Information

Patent Citations

  • Login authentication method, computer storage medium and electronic device

    CN109543376A

  • Single sign-on system

    CN114257430A