Distributed gateway identity mutual trust method and system and related equipment

Abstract

The invention relates to a distributed gateway identity mutual trust method, a distributed gateway identity mutual trust system and related equipment. The method comprises the following steps: sending a registration request containing a digital certificate and an institution code to a second gateway node through a first gateway node; the second gateway node generates and returns a registration response containing the public key certificate and the security policy template in response to the registration request; the first gateway node verifies the validity of the public key certificate and checks whether the security policy template conforms to a preset security policy; if the verification is passed, the first gateway node signs the mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; after the second gateway node verifies the validity of the signature, a trust record with the first gateway node is established and stored, and trust establishment between gateways is completed, so that the technical problem that a cross-domain identity authentication scheme generally depends on a unified identity authentication center and has a single-point fault risk in the prior art is solved; the technical effect of safe and reliable cross-domain identity mutual trust is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network authentication, in particular to a distributed gateway identity mutual trust method, system and related equipment. BACKGROUND

[0002] With the deepening of enterprise digital transformation, large enterprise groups generally adopt distributed architecture to build cross-regional and cross-organizational information systems. The headquarters and multiple secondary units (such as branches and subsidiaries) need to implement unified authentication of user identity and secure sharing of resources. In this context, the identity authentication gateway as the core component of access control undertakes key functions such as user identity verification, access token issuance and cross-domain access control.

[0003] The current mainstream identity mutual trust mechanism is mostly based on the centralized identity provider (IdP) mode, for example, using SAML, OAuth 2.0 or OpenID Connect (OIDC) standard protocols, issuing tokens such as JWT (JSON Web Token) for each branch by a central authentication server, implementing single sign-on (SSO) and cross-domain access. Such solutions have certain advantages in centralized management scenarios, but in cross-organizational and decentralized distributed environments, they expose many security risks and architectural defects.

[0004] In addition, traditional JWT tokens are usually bound to user identity and are not strongly associated with the running environment of terminal devices. Once an attacker steals the JWT of a legitimate user through phishing, man-in-the-middle attacks and other means, the attacker can simulate the user's identity on any device to perform illegal access, resulting in the security risk of "legal ticket illegal use". Although some solutions have tried to introduce device fingerprint technology, they still rely on third-party centralized services for fingerprint verification, and cannot escape the problem of single point of failure and central trust dependency.

[0005] Therefore, how to achieve secure, trusted and dynamic identity mutual recognition between multiple independent organizations without a central trust center, and effectively prevent the abuse of identity tickets on unauthorized devices, has become a technical problem to be solved in the current distributed system security field.

[0006] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0007] The embodiments of the present application provide a distributed gateway identity mutual trust method, system and related equipment to at least solve the technical problem that the cross-domain identity authentication scheme in the prior art generally relies on a unified identity authentication center, and there is a single point of failure risk.

[0008] According to an aspect of the embodiments of the present application, a distributed gateway identity mutual trust method is provided, which is applied to a distributed system composed of at least two gateway nodes deployed in different organizations, and the method comprises: a first gateway node sends a registration request containing a digital certificate and an organization code to a second gateway node; the second gateway node generates and returns a registration response containing a public key certificate and a security policy template in response to the registration request; the first gateway node verifies the validity of the public key certificate and audits whether the security policy template conforms to a preset security policy; if the audit is passed, the first gateway node signs a mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; the second gateway node establishes and stores a trust record with the first gateway node after verifying the validity of the signature, and completes the trust establishment between gateways; wherein the trust record comprises a first gateway node identifier, a public key and a trust state, and is used for identity authentication for cross-domain access.

[0009] Optionally, after the trust establishment between gateways is completed, the method further comprises: a user terminal submits an account password to the first gateway node for identity authentication; the first gateway node returns a script code for collecting device environment features to the user terminal after the authentication is passed; the user terminal executes the script code to collect an environment feature set; the user terminal generates a device fingerprint for the environment feature set and submits it to the first gateway node; the first gateway node constructs a network token, embeds the device fingerprint and a gateway identifier into an extension field, and signs it using a private key; the first gateway node returns the signed network token to the user terminal.

[0010] Optionally, when the user terminal accesses a target resource managed by the second gateway node with the network token, the method comprises: the second gateway node receives a request instruction carrying the network token, parses the network token header to obtain an issuing gateway identifier; according to a locally configured peer gateway list, the second gateway node queries a public key certificate corresponding to the issuing gateway identifier; the second gateway node verifies the validity of the network token signature using the public key and checks whether it is within a valid period; the second gateway node dynamically collects current environment features of the user terminal to generate a real-time fingerprint; the second gateway node compares the historical fingerprint stored in the network token with the real-time fingerprint to determine whether the fingerprint similarity reaches a preset threshold; if the fingerprint similarity reaches the preset threshold and the authorization check is passed, the target resource is allowed to be accessed; otherwise, an exception handling mechanism is triggered.

[0011] Optionally, the abnormality processing mechanism comprises: if the network token signature verification fails, the second gateway node sends a key abnormality alarm to the first gateway node and returns a service unavailable status code; if the trust relationship of the network token has expired but has not exceeded a first preset time, the second gateway node performs degraded verification using a historical public key and re-completes identity authentication through the user terminal; if the device fingerprint comparison does not match, the second gateway node initiates a verification request to the user terminal; after the user terminal inputs and submits a verification code, the second gateway node grants temporary access permission if the verification is passed, and the effective period does not exceed a second preset time; wherein the first preset time is greater than the second preset time.

[0012] Optionally, the method further comprises: the trust monitoring server periodically initiates a query on the digital certificate state of each gateway node; if an abnormal gateway node is detected, the trust monitoring server sends a trust revocation notification to other gateway nodes that have established a trust relationship with the abnormal gateway node; the other gateway nodes receiving the notification update the corresponding trust state to a suspended state and trigger a certificate update process; after the abnormal gateway node obtains a new certificate from the trust monitoring server and completes verification, the trust state of the abnormal gateway node is restored to an active state.

[0013] Optionally, the method further comprises: when a user terminal attempts to access resources managed by a gateway node in a suspended state, the gateway node denies service and prompts that the trust chain is being rebuilt; after the trust state is restored to an active state, the user terminal can re-initiate an authentication process to obtain a valid network token and restore cross-domain access capability.

[0014] Optionally, the policy template defined in the mutual trust protocol comprises a fingerprint comparison threshold, a network token validity period upper limit, a supported encryption algorithm suite and a key rotation period; the first gateway node performs compliance verification on the template parameters according to a local security policy in the audit phase; if the template parameters exceed the security boundary threshold, the trust relationship is refused to be established.

[0015] According to another aspect of the embodiments of the present application, there is provided a distributed gateway identity mutual trust system, comprising at least two gateway nodes deployed in different organizations, respectively a first gateway node and a second gateway node, the first gateway node being in communication connection with the second gateway node through a network; wherein: the first gateway node is configured to send a registration request containing its own digital certificate and organization code to the second gateway node; receive and verify the validity of the public key certificate returned by the second gateway node, and check whether the security policy template provided by the second gateway node conforms to a preset security policy; and after the check passes, sign a mutual trust protocol and send the signed mutual trust protocol to the second gateway node; the second gateway node is configured to, after receiving the registration request of the first gateway node, generate a registration response containing its own public key certificate and security policy template, and return to the first gateway node; and receive the signed mutual trust protocol sent by the first gateway node, verify the validity of the signature, and after the verification passes, establish and store a trust record containing the first gateway node identifier, public key and trust status; wherein the trust record is used for identity authentication for cross-domain access.

[0016] According to another aspect of the embodiments of the present application, there is provided an electronic device, comprising a processor and a memory storing a program, the program comprising instructions which, when executed by the processor, cause the processor to perform the method described in the above.

[0017] According to another aspect of the embodiments of the present application, there is provided a non-transitory machine-readable medium storing computer instructions for causing a computer to perform the method described in any one of the above.

[0018] In the embodiments of the present application, the first gateway node sends a registration request containing a digital certificate and an organization code to the second gateway node; the second gateway node generates and returns a registration response containing a public key certificate and a security policy template in response to the registration request; the first gateway node verifies the validity of the public key certificate and checks whether the security policy template conforms to a preset security policy; if the check passes, the first gateway node signs a mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; and the second gateway node, after verifying the validity of the signature, establishes and stores a trust record with the first gateway node, completes the establishment of trust between gateways, and thus solves the technical problem that the existing cross-domain identity authentication scheme generally relies on a unified identity authentication center and has a single point of failure risk, and achieves the technical effect of realizing secure and reliable cross-domain identity mutual trust. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other embodiments can be obtained from these drawings without creative labor.

[0020] Figure 1 The flow chart of the distributed gateway identity mutual trust method provided by the embodiments of the present application; Figure 2 The flow chart of the dynamic trust establishment provided by the embodiments of the present application; Figure 3 The flow chart of the user authentication and ticket issuing provided by the embodiments of the present application; Figure 4 The flow chart of the cross-domain access verification provided by the embodiments of the present application; Figure 5 The flow chart of the trust relationship exception provided by the embodiments of the present application; Figure 6 The flow chart of the trust relationship maintenance provided by the embodiments of the present application; Figure 7 The structural schematic diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0021] The embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present application are shown in the drawings, it should be understood that the embodiments of the present application can be implemented in various forms, and should not be interpreted as being limited to the embodiments set forth herein, on the contrary, these embodiments are provided to make the embodiments of the present application more thoroughly and completely understood. It should be understood that the drawings and embodiments of the present application are only for exemplary purposes, and are not intended to limit the protection scope of the present application.

[0022] The traditional cross-domain identity authentication scheme usually relies on a centralized identity authentication agency (such as CA center or IDP), all nodes must trust the center, once the center fails, is attacked or misconfigured, the identity authentication function of the whole system will be paralyzed. For this purpose, the present application provides a distributed gateway identity mutual trust method, which is applied to a distributed system composed of at least two gateway nodes deployed in different organizations.

[0023] Figure 1 The flow chart of the distributed gateway identity mutual trust method provided by the embodiments of the present application is shown in FIG. 1, which comprises the following steps: Figure 1 Step S102, the first gateway node sends a registration request containing a digital certificate and an agency code to the second gateway node; ​Step S104, the second gateway node generates and returns a registration response containing the public key certificate and the security policy template in response to the registration request; Step S106, the first gateway node verifies the validity of the public key certificate and checks whether the security policy template meets the preset security policy; Step S108, if the check passes, the first gateway node signs the mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; Step S110, after the second gateway node verifies the validity of the signature, it establishes and stores a trust record with the first gateway node, completing the inter-gateway trust establishment; wherein the trust record includes the first gateway node identifier, the public key and the trust status, and is used for cross-domain access identity authentication.

[0024] In the embodiments of the present application, the first gateway node sends a registration request containing a digital certificate and an agency code to the second gateway node; the second gateway node generates and returns a registration response containing a public key certificate and a security policy template in response to the registration request; the first gateway node verifies the validity of the public key certificate and checks whether the security policy template meets the preset security policy; if the check passes, the first gateway node signs the mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; after the second gateway node verifies the validity of the signature, it establishes and stores a trust record with the first gateway node, completing the inter-gateway trust establishment, thereby solving the technical problem that the existing cross-domain identity authentication scheme generally relies on a unified identity authentication center, which has a single point of failure risk, and achieving the technical effect of secure and reliable cross-domain identity trust.

[0025] It should be noted that the embodiments of the present application achieve decentralized mutual trust by the following design, eliminating the dependence on a unified center: (1) Directly establish a two-way trust relationship between gateway nodes: the trust relationship is no longer granted by a third-party center, but is established by two gateway nodes through the process of registration, verification, and signature of the mutual trust protocol. For example, the first gateway initiates registration to the second gateway, the second gateway returns the public key certificate and the security policy template after verifying the digital certificate and the agency code of the first gateway, and the two parties sign the mutual trust protocol on the premise of meeting the security policy.

[0026] (2) Self-verification mechanism based on digital certificate and signature: each gateway node uses its own digital certificate to prove identity, and confirms the legality of the other party by verifying the validity of the public key certificate and the signature of the mutual trust protocol. This verification method based on public key infrastructure (PKI) does not need to rely on external centers for real-time authentication.

[0027] (3) Local storage of trust records, realizing distributed trust management: Each gateway node locally maintains a trust record table, recording the identification, public key and trust status of other gateway nodes with which it establishes a trust relationship. This distributed storage avoids the single point risk of centralized trust database.

[0028] Figure 2 The flowchart of the dynamic trust establishment provided by the embodiments of the present application is shown in Figure 2 The specific process of the dynamic trust establishment includes: Step 1: The first gateway node sends a registration request containing a digital certificate and an agency code to the second gateway node; the purpose of this process is to enable the first gateway node to be identified by the second gateway node and start the establishment of a trust relationship.

[0029] Step 2: After receiving the registration request, the second gateway node generates a registration response containing a public key certificate and a policy template, and sends it to the first gateway node; in this step, the second gateway node provides the first gateway node with necessary security information and rules for subsequent trust verification and policy execution.

[0030] Step 3: The first gateway node verifies the validity of the public key certificate; this verification process usually involves checking the signature, validity period of the certificate and the integrity of the certificate chain.

[0031] Step 4: The first gateway node audits whether the policy template complies with the preset security policy; after confirming the validity of the certificate, the first gateway node also needs to audit the policy template provided by the second gateway node to ensure that it complies with its own security policy and business requirements. Only when the policy is compliant, can the next step of trust establishment continue.

[0032] Step 5: If the policy template is compliant, the first gateway node signs the mutual trust protocol using the SM2 algorithm and sends it to the second gateway node; this signature ensures the integrity and non-repudiation of the protocol content.

[0033] Step 6: The second gateway node verifies the validity of the signature and stores the trust record containing the first gateway node ID and public key; after receiving the signed mutual trust protocol from the first gateway node, the second gateway node verifies the validity of the signature to confirm that the protocol has not been tampered with. After verification, the second gateway node will store the trust record related to the first gateway node, including the ID and public key of the first gateway node, and set the status to ACTIVE, indicating that the trust relationship has been successfully established.

[0034] Step 7: The second gateway node returns a message to the first gateway node indicating that the trust establishment is successful. At this point, the first gateway node and the second gateway node can perform secure data exchange and communication based on this trust relationship.

[0035] As an optional embodiment, after the trust establishment between the gateways is completed, the method further comprises: the user terminal submits an account password to the first gateway node for identity authentication; the first gateway node returns a script code for collecting device environment features to the user terminal after the authentication is passed; the user terminal executes the script code to collect the environment feature set; the user terminal generates a device fingerprint for the environment feature set and submits the device fingerprint to the first gateway node; the first gateway node constructs a network token, embeds the device fingerprint and the gateway identifier into an extension field, and signs the network token using a private key; and the first gateway node returns the signed network token to the user terminal.

[0036] Figure 3 The flowchart of the user authentication and ticket issuing provided by the embodiments of the present application is shown in FIG. 1, and a specific implementation process of the user authentication and ticket issuing is as follows: Figure 3 Step 1: The user inputs his / her own account and password in a user terminal (which can be a browser) to prepare for identity authentication.

[0037] Step 2: The user terminal sends the account and password of the user to the / auth interface of the first gateway node through an HTTP POST request to start the authentication process.

[0038] Step 3: After receiving the request, the first gateway node verifies the account and password of the user using an LDAP or RADIUS protocol to confirm the legality of the user identity.

[0039] Step 4: After the verification is passed, the first gateway node returns a piece of JavaScript code to the user terminal for executing feature collection.

[0040] Step 5: The user terminal executes the returned JavaScript code to collect various feature information including UserAgent, Canvas rendering data, WebGL parameters and screen attributes, and generates a unique fingerprint (fp) using an SM3 algorithm.

[0041] Step 6: The user terminal submits the generated fingerprint information to the first gateway node through an HTTP request.

[0042] Step 7: After receiving the fingerprint information, the first gateway node constructs a JSON Web Token (JWT) and sets the expiration time of the JWT to the current time plus 8 minutes.

[0043] Step 8: An extension field is added to the JWT, for example, {"fp": fp, "gate":"GW"}, to include the fingerprint information and other necessary identification information.

[0044] ​Step 9: Use the private key of the SM2 algorithm to digitally sign the JWT, ensuring its integrity and tamper resistance.

[0045] Step 10: Finally, the first gateway node sends the signed JWT as an id_token to the user terminal through the Set-Cookie response header, completing the ticket issuance process. After that, the user can use this id_token for identity verification when accessing protected resources.

[0046] In the embodiments of the present application, on the basis of having completed the trust establishment between gateways, a network token (id_token) issuance mechanism of binding user terminal identity authentication and device fingerprint is further introduced, realizing double security authentication of user identity and access device environment. The technical scheme not only strengthens the security of terminal access, but also provides a trusted credential for subsequent identity transfer and risk control in cross-domain access. The following are the specific technical effects realized by the embodiments: (1) Enhance the security of user identity authentication and prevent account theft: Through the combination of "account password + device environment characteristics", a lightweight multi-factor authentication mechanism is formed. Even if the account password is leaked, attackers cannot generate the same device fingerprint on different devices, making it difficult to complete the authentication process. The collected environment characteristics (such as UserAgent, Canvas, WebGL, screen properties) have high uniqueness and are difficult to fake, significantly improving the accuracy of device identification. It effectively prevents common attacks such as dictionary attacks, password brute force attacks, and session hijacking, and improves the security strength of the user identity authentication link.

[0047] (2) Realize the trusted binding of device fingerprint and identity token, and establish traceable access credentials: Embed the generated device fingerprint (fp) and gateway identifier (gate) into the extension field of JWT, forming a strong association between identity and device. Use the SM2 algorithm to digitally sign the JWT, ensuring that the token content is tamper-proof and the source is trusted. A verifiable and tamper-proof identity token (id_token) is constructed, which can be used as an identity credential for subsequent resource access; supports accurate identification of "which user, from which device, via which gateway" when auditing or tracing, improving security auditing capabilities.

[0048] (3) Improve the security and consistency of cross-domain identity transfer: In the distributed gateway trust system, once the user completes authentication at the first gateway and obtains a signed id_token, they can use this token for secure identity transfer when accessing other trusted domain resources. The second gateway node can use the public key of the first gateway to verify the JWT signature and confirm its legitimacy, without the need to repeat the user identity authentication.

[0049] As an optional embodiment, when the user terminal carries the network token to access the target resource managed by the second gateway node, the above method comprises: the second gateway node receives the request instruction carrying the network token, parses the network token header to obtain the issuing gateway identifier; according to the locally configured peer gateway list, the public key certificate corresponding to the issuing gateway identifier is queried; the validity of the network token signature is verified using the public key, and it is checked whether it is within the valid period; the second gateway node dynamically collects the current environmental characteristics of the user terminal to generate a real-time fingerprint; the historical fingerprint stored in the network token is compared with the real-time fingerprint to judge whether the fingerprint similarity reaches the preset threshold; if the fingerprint similarity reaches the preset threshold and the authorization check passes, the access to the target resource is allowed; otherwise, the abnormal processing mechanism is triggered.

[0050] Figure 4 The flowchart of the cross-domain access verification provided by the embodiments of the present application is shown in Figure 4 The specific implementation process of the cross-domain access verification is as follows: Step 1: The user initiates an HTTP request for the resource of the second gateway node through the user terminal, and carries a JWT (JSON Web Token) for identity verification.

[0051] Step 2: After receiving the request, the second gateway node first parses the header information of the JWT to determine the subsequent verification steps.

[0052] Step 3: According to the gate field in the JWT, the second gateway node queries the corresponding public key certificate from the public key cache for verifying the signature of the JWT.

[0053] Step 4: The public key cache returns the public key certificate matching the gate field to the second gateway node.

[0054] Step 5: The second gateway node uses the obtained public key certificate to verify the signature of the JWT to ensure that the JWT has not been tampered with.

[0055] Step 6: After verifying the signature, the second gateway node checks the issue time and expiration time in the JWT to confirm whether the JWT is within the valid period.

[0056] Step 7: In order to further enhance security, the second gateway node initiates a fingerprint verification request to require the user terminal to provide real-time feature data.

[0057] Step 8: The user terminal responds to the request and collects various real-time feature information including UserAgent, Canvas rendering data, WebGL parameters and screen attributes.

[0058] Step 9: The user terminal generates a fingerprint summary using the collected real-time feature information and sends it back to the second gateway node.

[0059] Step 10: After receiving the fingerprint summary, the second gateway node saves it as a real-time fingerprint.

[0060] Step : The second gateway node compares the real-time fingerprint with the stored fingerprint in the JWT and calculates the similarity.

[0061] Step : If the fingerprint similarity is greater than 85%, the second gateway node considers the user identity as trusted and performs Role-Based Access Control (RBAC) authorization checks to confirm whether the user has the right to access the requested resource.

[0062] Step : After the authorization check passes, the second gateway node returns the requested resource to the user terminal, and the user can view the resource content in the user terminal.

[0063] Step : After the user terminal receives the resource, it displays it to the user.

[0064] Step : If the fingerprint similarity is insufficient or the authorization check fails, the second gateway node returns a 401 Unauthorized error, indicating that the user has no right to access the resource.

[0065] Step : For the case of returning a 401 error, the second gateway node may prompt the user to perform secondary authentication, such as through SMS verification code or other means to further verify the identity.

[0066] In the embodiments of the present application, on the basis of the user having obtained the network token (JWT) issued by the first gateway, a secondary identity verification and device environment consistency check mechanism is further implemented during cross-domain access, effectively improving the security and credibility of cross-domain resource access in the distributed gateway system. By combining token signature verification, time validity check, device fingerprint comparison, and authorization control, a complete cross-domain access security verification closed loop is constructed. The following are the main technical effects achieved by this embodiment: (1) Trusted verification of cross-domain identity token is realized to ensure the security of identity transmission: the second gateway identifies the issuing gateway identity by analyzing the gate field in the JWT header, and queries the corresponding public key certificate from the local peer gateway list, and verifies the JWT signature using the public key. Based on the trust relationship established between gateways in advance, only tokens issued by trusted gateways can be accepted. In this way, it can prevent fake identity tokens (such as attackers self-signing JWT) from impersonating legitimate users, implement tamper-proof verification of cross-domain identity information, ensure the trusted circulation of identity credentials in the distributed system, use local cached public keys to improve verification efficiency, and avoid frequent queries to the central node.

[0067] (2) Introduce device fingerprint dynamic comparison mechanism to prevent device camouflage and session hijacking: When accessing target resources, the second gateway dynamically initiates real-time fingerprint collection request to obtain the current environmental characteristics (UserAgent, Canvas, WebGL, screen properties, etc.) of the user terminal, and generates "real-time fingerprint". The "historical fingerprint" carried in the JWT is compared with the real-time fingerprint, and 85% is set as the threshold to judge whether it is the same device. Through this way, device changes, virtual machine / browser simulation, remote control and other high-risk behaviors can be effectively identified; it can prevent attackers from stealing the JWT of a legitimate user and then replaying it on other devices (i.e. "ticket theft"); and it provides continuous identity confirmation capability to enhance access security in a zero-trust architecture.

[0068] (3) Implement fine-grained access control and risk response mechanism: Only when the signature is valid, not expired, fingerprint matched, and authorization passed, can the resource be accessed. If any condition is not met (such as insufficient fingerprint similarity or insufficient permissions), return 401 Unauthorized and trigger an abnormal handling process, such as requiring secondary authentication (SMS verification code, etc.). Through this way, a multi-layer defense mechanism can be built to avoid security vulnerabilities caused by the failure of a single verification link; support for dynamic access control policies based on risk levels to achieve "trusted and released, suspicious and intercepted"; improve the system's perception and response ability to abnormal access behavior, and reduce the probability of security incidents.

[0069] As an optional embodiment, the above abnormal handling mechanism includes: if the network token signature verification fails, the second gateway node sends a key exception alarm to the first gateway node and returns a service unavailable status code; if the trust relationship of the network token has expired but has not exceeded the first preset time, the second gateway node performs downgrade verification using the historical public key and re-completes identity authentication with the user terminal; if the device fingerprint comparison does not match, the second gateway node initiates a verification request to the user terminal; after the user terminal inputs and submits the verification code, the second gateway node grants temporary access rights if the verification is passed, and the effective period does not exceed the second preset time; wherein the first preset time is greater than the second preset time. The first preset time includes but is not limited to 12 hours, 16 hours and 24 hours, etc.; the second preset time includes but is not limited to 15 minutes, 30 minutes, 1 hour, etc.

[0070] Figure 5 The flowchart of the trust relationship exception provided by the embodiments of the present application is shown in Figure 5 The specific implementation process of the trust relationship exception is as follows: Step 1: The user sends a resource request to the second gateway node through the user terminal, but the JWT (JSON Web Token) carried by the user terminal is abnormal.

[0071] Step 2: After receiving the request, the second gateway node verifies the JWT. If the signature is found to be invalid, it proceeds to the exception handling process.

[0072] Step 3: After detecting the invalid signature, the second gateway node sends a key exception alert to the first gateway node, informing it that there may be a problem with the current key.

[0073] Step 4: After receiving the alert, the first gateway node initiates an automatic key rotation mechanism, generates a new key pair, and updates the relevant configurations.

[0074] Step 5: During the key rotation process, the second gateway node cannot handle requests temporarily, so it returns a 503 status code to the user terminal, indicating that the service is temporarily unavailable and is being updated.

[0075] Step 6: If the trust relationship expires, the second gateway node checks the historical public keys used in the past 24 hours to confirm whether there are any cases of not updating in time.

[0076] Step 7: If abnormal conditions such as fingerprint mismatch are found, the second gateway node will require the user to re-authenticate to ensure the validity of the identity.

[0077] Step 8: To further verify the user's identity, the second gateway node sends a one-time password (OTP) verification request to the user.

[0078] Step 9: After receiving the verification request, the user terminal displays a short message verification interface, prompting the user to enter the received verification code.

[0079] Step 10: The user enters the received OTP verification code on the verification interface.

[0080] Step : After the user enters the verification code, the user terminal submits the verification code to the second gateway node for verification.

[0081] Step : After the second gateway node verifies that the verification code is correct, it grants the user temporary access rights with a validity period of 30 minutes, allowing the user to normally access resources during this period.

[0082] In the embodiments of the present application, through the hierarchical exception handling mechanism, accurate response and security recovery are achieved for various trust exceptions in cross-domain access, and the main technical effects are as follows: (1) Ensure key security and respond to signature exceptions in a timely manner: When signature verification fails, send a key exception alert to trigger the first gateway key rotation, preventing key leakage or tampering risks.

[0083] (2) Improve system availability, support trust degradation recovery: when the trust expires but is not more than the first preset time (such as 24 hours), use the historical public key for degraded verification to avoid service interruption and ensure business continuity.

[0084] (3) Dynamic verification of identity, prevent device risk: when the device fingerprint does not match, secondary authentication is performed through user terminal input verification code (such as OTP) to ensure that the real user accesses and prevent ticket theft.

[0085] (4) Control risk window, limit temporary rights: temporary access rights have a short validity period (such as 30 minutes, less than the first preset time), which facilitates users while minimizing the security exposure window.

[0086] As an optional embodiment, the above method further comprises: the trust monitoring server periodically initiates a query on the digital certificate state of each gateway node; if an abnormal gateway node is detected, the trust monitoring server sends a trust revocation notification to other gateway nodes that have established a trust relationship with the abnormal gateway node; the other gateway nodes receiving the notification update the corresponding trust state to the suspended state and trigger the certificate update process; after the abnormal gateway node obtains a new certificate from the trust monitoring server and completes verification, the trust state of the abnormal gateway node is restored to the active state. The above abnormal gateway node is any one of the gateway nodes.

[0087] Figure 6 The flowchart of the trust relationship maintenance provided by the embodiments of the present application is shown in Figure 6 The specific process of the trust relationship maintenance includes: Step 1: The first gateway node and the second gateway node will initiate a certificate state check request to the trust monitoring server every day to ensure that the currently used certificate is valid.

[0088] Step 2: After receiving the check request, the trust monitoring server queries the Online Certificate Status Protocol (OCSP) server to obtain the current state of the certificate and returns the result to the first gateway node and the second gateway node.

[0089] Step 3: If the certificate state is abnormal (for example, the certificate is revoked or expired), the trust monitoring server will send a trust revocation notification to the first gateway node and the second gateway node.

[0090] Step 4: After receiving the revocation notification, the first gateway node and the second gateway node will update the current trust state to SUSPENDED and suspend using the certificate for communication.

[0091] Step 5: After the trust state becomes SUSPENDED, the first gateway node and the second gateway node will request a new certificate from the trust monitoring server.

[0092] Step ⑥: The trust monitoring server generates and sends a new certificate to the first gateway node and the second gateway node.

[0093] Step ⑦: After the first gateway node and the second gateway node receive the new certificate, they will verify it. If the verification is successful, the trust state will be updated to ACTIVE, and normal communication will be restored.

[0094] Step ⑧: When the certificate state is normal, the trust monitoring server will record the results of this check and confirm the validity of the certificate.

[0095] In the embodiments of the present application, the introduction of the trust monitoring server realizes centralized monitoring and automatic response of the gateway certificate state, and the main technical effects are as follows: (1) Periodic query of OCSP, timely discovery of certificate revocation, expiration, etc., and improvement of system security.

[0096] (2) After detecting abnormal nodes, actively send revocation notifications to related gateways to prevent risk spread.

[0097] (3) Related gateways automatically set the trust state to "suspended", and restore it to "active" after obtaining a new certificate verification, realizing closed-loop management of trust state.

[0098] (4) Support for automatic certificate update and trust recovery, avoid long-term interruption, and improve system availability and resilience.

[0099] As an optional embodiment, the above method further comprises: when the user terminal attempts to access the resources managed by the gateway node in the suspended state, the gateway node rejects the service and prompts the trust chain reconstruction; after the trust state is restored to the active state, the user terminal can re-initiate the authentication process to obtain a valid network token and restore the cross-domain access capability.

[0100] Optionally, when the user terminal initiates a resource access request to the gateway node with the trust state "suspended (SUSPENDED)", the gateway node first checks its trust state. If the current gateway is in the suspended state (for example, suspended by the trust monitoring server due to certificate abnormalities), it immediately rejects the service request and returns a specific status code (such as 503 Service Unavailable or a custom status code) and a prompt message to the user terminal: "trust chain reconstruction, please try again later". After receiving the prompt, the user terminal guides the user to wait for the system to automatically recover or manually reattempt access after a period of time. When the abnormal gateway completes certificate update and the trust state is restored to "active (ACTIVE)", the user terminal can re-initiate the authentication process: submit the account password to the first gateway for identity authentication; obtain a new device fingerprint and generate a signed network token (JWT); access the target resource with the new token to restore normal cross-domain access capability.

[0101] In this embodiment, when the gateway node is in a trusted pause state, user access behavior is subject to security control and guidance. Service is denied during periods of abnormal gateway trust status to prevent users from accessing resources through untrusted nodes, thus preventing man-in-the-middle attacks or data leaks. A clear message "Trust chain rebuilding" is displayed to inform users that it is a temporary system maintenance issue rather than a personal permission problem, reducing confusion and accidental operations. Service is only provided when the gateway identity is trusted (active), maintaining the security baseline of the distributed identity system.

[0102] As an optional implementation, the policy template defined in the mutual trust protocol includes fingerprint comparison threshold, network token validity period limit, supported encryption algorithm suites, and key rotation cycle; the first gateway node performs compliance verification on the template parameters according to the local security policy during the review stage; if the template parameters exceed the security boundary threshold, the trust relationship is refused to be established.

[0103] This optional embodiment introduces a structured security policy template into the mutual trust protocol to achieve negotiation and compliance verification of security capabilities between gateway nodes. Key security parameters are verified during the trust establishment phase to prevent subsequent security vulnerabilities caused by inconsistent policies. The specific implementation process is as follows: The mutual trust protocol includes a preset security policy template containing the following key parameters: fingerprint comparison threshold (e.g., minimum allowed similarity of 85%); network token validity period limit (e.g., maximum of 60 minutes); supported encryption algorithm suites (e.g., SM2 / SM3 / SM4, TLS 1.3, etc., national cryptographic or high-security algorithms); and key rotation cycle (e.g., mandatory update of the signing key every 7 days).

[0104] After the first gateway node initiates a registration request to the second gateway and establishes an initial connection, the second gateway returns the policy template in the registration response, which serves as the rule basis for subsequent secure interactions between the two parties.

[0105] After receiving the policy template, the first gateway node compares and verifies it against the locally preset security policy boundaries. For example, if the template allows a token validity period of 120 minutes, while the local policy stipulates that it must not exceed 60 minutes, then it exceeds the boundary; if the template supports weak algorithms such as MD5 or RSA-1024, then it does not meet the encryption strength requirements; if the fingerprint comparison threshold is lower than the locally set bottom line of 80%, then there is a security risk.

[0106] If all parameters are within the limits allowed by the local security policy, the review is approved, and the mutual trust protocol signing continues; if any parameter exceeds the security boundary, the trust relationship is refused to be established, and the reason for refusal is returned to the other party.

[0107] According to another aspect of the embodiments of the present application, a distributed gateway identity mutual trust system is provided, comprising at least two gateway nodes deployed in different organizations, respectively a first gateway node and a second gateway node, the first gateway node and the second gateway node being connected through a network communication; wherein: The first gateway node is configured to send a registration request containing its own digital certificate and organization code to the second gateway node, receive and verify the validity of the public key certificate returned by the second gateway node, and audit whether the security policy template provided by the second gateway node conforms to a preset security policy; and after the audit passes, sign a mutual trust protocol and send the signed mutual trust protocol to the second gateway node.

[0108] The second gateway node is configured to, after receiving the registration request of the first gateway node, generate a registration response containing its own public key certificate and security policy template, and return the registration response to the first gateway node; and receive the signed mutual trust protocol sent by the first gateway node, verify the validity of the signature, and after the verification passes, establish and store a trust record containing the identification, public key and trust status of the first gateway node; wherein the trust record is used for identity authentication for cross-domain access.

[0109] In the embodiments of the present application, the system sends a registration request containing a digital certificate and an organization code from the first gateway node to the second gateway node; the second gateway node generates and returns a registration response containing a public key certificate and a security policy template in response to the registration request; the first gateway node verifies the validity of the public key certificate and audits whether the security policy template conforms to a preset security policy; if the audit passes, the first gateway node signs a mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; the second gateway node establishes and stores a trust record with the first gateway node after verifying the validity of the signature, completes the establishment of trust between gateways, and thus solves the technical problem that the existing cross-domain identity authentication scheme generally relies on a unified identity authentication center and has a single point of failure risk, and achieves the technical effect of realizing secure and reliable cross-domain identity mutual trust.

[0110] According to another aspect of the embodiments of the present application, an electronic device is provided, comprising a processor and a memory storing a program, the program comprising instructions which, when executed by the processor, cause the processor to perform the method of the embodiments of the present application.

[0111] Reference Figure 7An example of a hardware device that can be employed in the electronic device that can be a server or a client of embodiments of the present application will now be described with reference to the block diagram of the electronic device, which is an example of a hardware device that can be employed in aspects of the present application. The electronic device is intended to represent various forms of digital electronic computer devices such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices such as personal digital assistants, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application described and / or claimed in this document.

[0112] As shown in FIG. 7, Figure 7 The electronic device includes a computing unit 701 that can perform various appropriate actions and processes in accordance with a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. Various programs and data required for operation of the electronic device can also be stored in the RAM 703. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0113] Various components in the electronic device are connected to the I / O interface 705, including an input unit 706, an output unit 707, the storage unit 708, and a communication unit 709. The input unit 706 can be any type of device that can input information to the electronic device, and can receive inputted digital or character information, and generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 707 can be any type of device that can present information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 708 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 709 allows the electronic device to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, and a wireless communication transceiver, such as a Bluetooth device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0114] The computing unit 701 can be various general and / or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, CPUs, graphics processing units (GPUs), various specialized artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, or the like. The computing unit 701 performs various methods and processes described above. For example, in some embodiments, the method embodiments of the present application can be implemented as a computer program tangibly embodied in a machine-readable medium, such as the storage unit 708. In some embodiments, portions or all of the computer program can be loaded and / or installed onto the electronic device via the ROM 702 and / or the communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the methods described above by way of, for example, firmware programming.

[0115] Computer programs used to implement embodiments of the present application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer program

[0116] According to another aspect of the embodiments of the present application, a non-transitory machine-readable medium having stored computer instructions for causing a computer to perform the methods of the embodiments of the present application is provided.

[0117] In the context of the embodiments of the present application, a machine-readable medium can be a tangible medium that can contain or store the program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable signal medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more of a line of electrical connection, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0118] It should be noted that the terms "comprises" and "comprising" used in the specification are open-ended, and that the terms "comprises" and "comprising" are used in the specification to indicate that the specification includes the referenced element, but not excluding the presence of additional elements. The term "based on" is intended to mean "based, at least in part, on" unless explicitly stated otherwise. The term "one embodiment" is used to indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. The term "some embodiments" is used to indicate that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least some embodiments. The appearances of the phrase "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiment.

[0119] The various steps of the method embodiments provided by the embodiments of the present application can be performed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit performing the steps shown. The scope of protection of the present application is not limited in this respect.

[0120] The word "embodiment" in the specification means that the specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of the present application. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily mean the same embodiment, nor does it mean independence or alternative to other embodiments. Each embodiment in the specification is described in a relevant manner, and the same or similar parts between each embodiment are cross-referenced. In particular, for device, apparatus, system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts are referred to the part of the method embodiment.

[0121] The above-described embodiments only express several embodiments of the present application, which are described in a more specific and detailed manner, but should not be understood as limiting the scope of patent protection. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A distributed gateway identity mutual trust method, characterized in that, Applied to a distributed system consisting of at least two gateway nodes deployed in different organizations, the method includes: The first gateway node sends a registration request containing the digital certificate and organization code to the second gateway node; In response to the registration request, the second gateway node generates and returns a registration response containing a public key certificate and a security policy template; The first gateway node verifies the validity of the public key certificate and reviews whether the security policy template conforms to the preset security policy; If the review is approved, the first gateway node signs the mutual trust protocol and sends the signed mutual trust protocol to the second gateway node; After verifying the validity of the signature, the second gateway node establishes and stores a trust record with the first gateway node, thus completing the trust establishment between the gateways; wherein, the trust record includes the first gateway node identifier, public key and trust status, and is used for identity authentication for cross-domain access.

2. The method according to claim 1, characterized in that, After establishing trust between gateways, the following steps are also included: The user terminal submits its account and password to the first gateway node for identity authentication. After successful authentication, the first gateway node returns script code for collecting device environmental characteristics to the user terminal; The user terminal executes the script code to collect an environmental feature set; The user terminal generates a device fingerprint based on the environmental feature set and submits it to the first gateway node; The first gateway node constructs a network token, embeds the device fingerprint and gateway identifier into an extended field, and signs it using a private key; The first gateway node returns the signed network token to the user terminal.

3. The method according to claim 2, characterized in that, When the user terminal accesses a target resource managed by the second gateway node carrying the network token, the method includes: The second gateway node receives a request instruction carrying a network token and parses the network token header to obtain the issuing gateway identifier; Based on the locally configured list of peer gateways, query the public key certificate corresponding to the issuing gateway identifier; Use the public key to verify the validity of the network token signature and check whether it is within its validity period; The second gateway node dynamically collects the current environmental characteristics of the user terminal and generates a real-time fingerprint; The historical fingerprints stored in the network token are compared with the real-time fingerprints to determine whether the fingerprint similarity reaches a preset threshold. If the fingerprint similarity reaches the preset threshold and the authorization check passes, access to the target resource is allowed; otherwise, an exception handling mechanism is triggered.

4. The method according to claim 3, characterized in that, The exception handling mechanism includes: If the network token signature verification fails, the second gateway node sends a key abnormality alarm to the first gateway node and returns a service unavailable status code. If the trust relationship of the network token has expired but has not exceeded the first preset time, the second gateway node uses the historical public key to perform downgrade verification and re-completes identity authentication through the user terminal; If the device fingerprint does not match, the second gateway node initiates a verification request to the user terminal. After the user terminal inputs and submits the verification code, the second gateway node grants temporary access if the verification is successful, and the validity period does not exceed the second preset time; wherein, the first preset time is longer than the second preset time.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The trust monitoring server periodically queries the digital certificate status of each gateway node; If an abnormal gateway node is detected, the trust monitoring server sends a trust revocation notification to other gateway nodes that have established a trust relationship with the abnormal gateway node. Other gateway nodes that receive the notification will update their corresponding trust status to paused and trigger the certificate update process. After the abnormal gateway node obtains a new certificate from the trust monitoring server and completes the verification, the trust status of the abnormal gateway node is restored to the active state.

6. The method according to claim 5, characterized in that, The method further includes: When a user terminal attempts to access resources managed by a gateway node that is in a suspended state, the gateway node refuses service and prompts that the trust chain is being rebuilt. After the trust state is restored to the active state, the user terminal can re-initiate the authentication process to obtain a valid network token and restore cross-domain access capabilities.

7. The method according to claim 1, characterized in that, The policy template defined in the mutual trust protocol includes fingerprint comparison threshold, network token validity period limit, supported encryption algorithm suites, and key rotation cycle; During the review phase, the first gateway node performs compliance verification on the template parameters based on its local security policy. If the template parameters exceed the security boundary threshold, the trust relationship will not be established.

8. A distributed gateway identity mutual trust system, characterized in that, It includes at least two gateway nodes deployed in different organizations, namely a first gateway node and a second gateway node, wherein the first gateway node and the second gateway node are connected via network communication; wherein: The first gateway node is configured to send a registration request containing its own digital certificate and organization code to the second gateway node; receive and verify the validity of the public key certificate returned by the second gateway node, and review whether the security policy template provided by the second gateway node conforms to the preset security policy; and after the review is passed, sign the mutual trust protocol and send the signed mutual trust protocol to the second gateway node. The second gateway node is configured to receive the registration request from the first gateway node, generate a registration response containing its own public key certificate and security policy template, and return it to the first gateway node; and receive the signed mutual trust protocol sent by the first gateway node, verify the validity of the signature, and after successful verification, establish and store a trust record containing the first gateway node's identifier, public key, and trust status; wherein, the trust record is used for cross-domain access authentication.

9. An electronic device, comprising: A processor and a memory storing a program, characterized in that the program includes instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 7.

10. A non-transitory machine-readable medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 7.

Images