User authentication method, system, medium and equipment

Abstract

The invention provides a user authentication method and system, a medium and equipment, and the method comprises the steps: a service portal and a private network authentication agent pre-install a root certificate based on a standard public key infrastructure, and establish a safety message channel through the mutual verification of digital certificates; a user sends an authentication request to a service portal through a client, the service portal forwards authentication information to an authentication agent through a secure channel, and the authentication agent submits the authentication information to a private network LDAP server after protocol conversion; the LDAP server verifies the identity and returns a result, the result is transmitted back to the service portal through the authentication agent and the secure channel, and the service portal generates a short-term token or a black hole cache and feeds back the short-term token or the black hole cache to the client; and the client accesses the service site by the token. According to the invention, the deployment process is simplified, the existing network architecture and security rules of an enterprise are prevented from being changed, the pressure of a private network LDAP server is reduced, and the security, efficiency and system stability of cross-domain authentication are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a user authentication method, system, medium, and device. Background Technology

[0002] As enterprise IT systems extend to the public cloud, business services are distributed across multiple environments, including public clouds, private clouds, and on-premises data centers, requiring cross-domain user authentication. LDAP servers, serving as the unified identity source for the enterprise's private network, cannot be directly migrated to the public cloud due to the requirement for local storage of sensitive data. Therefore, a secure link is needed to enable authentication interaction between public cloud services and the private network LDAP.

[0003] Existing technologies have several problems: some solutions require configuring network endpoints bound to cloud identity management services in the user's virtual private cloud, involving complex routing policies and security group rule configurations, which places high demands on enterprise network operation and maintenance capabilities and is prone to configuration conflicts in complex architectures; some solutions achieve cross-domain authentication through multi-level authentication centers, involving multi-party interactions, cumbersome steps, and failure in any link may lead to authentication failure, and troubleshooting is difficult; some solutions deploy authentication proxies on the public network, which poses a risk of port exposure and vulnerability to network attacks; and some solutions do not clearly define the communication mechanism between remote services and private network authentication servers, requiring additional network access policies to be configured, increasing deployment costs and security risks.

[0004] The aforementioned issues make it difficult to balance deployment complexity, security, stability, and operational efficiency in existing cross-domain authentication solutions, necessitating a lightweight, secure, and low-intrusion solution. Summary of the Invention

[0005] In view of this, this application provides a user authentication method, system, medium and device, the main purpose of which is to provide a lightweight, secure and low-intrusion cross-domain authentication solution.

[0006] According to one aspect of this application, a user authentication method is provided, which is based on a three-tier cross-domain system consisting of a public cloud service portal, a private network authentication proxy, and a private network LDAP server, to enable user authentication through access to a private network LDAP service via a public cloud service. The method includes the following steps: Step 1: The public cloud service portal and the private network authentication agent are pre-installed with root certificates for identity authentication based on standard public key infrastructure. The private network authentication agent initiates a message channel creation application to the public cloud service portal. Both parties verify each other's digital certificates to complete identity verification. Step 2: After identity verification is successful, the private network authentication agent negotiates a session key with the public cloud service portal to establish a secure messaging channel; Step 3: The user sends an authentication request containing authentication information to the public cloud service portal through the client. The public cloud service portal encapsulates the authentication information into an LDAP authentication message and sends it to the private network authentication agent through a secure message channel. Step 4: The private network authentication agent converts the LDAP authentication message according to the protocol and sends it to the private network LDAP server. The private network LDAP server verifies the user's identity and generates the authentication result, and returns the authentication result to the private network authentication agent. Step 5: After the private network authentication agent performs protocol conversion on the authentication result, it sends it back to the public cloud service portal through a secure message channel. The public cloud service portal parses the authentication result. If the authentication is successful, it generates a short-term valid authentication token and returns it to the client. If the authentication fails, it establishes a short-term black hole cache for the authentication information. Step 6: The client receives the information returned by the public cloud service portal. If the authentication is successful, the client saves the authentication token and carries the authentication token when accessing the business site in the future to prove that the identity has been authenticated.

[0007] In one implementation, step 1, in which the public cloud service portal and the private network authentication agent mutually verify each other's digital certificates, includes: The private network authentication agent receives the digital certificate returned by the public cloud service portal, uses the pre-installed root certificate to verify the signature of the public cloud service portal certificate, and submits its own digital certificate to the public cloud service portal after successful verification. The public cloud service portal receives and verifies the digital certificate of the private network authentication agent. After successful verification, a random challenge value is generated, encrypted with the public key in the private network authentication agent's certificate, and sent to the private network authentication agent. The private network authentication agent uses its own private key to decrypt and obtain a random challenge value, signs it, and returns it to the public cloud service portal. The public cloud service portal uses the private network authentication agent's public key to verify the signature.

[0008] In one implementation, in step 2, the private network authentication agent generates a symmetric session key, encrypts it with the public key of the public cloud service portal, and sends it to the public cloud service portal. The public cloud service portal then decrypts the key using its own private key to obtain the session key. Alternatively, the private network authentication agent and the public cloud service portal negotiate the session key through a key exchange algorithm.

[0009] In one implementation, within the secure message channel in step 3, asynchronous messages initiated by the public cloud service portal and messages initiated by the private network authentication agent are distinguished by different flow identifiers, and a separate buffer is established for each flow identifier, with the termination character indicating the end of a single message stream.

[0010] In one implementation, the authentication token generated by the public cloud service portal in step 5 contains user identity information and related permission statements, and is stored in the local cache of the public cloud service portal. When the user accesses the public cloud service later, the public cloud service portal first verifies the session state of the local cache, without having to repeatedly call the private network LDAP server, until the cache expires or the user actively logs out.

[0011] In one implementation, after generating the authentication token in step 5, the public cloud service portal recommends a list of business sites to the client and pushes the authentication token to the business sites. The sites in the business site list are sorted according to their geographical distance from the user's location, with the closer the distance, the higher the ranking.

[0012] In one implementation, when the client accesses the business site recommended by the public cloud service portal in step 6, it carries the authentication token in the request header. The business site then executes the user's business operations by verifying the validity and legitimacy of the token.

[0013] According to one aspect of this application, a user authentication system is provided, comprising a public cloud service portal, a private network authentication proxy, a private network LDAP server, and a client constituting a three-tier cross-domain system. The system achieves user authentication by accessing the private network LDAP service through the public cloud service, wherein: The public cloud service portal is deployed on the public network and is used to receive authentication requests sent by clients, establish a secure message channel with the private network authentication agent, forward authentication information and authentication results, and generate authentication tokens or short-term black hole caches. The private network authentication agent is deployed on the enterprise's private network to establish a secure message channel with the public cloud service portal, perform protocol conversion on authentication information and authentication results, forward authentication information to the private network LDAP server, and receive authentication results. The private LDAP server is deployed on the enterprise's private network and is used to verify user identity and generate authentication results; The client is used to send authentication requests to the public cloud service portal, receive and save authentication tokens, and carry the authentication tokens when accessing business sites.

[0014] According to one aspect of this application, a storage medium is provided that stores a computer program, wherein the computer program is configured to execute the above-described method at runtime.

[0015] According to one aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the methods described above.

[0016] By employing the above technical solutions, the user authentication method, system, medium, and equipment provided in this application have the following specific technical advantages: 1. As a lightweight solution, this application reduces unnecessary node dependencies in traditional solutions, simplifies the overall architecture, and makes the deployment process more streamlined. Enterprises do not need to invest significant resources in maintaining complex multi-node interaction systems. Simultaneously, the reduced risk of failure means that operations and maintenance personnel can more quickly locate and resolve problems, reducing business downtime caused by system failures and improving operational efficiency.

[0017] 2. This application does not require changes to the enterprise's existing network topology, security access rules, or the private deployment mode of the LDAP server, thus avoiding security risks and business fluctuations that may arise from adjusting the network architecture. Through reasonable technical design, secure access to the enterprise's private LDAP server from the public network can meet the authentication requirements of public cloud services while ensuring the security standards of the enterprise's internal network, guaranteeing the security of identity data during transmission and processing.

[0018] 3. This application leverages the caching optimization capabilities of public cloud portals to temporarily store frequently queried authentication results, significantly reducing the number of direct requests to the private network LDAP server. This mechanism reduces the CPU, memory, and network resource consumption of the private network LDAP server, enabling it to handle core authentication tasks more efficiently. Especially in enterprise scenarios with a large user base and high authentication frequency, it can prevent server response delays or lags due to excessive load, ensuring a smooth authentication process and improving the user experience.

[0019] 4. This application supports a multi-service site architecture, which can be used for the dynamic scaling of enterprise IT information service sites. Through the centralized management capabilities of the service portal's authentication information, client authentication tokens are pushed to service sites used for load balancing, improving the scalability of the business system and eliminating performance bottlenecks of a single service site.

[0020] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This application illustrates a user authentication system architecture diagram provided by an embodiment of the present application; Figure 2 A flowchart of a user authentication method provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating an example of a user authentication method provided in this application is shown. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present application can be combined with each other.

[0023] The inventors of this application have discovered that as enterprise IT systems gradually extend to the public cloud, business services are dispersed across multiple environments such as public cloud, private cloud, and local data centers. Mobile users cannot directly access the LDAP server of the enterprise's private network for authentication. Generally, it is necessary to deploy authentication databases in multiple network environments or add network devices to enable inter-domain communication. This not only increases costs but also easily causes inconsistencies in authentication information. Furthermore, network messages may be blocked by firewall devices, leading to authentication failure.

[0024] Based on this, this application proposes a lightweight solution for user authentication via accessing a private network LDAP service through a public cloud service. It establishes a three-tiered cross-domain system consisting of a public cloud service portal, a private network authentication proxy, and a private network LDAP server to authenticate public network users, ensuring the authority of the LDAP service as the enterprise's unified identity source. The service portal is deployed on the public network, providing an authentication entry point for clients and acting as a near-end business node for caching and security protection. The private network authentication proxy is deployed in the enterprise's private network, allowing configuration of a unified enterprise security access policy, restricting access only to the LDAP server for user authentication. A long-lived TCP connection is established between the service portal and the private network authentication proxy for secure forwarding of user authentication messages. Upon successful authentication, the service portal issues a short-term token to the client and synchronizes it to the nearest edge cloud business site, eliminating the need for re-authentication within the token's validity period.

[0025] See Figure 1 This is a schematic diagram of a user authentication system architecture provided in an embodiment of this application.

[0026] like Figure 1As shown in the architecture diagram, this application applies to the following business scenario: An enterprise's IT system is deployed on public and edge clouds. When mobile users or user terminals operating in a public network environment access the IT system's "service portal" through a "client," identity authentication is required. The authentication entity is the enterprise's unified identity authentication server (LDAP server). Users and the enterprise's public cloud and edge cloud services are deployed on a public network environment, while the LDAP server is deployed in a private network environment. The public network is visible to the private network, and all private networks can access the public network, but private networks are not visible to the public network; therefore, the public network cannot access the private network. Based on this, an authentication proxy is needed to establish a secure identity authentication message channel between the public and private networks to enable user authentication through access from the public network to the private network LDAP server.

[0027] The system consists of three components: multiple clients, a public network, and a private network. The public network further includes a public cloud (with a service portal) and multiple edge clouds (with business sites). The private network includes an authentication agent and an LDAP server. The public network, private network, and clients communicate with each other via the Internet.

[0028] Clients (Client 1, Client 2): Serving as the entry point for user interaction with the system, they are used to send authentication requests to the public cloud service portal and, after successful authentication, access business sites with the authentication token.

[0029] Business sites (Edge Cloud 1 Business Site 1, Edge Cloud 2 Business Site 2): Deployed in the edge cloud on the public network, providing various business services. Upon receiving an access request from a client carrying a valid authentication token, the site verifies the token and provides the user with the business operation.

[0030] Service Portal: Deployed on the public cloud, it is the core interaction node on the public network side. It is responsible for receiving authentication requests from clients, establishing secure messaging channels with authentication proxies on the private network, forwarding authentication information and receiving authentication results, generating authentication tokens or short-term black hole caches, and also recommending a list of business sites to clients and pushing authentication tokens.

[0031] Authentication Proxy: Deployed on a private network, it acts as a bridge for communication between the private network and the public network service portal. It establishes a secure message channel with the service portal, performs protocol conversion on authentication information and results, forwards authentication information to the private network LDAP server, and receives authentication results.

[0032] LDAP server: Deployed on a private network, it serves as a unified identity source for the enterprise's private network, used to verify user identities and generate authentication results.

[0033] Specifically, the client and service portal interact via the Internet; the service portal and authentication agent establish a secure messaging channel across public and private networks to facilitate information relay; the authentication agent and LDAP server process authentication information and return results within the private network; and business sites interact with the service portal and clients within the public network based on authentication tokens.

[0034] based on Figure 1 The user authentication system shown involves the client sending an authentication request containing authentication information to the service portal. The service portal encapsulates the authentication information and sends it to the authentication agent through a secure messaging channel established with the authentication agent. The authentication agent performs protocol conversion on the authentication information and forwards it to the LDAP server. The LDAP server verifies the user's identity and generates an authentication result, which is then returned to the authentication agent. The authentication agent performs protocol conversion on the authentication result and sends it back to the service portal through the secure messaging channel. The service portal parses the result; if successful, it generates an authentication token and returns it to the client; if unsuccessful, it establishes a short-term black hole cache. After successful authentication, the client uses the authentication token to access the business site, which verifies the token and provides business services to the user.

[0035] The user authentication system in this application has at least the following technical advantages: Cross-domain secure communication: Through secure messaging channels between service portals and authentication agents, and certificate verification based on standard public key infrastructure, secure authentication information transmission between public and private networks is achieved, ensuring data security and preventing direct exposure of private network resources.

[0036] Simplified deployment and operation: No need to make too many adjustments to the enterprise's existing private network topology, security rules and LDAP server deployment, reducing complex configuration and operation and maintenance costs, and lowering the requirements for the enterprise's network operation and maintenance capabilities.

[0037] Improved authentication efficiency: The service portal's caching mechanism for authentication results reduces duplicate requests to the private network LDAP server. At the same time, the recommendation of business sites sorted by geographical distance improves the efficiency and experience of users accessing services.

[0038] Enhanced system stability: Reduced reliance on intermediate nodes such as multi-level authentication centers, resulting in a simpler authentication chain, lower probability of failures, and more focused troubleshooting on critical interaction links, facilitating rapid location and resolution of problems.

[0039] As can be seen, this paper proposes a lightweight solution to address the need for public cloud services to authenticate users through private network LDAP servers for public cloud service access. This solution simplifies deployment and maintenance, reduces unnecessary node dependencies in traditional solutions, and lowers the risk of failure. It enables secure access to the enterprise LDAP user authentication server from the public network without altering the enterprise network topology, security access rules, or the private deployment mode of the LDAP server. Through the caching optimization capabilities of the service portal, frequently queried authentication results can be temporarily stored, reducing the number of direct requests to the private network LDAP server and lowering its CPU, memory, and network resource consumption. This is particularly suitable for enterprise scenarios with a large user base and high authentication frequency. Furthermore, through the centralized management capabilities of the service portal for authentication information, client authentication tokens can be pushed to business sites used for load balancing, improving the scalability of the business system. The system can be dynamically scaled up or down, eliminating performance bottlenecks of single business sites.

[0040] In summary, the lightweight solution provided in this application reduces unnecessary node dependencies in traditional solutions, simplifies the overall architecture, and makes the deployment process more streamlined. It eliminates the need to change the enterprise's existing network topology, security access rules, and the private deployment mode of the LDAP server, avoiding security risks and business fluctuations that may arise from adjusting the network architecture. Leveraging the caching optimization capabilities of the public cloud portal, frequently queried authentication results are temporarily stored, significantly reducing the processing pressure on the private network LDAP server.

[0041] See Figure 2 The diagram illustrates a user authentication method flowchart provided in an embodiment of this application. The method is based on a three-level cross-domain system consisting of a public cloud service portal, a private network authentication agent, and a private network LDAP server, enabling user authentication through access to the private network LDAP service via the public cloud service. Specifically, it includes the following steps 101-206.

[0042] Step 101: The public cloud service portal and the private network authentication agent are pre-installed with root certificates for identity authentication based on standard public key infrastructure. The private network authentication agent initiates a message channel creation application to the public cloud service portal. Both parties verify each other's digital certificates to complete identity verification. Step 102: After identity verification is successful, the private network authentication agent negotiates a session key with the public cloud service portal to establish a secure messaging channel; Step 103: The user sends an authentication request containing authentication information to the public cloud service portal through the client. The public cloud service portal encapsulates the authentication information into an LDAP authentication message and sends it to the private network authentication agent through a secure message channel. Step 104: The private network authentication agent converts the LDAP authentication message according to the protocol and sends it to the private network LDAP server. The private network LDAP server verifies the user's identity and generates the authentication result, and returns the authentication result to the private network authentication agent. Step 105: After the private network authentication agent performs protocol conversion on the authentication result, it sends it back to the public cloud service portal through a secure message channel. The public cloud service portal parses the authentication result. If the authentication is successful, it generates a short-term valid authentication token and returns it to the client. If the authentication fails, it establishes a short-term black hole cache for the authentication information. Step 106: The client receives the information returned by the public cloud service portal. If the authentication is successful, it saves the authentication token and carries the authentication token when accessing the business site in the future to prove that the identity has been authenticated.

[0043] The user authentication method provided in this application can solve at least the following technical problems: 1. Solve the problem of complex configuration dependencies: In response to the problem that existing technologies require configuring network endpoints bound to cloud services within a virtual private cloud, involving complex routing policies and security group rules, which leads to high requirements for enterprise operation and maintenance capabilities and is prone to configuration conflicts, the "three-level cross-domain system of public cloud service portal, private network authentication proxy, and private network LDAP server" simplifies deployment and configuration without adjusting the enterprise's existing network topology and security rules, and only by pre-setting root certificates and automatically establishing secure channels.

[0044] 2. Solve the problem of redundancy in multi-node interaction: In response to the problems of existing technologies that require multiple authentication centers for cross-domain authentication, involve multiple parties and result in cumbersome steps, high failure risk and difficulty in troubleshooting, a secure message channel is directly established between the service portal and the private network authentication proxy to reduce reliance on intermediate nodes, shorten the authentication link and reduce the probability of failure.

[0045] 3. Addressing Security Risks of Public Network Exposure: To address the issue of existing technologies where authentication proxies are deployed on the public network, leading to port exposure and vulnerability to network attacks, the authentication proxy is deployed on a private network. It communicates with the public network service portal only through a secure reverse-initiated channel, thus avoiding direct exposure of private network resources to the public network and improving security.

[0046] 4. Addressing the issue of additional network policy costs: In response to the problem that existing technologies require configuring fine-grained port mapping or VPN connections for cross-domain communication, which increases deployment costs and security risks, the automatic certificate verification and key negotiation through the service portal and private network authentication proxy eliminate the need for additional network access policies, reducing intrusion.

[0047] In summary, the user authentication method provided in this application, through a three-tier cross-domain system, eliminates the need to adjust the enterprise's existing network topology, security rules, and LDAP server deployment mode, reducing reliance on operational capabilities, avoiding configuration conflicts, and simplifying the deployment process. It reduces intermediate node interactions, using a single secure message channel to forward authentication information, lowering the probability of link failures. Troubleshooting only requires focusing on the interaction link between the service portal and the private network authentication proxy, improving operational efficiency. The private network authentication proxy is deployed within the enterprise intranet, ensuring channel security through certificate verification and encrypted session keys, preventing the exposure of private network resources. Simultaneously, authentication information transmission is encrypted throughout, preventing the leakage of sensitive data. It eliminates the need to configure additional network policies such as port mapping and VPNs, reducing deployment costs and the risk of business fluctuations caused by network adjustments, balancing security and economy. The service portal's caching mechanism for authentication results (generating short-term tokens upon success and establishing black-hole caches upon failure) reduces repeated requests to the private network LDAP server, improving authentication response speed.

[0048] See Figure 3 The diagram shows an example flowchart of a user authentication method provided in this application.

[0049] This example proposes a lightweight solution for user authentication via accessing a private network LDAP service through a public cloud service. It achieves the authentication of public network users by building a three-level cross-domain system consisting of a public cloud service portal, a private network authentication proxy, and a private network LDAP server, including the following steps.

[0050] Step 201: The service portal and authentication agent are pre-installed with root identity certificates based on the X.509 protocol to establish a secure messaging channel between them.

[0051] Step 202: The authentication agent deployed in the private network environment initiates a message channel creation request to the service portal based on the X.509 protocol and requests the service portal to return its own certificate information. When the service portal responds, in addition to returning its own X.509 certificate (containing the service portal's public key, identity information, and root certificate signature), it also requests the authentication agent to provide its digital certificate to verify its identity.

[0052] Step 203: After receiving the service portal certificate, the authentication agent verifies the signature of the service portal certificate using the issuing root certificate declared in the service portal certificate (i.e., the root certificate pre-installed in step 201), confirming the certificate's legality and the authenticity of the service portal's identity. Once the service portal certificate verification is successful, the authentication agent submits its own digital certificate to the service portal.

[0053] Step 204: After receiving the digital certificate from the authentication agent, the service portal executes a similar verification process. Upon successful verification, a random challenge value is generated, encrypted using the public key from the authentication agent's certificate, and sent to the authentication agent. The authentication agent decrypts the random challenge value using its own private key, signs it, and returns it to the service portal. The service portal verifies the signature using the authentication agent's public key, confirming that the authentication agent's private key matches the certificate, thus preventing the authentication agent's certificate information from being leaked and misused by unauthorized devices.

[0054] Step 205: After successful identity verification between both parties, the authentication agent generates a symmetric session key, encrypts it using the service portal's public key, and sends it to the service portal. The service portal can decrypt it using its own private key, or optionally negotiate the session key using a key exchange algorithm such as Diffie-Hellman. All subsequent communication data is encrypted using this session key to ensure data transmission security. At this point, the secure message channel between the service portal and the authentication agent is established.

[0055] Step 206: The user initiates an authentication request, entering authentication information such as username and password on the public cloud service portal. The client sends the username and password to the public cloud service portal, with the password encrypted using an encryption algorithm agreed upon with the LDAP server. The service portal needs to send the request to the enterprise's private LDAP server, but due to network isolation between the public and private networks, direct communication is not possible.

[0056] Step 207: After receiving the authentication request, the public cloud service portal encapsulates the authentication information into an LDAP authentication message and sends it to the authentication agent via the secure message channel created in step 205 (i.e., a message actively sent by the service portal). The asynchronous message initiated by the service portal and the message actively initiated by the authentication agent use different flow IDs to distinguish between the two message flows, and a separate buffer is established for each flow ID. The termination character indicates the end of a single message flow, so there will be no conflict when the two flows send messages simultaneously. This allows a single session connection to be used by multiple business flows simultaneously, upgrading single-channel serial communication to multi-channel parallel communication.

[0057] Step 208: After receiving the authentication information, the authentication agent parses the request format and performs protocol conversion. That is, it converts the message protocol format between the service portal and the authentication agent into the message format between the authentication agent and the LDAP server, conforming to the protocol specifications of the corresponding LDAP server, and assembles it into an authentication request to send to the LDAP server.

[0058] Step 209: Upon receiving the authentication request, the LDAP server executes authentication logic based on locally stored user directories such as user domains, password ciphertext strings under specific encryption algorithms, permissions, and other attributes to verify the legitimacy of the user's identity, generate a success or failure authentication result, and assembles a response message to send to the authentication agent.

[0059] Step 210: The authentication agent receives the response from the LDAP server, converts the message format, and then sends it back to the service portal along the original path.

[0060] Step 211: The service portal parses the response result. If authentication is successful, a short-lived authentication token (such as a JWT) is generated, containing user identity information and related permission statements. This token is stored in the gateway's local cache and returned to the client. If authentication fails, a short-lived black hole cache is created for the username and password, allowing for rapid rejection of identical usernames and passwords, reducing the processing load on the LDAP server. Subsequent accesses to public cloud services by the service portal prioritize verifying the locally cached session state, eliminating the need for repeated calls to the private LDAP network, until the cache expires or the user actively logs out. Simultaneously, to handle large-scale, high-concurrency business scenarios and support load balancing, the service portal recommends a list of business sites to the client and pushes the client's authentication token to the business sites. Sites in the list are ranked according to their geographical distance from the user's location; the closer the site is to the user's location, the higher its ranking. This approach improves the scalability of the business system, allowing for dynamic scaling up and down and eliminating performance bottlenecks associated with single business sites.

[0061] Step 212: The client receives the response message from the service portal and processes it according to the authentication result: If authentication is successful, the client saves the authentication token. Subsequently, when accessing preferred business sites recommended by the service portal, the client includes the token in the request header to prove that the user has been authenticated. When the business site receives a business request from the client carrying the token, it verifies the validity and legality of the token and executes the user's business operation.

[0062] This example has the following technical features and advantages: (1) The service portal and the authentication agent are pre-installed with root certificates for identity authentication based on the X.509 protocol, which are used to establish a secure messaging channel between them. Both parties request each other's digital certificates to verify their identities. After receiving the service portal's certificate, the authentication agent uses its locally pre-installed root certificate, which is also declared in the service portal's certificate, to verify the signature of the service portal's certificate. The service portal verifies the certificate, generates a random challenge value, encrypts it with its certificate's public key, and sends it back. The authentication agent decrypts it, signs it, and returns it to the service portal for verification. The authentication agent generates a session key, encrypts it with the service portal's public key, and the service portal decrypts it with its private key to obtain the key. In this way, a secure messaging channel is created.

[0063] (2) The user initiates an authentication request and enters authentication information, such as account and password, into the public cloud service portal. The client sends the account and password to the public cloud service portal, where the password is encrypted using an encryption algorithm agreed upon with the LDAP server to avoid exposing the plaintext password on the public Internet.

[0064] (3) In the secure message channel, asynchronous messages initiated by the service portal and messages initiated by the authentication agent are distinguished by different flow IDs. A separate buffer is established for each flow ID. The termination character of a single message flow is used to indicate the termination of a single message flow. Therefore, there will be no conflict when the two flows send messages at the same time. This allows a session connection to be used by multiple business flows at the same time, upgrading single-channel serial communication to multi-channel parallel communication.

[0065] (4) The service portal parses the response result. If authentication is successful, it generates a short-lived authentication token (such as a JWT) containing user identity information and related permission statements, stores it in the gateway's local cache, and returns the token to the client. If authentication fails, it also establishes a short-lived black hole cache for username and password information to quickly reject identical usernames and passwords, reducing the processing pressure on the LDAP server. When users access public cloud services subsequently, the service portal will prioritize verifying the locally cached session state, without repeatedly calling the private network LDAP, until the cache expires or the user actively logs out.

[0066] (5) To cope with large-scale, high-concurrency business scenarios, business sites support load balancing. The service portal recommends a list of business sites to clients and pushes the client's authentication token to the business sites. The sites in the list are ranked according to their geographical distance from the user's location; the closer a site is to the user's location, the higher its ranking. This approach improves the scalability of the business system, allowing for dynamic scaling up and down of the system and eliminating performance bottlenecks associated with a single business site.

[0067] (6) When the client receives the response message from the service portal, it processes the authentication result: if the authentication is successful, it saves the authentication token and carries the token in the request header when accessing the preferred business sites recommended by the service portal to prove that the user has been notified of identity authentication.

[0068] In summary, the proposed solution has the following technical advantages: 1. As a lightweight solution, this application reduces unnecessary node dependencies in traditional solutions, simplifies the overall architecture, and makes the deployment process more streamlined. Enterprises do not need to invest significant resources in maintaining complex multi-node interaction systems. Simultaneously, the reduced risk of failure means that operations and maintenance personnel can more quickly locate and resolve problems, reducing business downtime caused by system failures and improving operational efficiency.

[0069] 2. This application does not require changes to the enterprise's existing network topology, security access rules, or the private deployment mode of the LDAP server, thus avoiding security risks and business fluctuations that may arise from adjusting the network architecture. Through reasonable technical design, secure access to the enterprise's private LDAP server from the public network can meet the authentication requirements of public cloud services while ensuring the security standards of the enterprise's internal network, guaranteeing the security of identity data during transmission and processing.

[0070] 3. This application leverages the caching optimization capabilities of public cloud portals to temporarily store frequently queried authentication results, significantly reducing the number of direct requests to the private network LDAP server. This mechanism reduces the CPU, memory, and network resource consumption of the private network LDAP server, enabling it to handle core authentication tasks more efficiently. Especially in enterprise scenarios with a large user base and high authentication frequency, it can prevent server response delays or lags due to excessive load, ensuring a smooth authentication process and improving the user experience.

[0071] 4. This application supports a multi-service site architecture, which can be used for the dynamic scaling of enterprise IT information service sites. Through the centralized management capabilities of the service portal's authentication information, client authentication tokens are pushed to service sites used for load balancing, improving the scalability of the business system and eliminating performance bottlenecks of a single service site.

[0072] Embodiments of this application also provide a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0073] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0074] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0075] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0076] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0077] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0078] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0080] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0082] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0083] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A user authentication method, characterized in that, A three-tiered cross-domain system based on a public cloud service portal, a private network authentication proxy, and a private network LDAP server enables user authentication through access to a private network LDAP service via a public cloud service. The method includes the following steps: Step 1: The public cloud service portal and the private network authentication agent are pre-installed with root certificates for identity authentication based on standard public key infrastructure. The private network authentication agent initiates a message channel creation application to the public cloud service portal. Both parties verify each other's digital certificates to complete identity verification. Step 2: After identity verification is successful, the private network authentication agent negotiates a session key with the public cloud service portal to establish a secure messaging channel; Step 3: The user sends an authentication request containing authentication information to the public cloud service portal through the client. The public cloud service portal encapsulates the authentication information into an LDAP authentication message and sends it to the private network authentication agent through a secure message channel. Step 4: The private network authentication agent converts the LDAP authentication message according to the protocol and sends it to the private network LDAP server. The private network LDAP server verifies the user's identity and generates the authentication result, and returns the authentication result to the private network authentication agent. Step 5: After the private network authentication agent performs protocol conversion on the authentication result, it sends it back to the public cloud service portal through a secure message channel. The public cloud service portal parses the authentication result. If the authentication is successful, it generates a short-term valid authentication token and returns it to the client. If the authentication fails, it establishes a short-term black hole cache for the authentication information. Step 6: The client receives the information returned by the public cloud service portal. If the authentication is successful, the client saves the authentication token and carries the authentication token when accessing the business site in the future to prove that the identity has been authenticated.

2. The method according to claim 1, characterized in that, Step 1 involves the public cloud service portal and the private network authentication agent mutually verifying each other's digital certificates, including: The private network authentication agent receives the digital certificate returned by the public cloud service portal, uses the pre-installed root certificate to verify the signature of the public cloud service portal certificate, and submits its own digital certificate to the public cloud service portal after successful verification. The public cloud service portal receives and verifies the digital certificate of the private network authentication agent. After successful verification, a random challenge value is generated, encrypted with the public key in the private network authentication agent's certificate, and sent to the private network authentication agent. The private network authentication agent uses its own private key to decrypt and obtain a random challenge value, signs it, and returns it to the public cloud service portal. The public cloud service portal uses the private network authentication agent's public key to verify the signature.

3. The method according to claim 1, characterized in that, In step 2, the private network authentication agent generates a symmetric session key, encrypts it with the public key of the public cloud service portal, and sends it to the public cloud service portal. The public cloud service portal decrypts the key with its own private key to obtain the session key; or, the private network authentication agent and the public cloud service portal negotiate the session key through a key exchange algorithm.

4. The method according to claim 1, characterized in that, In step 3, within the secure message channel, asynchronous messages initiated by the public cloud service portal and messages initiated by the private network authentication agent are distinguished by different flow identifiers, and a separate buffer is established for each flow identifier, with the termination character indicating the end of a single message stream.

5. The method according to claim 1, characterized in that, In step 5, the authentication token generated by the public cloud service portal contains user identity information and related permission statements, and is stored in the local cache of the public cloud service portal. When the user accesses the public cloud service later, the public cloud service portal will first verify the session state of the local cache, without having to repeatedly call the private network LDAP server, until the cache expires or the user actively logs out.

6. The method according to claim 1, characterized in that, In step 5, after generating the authentication token, the public cloud service portal recommends the list of business sites to the client and pushes the authentication token to the business sites. The sites in the business site list are sorted according to their geographical distance from the user's location, with the closer the site, the higher the ranking.

7. The method according to claim 6, characterized in that, In step 6, when the client accesses the business site recommended by the public cloud service portal, it carries the authentication token in the request header. The business site executes the user's business operations by verifying the validity and legality of the token.

8. A user authentication system, characterized in that, The system comprises a public cloud service portal, a private network authentication proxy, a private network LDAP server, and a client, forming a three-tiered cross-domain system. User authentication is achieved by accessing the private network LDAP service through the public cloud service. The public cloud service portal is deployed on the public network and is used to receive authentication requests sent by clients, establish a secure message channel with the private network authentication agent, forward authentication information and authentication results, and generate authentication tokens or short-term black hole caches. The private network authentication agent is deployed on the enterprise's private network to establish a secure message channel with the public cloud service portal, perform protocol conversion on authentication information and authentication results, forward authentication information to the private network LDAP server, and receive authentication results. The private LDAP server is deployed on the enterprise's private network and is used to verify user identity and generate authentication results; The client is used to send authentication requests to the public cloud service portal, receive and save authentication tokens, and carry the authentication tokens when accessing business sites.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 7 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 7.

Images