Distributed gateway identity cross-trust methods, systems, and related devices

Abstract

The application relates to a distributed gateway identity mutual trust method, system and related equipment. The method comprises the following steps: a first gateway node sends a registration request containing a digital certificate and an agency 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 meets 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; after verifying the validity of the signature, the second gateway node establishes and stores a trust record with the first gateway node, completes the trust establishment between the gateways, solves the technical problem that the cross-domain identity authentication scheme in the prior art generally depends on a unified identity authentication center and has a single-point failure risk, and achieves the technical effect of realizing safe and reliable cross-domain identity mutual trust.

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 show 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;

[0021] Figure 2 The flow chart of the dynamic trust establishment provided by the embodiments of the present application;

[0022] Figure 3 The flow chart of the user authentication and ticket issuing provided by the embodiments of the present application;

[0023] Figure 4 The flow chart of the cross-domain access verification provided by the embodiments of the present application;

[0024] Figure 5 The flow chart of the trust relationship exception provided by the embodiments of the present application;

[0025] Figure 6 The flow chart of the trust relationship maintenance provided by the embodiments of the present application;

[0026] Figure 7 The structural schematic diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0027] 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 used to limit the protection scope of the present application.

[0028] 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.

[0029] 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. Figure 1As shown, the method comprises the following steps:

[0030] In step S102, the first gateway node sends a registration request containing a digital certificate and an organization code to the second gateway node.

[0031] In step S104, 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.

[0032] In 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.

[0033] In step S108, if the check passes, the first gateway node signs the mutual trust agreement and sends the signed mutual trust agreement to the second gateway node.

[0034] In step S110, after verifying the validity of the signature, the second gateway node establishes and stores a trust record with the first gateway node, and completes the trust establishment between gateways; wherein the trust record includes the first gateway node identifier, the public key and the trust status, and is used for identity authentication for cross-domain access.

[0035] 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 meets the preset security policy; if the check passes, the first gateway node signs the mutual trust agreement and sends the signed mutual trust agreement 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, and completes the trust establishment between gateways, thereby solving 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 achieving the technical effect of realizing secure and reliable cross-domain identity trust.

[0036] It should be noted that the embodiments of the present application realize decentralized mutual trust by the following design, eliminating the dependence on a unified center:

[0037] (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 mutual trust agreement. For example, the first gateway initiates registration to the second gateway, the second gateway returns a public key certificate and a security policy template after verifying the digital certificate and the organization code of the first gateway, and the two parties sign a mutual trust agreement on the premise of meeting the security policy.

[0038] (2) Self-verification mechanism based on digital certificate and signature: Each gateway node proves its identity using its own digital certificate and confirms its legitimacy by verifying the validity of the other party's public key certificate and mutual trust protocol signature. This PKI-based verification method does not need to rely on external centers for real-time authentication.

[0039] (3) Local storage of trust records to achieve 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 has established trust relationships. This distributed storage avoids the single point risk of centralized trust database.

[0040] 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:

[0041] 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 trust relationship.

[0042] 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 the necessary security information and rules for subsequent trust verification and policy execution.

[0043] 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.

[0044] Step 4: The first gateway node audits whether the policy template complies with the pre-set 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.

[0045] 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.

[0046] Step ⑥: The second gateway node verifies the validity of the signature and stores a trust record containing the first gateway node ID and public key; wherein, after receiving the signature mutual trust agreement of the first gateway node, the second gateway node verifies the validity of the signature to confirm that the agreement 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, public key and other information of the first gateway node, and set the status to ACTIVE, indicating that the trust relationship has been successfully established.

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

[0048] As an optional embodiment, after completing the trust establishment between gateways, it further includes: 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 authentication; 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 it to the first gateway node; the first gateway node constructs a network token, embeds the device fingerprint and gateway identifier into the extension field, and signs it using the private key; the first gateway node returns the signed network token to the user terminal.

[0049] Figure 3 The flowchart of user authentication and ticket issuance provided by the embodiment of the application is shown in Figure 3 The specific implementation process of user authentication and ticket issuance is as follows:

[0050] Step ①: The user inputs his own account and password in the user terminal (which can be a browser) to prepare for identity verification.

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

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

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

[0054] Step ⑤: The user terminal executes the returned JavaScript code, collects various feature information including UserAgent, Canvas rendering data, WebGL parameters, and screen properties, and generates a unique fingerprint (fp) using the SM3 algorithm.

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

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

[0057] Step ⑧: Add an extension field to the JWT, such as {"fp": fp, "gate":"GW"}, to include fingerprint information and other necessary identification information.

[0058] Step ⑨: Use the private key of the SM2 algorithm to digitally sign the JWT to ensure its integrity and tamper resistance.

[0059] Step ⑩: Finally, the first gateway node sends the signed JWT as id_token to the user terminal through the Set-Cookie response header, completing the issuance of the token. After that, the user can use the id_token for identity verification when accessing protected resources.

[0060] In the embodiments of the present application, on the basis of completing the trust establishment between gateways, a network token (id_token) issuance mechanism for 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 transmission and risk control in cross-domain access. The following are the specific technical effects realized by the embodiments:

[0061] (1) Enhance the security of user identity authentication and prevent account theft: Through the combination of "account password + device environment features", 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 features (such as UserAgent, Canvas, WebGL, and screen properties) have high uniqueness and are difficult to fake, significantly improving device identification accuracy. 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.

[0062] (2) Realize the trusted binding of device fingerprint and identity token, and establish traceable access credentials: embed the generated device fingerprint (fp) and gateway identification (gate) into the extension field of JWT to form 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; support for accurate identification of "which user, from which device, via which gateway" when auditing or tracing, to improve security auditing capabilities.

[0063] (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, the token can be used 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 repeating the user identity authentication.

[0064] As an optional embodiment, when the user terminal carries a network token to access the target resource managed by the second gateway node, the above method comprises: the second gateway node receives a request instruction carrying a network token, parses the network token header to obtain the issuing gateway identification; according to the locally configured peer gateway list, the public key certificate corresponding to the issuing gateway identification 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; compare 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 passes, access to the target resource is allowed; otherwise, an abnormal processing mechanism is triggered.

[0065] 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:

[0066] Step 1: The user initiates an HTTP request to the resource of the second gateway node through the user terminal, and carries a JWT (JSON Web Token) for identity verification.

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

[0068] 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.

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

[0070] Step 5: The second gateway node uses the obtained public key certificate to perform signature verification on the JWT, ensuring that the JWT has not been tampered with.

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

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

[0073] 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 properties.

[0074] 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.

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

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

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

[0078] 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.

[0079] Step : The user terminal receives the resource and displays it to the user.

[0080] 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 does not have access to the resource.

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

[0082] In the embodiment of the present application, on the basis that the user has obtained the network token (JWT) issued by the first gateway, identity secondary verification and device environment consistency checking mechanism in cross-domain access are further implemented, effectively improving the security and credibility of cross-domain resource access in the distributed gateway system. By combining token signature verification, time effectiveness inspection, device fingerprint comparison and authorization control, a complete cross-domain access security verification closed loop is constructed. The following are the main technical effects realized by the embodiment:

[0083] (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 previously established between gateways, only tokens issued by trusted gateways can be accepted. In this way, it can prevent fake identity tokens (such as self-signed JWTs by attackers) 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.

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

[0085] (3) Realize 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 dynamic access control policies based on risk levels to realize "trusted to pass, suspicious to block"; improve the system's perception and response ability to abnormal access behavior, and reduce the probability of security incidents.

[0086] As an optional embodiment, the above-mentioned abnormality processing 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 performs degraded verification using the 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 the verification code, the second gateway node grants temporary access permission if the verification is passed, and the validity 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.; and the second preset time includes but is not limited to 15 minutes, 30 minutes, 1 hour, etc.

[0087] 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:

[0088] 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.

[0089] Step 2: After the second gateway node receives the request, it verifies the JWT. If it finds that the signature is invalid, it enters the abnormality processing flow.

[0090] Step 3: After the second gateway node detects that the signature is invalid, it sends a key abnormality alarm to the first gateway node, notifying the first gateway node that the current key may have a problem.

[0091] Step 4: After the first gateway node receives the alarm, it starts the automatic key rotation mechanism, generates a new key pair, and updates the related configuration.

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

[0093] Step 6: If the trust relationship expires, the second gateway node will check the historical public key used in the past 24 hours to confirm whether there is a situation of not being updated in time.

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

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

[0096] Step 9: After receiving the verification request, the user terminal displays a short message verification interface and prompts the user to input the received verification code.

[0097] Step 10: The user inputs the received OTP verification code on the verification interface.

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

[0099] Step : After the second gateway node verifies that the verification code is correct, the user is granted temporary access rights, which are valid for 30 minutes, allowing the user to normally access the resources during this period.

[0100] In the embodiments of the present application, through the hierarchical exception handling mechanism, accurate response and safe recovery of various trust exceptions in cross-domain access are realized, and the main technical effects are as follows:

[0101] (1) Ensure key security and respond to signature exceptions in a timely manner: when the signature verification fails, send a key exception alarm to trigger the first gateway key rotation to prevent key leakage or tampering risks.

[0102] (2) Improve system availability and 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.

[0103] (3) Dynamically verify identity and prevent device risks: when the device fingerprint does not match, input the verification code (such as OTP) through the user terminal for secondary authentication to ensure that the real user accesses and prevent ticket theft.

[0104] (4) Control risk window and limit temporary rights: the validity period of temporary access rights is short (such as 30 minutes, less than the first preset time), which minimizes the security exposure window while facilitating the user.

[0105] 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 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. The above abnormal gateway node is any one of the gateway nodes.

[0106] Figure 6 The flowchart of trust relationship maintenance provided by the embodiments of the present application is as follows:Figure 6 The specific process of maintaining the trust relationship includes:

[0107] Step 1: The first gateway node and the second gateway node will initiate a certificate status check request to the trust monitoring server every day to ensure that the currently used certificate is valid.

[0108] Step 2: After receiving the check request, the trust monitoring server will query the Online Certificate Status Protocol (OCSP) server to obtain the current status of the certificate and return the result to the first gateway node and the second gateway node.

[0109] Step 3: If the certificate status 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.

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

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

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

[0113] Step 7: After receiving the new certificate, the first gateway node and the second gateway node will verify it, and if the verification is successful, they will update the trust status to ACTIVE and restore normal communication.

[0114] Step 8: When the certificate status is normal, the trust monitoring server will record the results of this check to confirm the validity of the certificate.

[0115] In the embodiments of the present application, the trust monitoring server is introduced to realize centralized monitoring and automatic response of the gateway certificate status, and the main technical effects are as follows:

[0116] (1) Periodically query OCSP to timely discover certificate revocation, expiration and other risks, and improve system security.

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

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

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

[0120] As an optional embodiment, the above method further comprises: when the user terminal attempts to access the resource 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.

[0121] Optionally, when the user terminal initiates a resource access request to the gateway node with a trust state of “suspended (SUSPENDED)”, the gateway node first checks its trust state. If the current gateway is in the suspended state (for example, suspended due to certificate exception notified by the trust monitoring server), the service request is immediately rejected, and a specific status code (such as 503 Service Unavailable or a custom status code) and a prompt message “trust chain reconstruction, please try again later” are returned to the user terminal. 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 to complete identity authentication; obtain a new device fingerprint and generate a signed network token (JWT); and access the target resource with the new token to restore normal cross-domain access capability.

[0122] In the embodiments of the present application, when the gateway node is in the trust suspended state, the user access behavior is safely managed and guided, and the service is rejected during the gateway trust state exception, avoiding the user accessing resources through untrusted nodes and preventing man-in-the-middle attacks or data leakage. The prompt “trust chain reconstruction” is clearly given, so that the user understands that it is a temporary system maintenance rather than a personal permission problem, reducing confusion and misoperation. It is ensured that the service is provided only when the gateway identity is trusted (active state), and the security baseline of the distributed identity system is maintained.

[0123] As an optional embodiment, the policy template defined in the mutual trust protocol includes 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 the local security policy in the audit phase; if the template parameters exceed the security boundary threshold, the trust relationship is rejected.

[0124] This optional embodiment introduces a structured security policy template into the mutual trust protocol, realizes the negotiation and compliance verification of the security capabilities between gateway nodes, and checks the key security parameters in the trust establishment phase to prevent security vulnerabilities caused by inconsistent policies later. The specific implementation process is as follows:

[0125] A security policy template is preset in the mutual trust agreement, including the following key parameters: fingerprint comparison threshold (e.g., the minimum allowed similarity is 85%); network token validity period upper limit (e.g., no more than 60 minutes); supported encryption algorithm suite (e.g., SM2 / SM3 / SM4, TLS 1.3, etc. national encryption or high security algorithm); key rotation period (e.g., the signature key is forced to update once every 7 days).

[0126] After the first gateway node initiates a registration request to the second gateway and establishes a preliminary connection, the second gateway returns the policy template in the registration response as the rule basis for subsequent security interaction between the two parties.

[0127] After the first gateway node receives the policy template, it compares and verifies it with the local preset security policy boundary, for example: if the template allows the token validity period to be 120 minutes, but the local regulation stipulates that it should not exceed 60 minutes, it is out of the boundary; if the template supports weak algorithms such as MD5 or RSA-1024, it does not meet the encryption strength requirement; if the fingerprint comparison threshold is lower than the local set 80% bottom line, there is a security risk.

[0128] If all parameters are within the local security policy allowed range, the audit is passed, and the mutual trust agreement signature is continued; if any parameter exceeds the security boundary, the trust relationship is refused to be established, and the refusal reason is returned to the other party.

[0129] According to another aspect of the embodiments of the application, a distributed gateway identity mutual trust system is provided, including at least two gateway nodes deployed in different organizations, respectively being a first gateway node and a second gateway node, the first gateway node and the second gateway node being connected through network communication; wherein:

[0130] 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 meets the preset security policy; and after the audit is passed, sign the mutual trust agreement, and send the signed mutual trust agreement to the second gateway node.

[0131] 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 it to the first gateway node; and receive the signed mutual trust agreement sent by the first gateway node, verify the validity of the signature, and after the verification is passed, 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.

[0132] In the embodiments of the present application, the system sends a registration request containing a digital certificate and an agency code to a second gateway node through a first 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, completes the trust establishment between gateways, and thus solves the technical problem that the cross-domain identity authentication scheme in the prior art 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.

[0133] 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.

[0134] Reference Figure 7 The structure block diagram of an electronic device that can be a server or a client of the embodiments of the present application will now be described, which is an example of a hardware device that can be applied to various aspects of the present application. The electronic device is intended to represent a variety of forms of digital electronic computing devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent a variety of forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown in the figures, their connections, and relationships, and their functions, are merely examples and are not intended to limit the implementations of the present application described and / or claimed herein.

[0135] As shown in 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. In the RAM 703, various programs and data required for the operation of the electronic device can also be stored. 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.

[0136] A plurality of components in the electronic device are connected to the I / O interface 705, including an input unit 706, an output unit 707, a 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.

[0137] The computing unit 701 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a CPU, a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. 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, part 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, by any appropriate means (e.g., by means of firmware), to perform the methods described above.

[0138] The computer program for implementing the method embodiments of the present application can be written in any combination of one or more programming languages. The computer program can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed by the processor or controller, enables the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer program can be executed entirely on the machine, partially on the machine, partially on the machine as a stand-alone software package, and partially on a remote machine or server.

[0139] 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 execute the method embodiments of the present application.

[0140] In the context of the embodiments of the present application, a machine-readable medium can be a tangible medium that contains or stores a 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 the following: an electrical connection based on one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0141] It should be noted that the term "comprising" and variations thereof used in the present application are intended to cover the case where the term "comprising" is replaced by the term "consisting of". The term "based on" is "based at least in part on". The term "one embodiment" means "at least one embodiment". The term "another embodiment" means "at least one additional embodiment". The term "some embodiments" means "at least some embodiments". The terms "a" and "one" are intended to cover the case where there is at least one of the item, and the case where there are more than one of the item. The terms "a" and "one" are used interchangeably herein.

[0142] 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.

[0143] The word "embodiment" in the specification means that the specific feature, structure, or characteristic following the word "embodiment" is included in at least one embodiment of the present application. The appearance of the word "embodiment" in various places in the specification does not necessarily mean that the same embodiment is intended in each instance, nor does it mean that the same embodiment is necessarily independent of or available from other embodiments. Each embodiment of the present application is described in a related manner, and the same or similar parts of each embodiment refer to each other. In particular, for device, apparatus, and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts refer to the part of the method embodiment.

[0144] The above embodiments only express several implementation ways of the present application, and the description is specific and detailed, but it should not be understood as a limitation to the patent protection scope. It should be pointed out that, for ordinary skilled persons in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope 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 to the second gateway node, which includes a digital certificate and an organization code that identifies the organization to which the first gateway node belongs. 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. The security 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. In the step of reviewing whether the security policy template conforms to the preset security policy, the first gateway node performs compliance verification on the template parameters according to the local security policy. If the template parameters exceed the security boundary threshold, the trust relationship is refused to be established. If the review is approved, the first gateway node signs the mutual trust protocol containing the security policy template 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. The trust record includes the first gateway node's identifier, public key, and trust status, and is used to verify the signature of the network token based on the public key when a network token issued by the first gateway node is received. After establishing trust between gateways, the process further includes: the user terminal submitting its account and password to the first gateway node for authentication; after successful authentication, the first gateway node returning script code for collecting device environmental features to the user terminal; the user terminal executing the script code to collect an environmental feature set; the user terminal generating a device fingerprint from the environmental feature set and submitting it to the first gateway node; the first gateway node constructing a network token, embedding the device fingerprint and gateway identifier into an extended field of the network token, and signing the network token with the embedded extended field using a private key; the first gateway node returning the signed network token to the user terminal; and the user terminal carrying the network token... When accessing a target resource managed by the second gateway node, the second gateway node receives a request instruction carrying a network token, parses the network token header to obtain the issuing gateway identifier; queries the public key certificate corresponding to the issuing gateway identifier according to the locally configured trust record; verifies the validity of the network token signature using the public key, and checks 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; 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 passes, access to the target resource is allowed; otherwise, an exception handling mechanism is triggered.

2. The method according to claim 1, 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.

3. The method according to any one of claims 1 to 2, 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.

4. The method according to claim 3, 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.

5. 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 to the second gateway node, containing its own digital certificate and an organization code identifying the organization to which the first gateway node belongs; 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 a preset security policy; and, after the review is passed, sign the mutual trust protocol containing the security policy template, and send the signed mutual trust protocol to the second gateway node; the security policy template defined in the mutual trust protocol includes a fingerprint comparison threshold, a network token validity period limit, a supported suite of encryption algorithms, and a key rotation cycle; in the step of reviewing whether the security policy template conforms to the preset security policy, the first gateway node performs compliance verification on the template parameters according to its local security policy; if the template parameters exceed the security boundary threshold, it refuses to establish a trust relationship; The second gateway node is configured to receive a 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 a 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 to verify the signature of the network token based on the public key when a network token issued by the first gateway node is received; The system is further configured to, after establishing trust between gateways, have the user terminal submit its account and password to the first gateway node for authentication; upon successful authentication, the first gateway node returns script code to the user terminal for collecting device environmental features; the user terminal executes the script code to collect an environmental feature set; the user terminal generates a device fingerprint from 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 of the network token, and signs the network token with the embedded extended field using a private key; the first gateway node returns the signed network token to the user terminal; when the user terminal carries the network token... When a user terminal accesses a target resource managed by the second gateway node, the second gateway node receives a request instruction carrying a network token, parses the network token header to obtain the issuing gateway identifier, queries the public key certificate corresponding to the issuing gateway identifier based on the locally configured trust record, verifies the validity of the network token signature using the public key, and checks 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. It 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 passes, access to the target resource is allowed; otherwise, an exception handling mechanism is triggered.

6. 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 4.

7. 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 4.

Images