An authentication exception handling method and handling system

Abstract

The present application provides an authentication exception handling method and a handling system, which relate to the field of wireless communication technologies. By obtaining session request data when a terminal authentication exception occurs; then generating a message authentication request for a server when receiving a message according to the session request data, and determining an authentication node among multi-party communications when the server receives the message through the message authentication request; then determining distributed authentication parameters for joint authentication, and determining permission signature information for a client to perform cross-domain access according to the distributed authentication parameters; and determining a risk authentication feature when nodes are separated between a request sent by the client and a reply received, and further determining reorganized authentication information for the client to perform cross-domain access; then determining authorized resources when the terminal authentication is abnormal, and releasing a permission request during the terminal authentication according to the authorized resources. The present application can perform dynamic verification when there is a slow response in permission allocation in a multi-role permission control logic, so as to improve the effectiveness of authentication security protection in communication.

Description

Technical Field

[0001] This application relates to the field of wireless communication technologies. More specifically, this application relates to an authentication exception handling method and a handling system. Background Art

[0002] Wireless communication refers to the technology of information transmission and reception through radio waves or other electromagnetic waves, aiming to achieve remote data exchange between devices without physical connection. It relies on the propagation characteristics of electromagnetic waves, modulates information into signals, transmits them into the air through antennas, and then the receiving devices receive and demodulate them to restore the original information. Wireless communication technologies cover multiple application fields, such as mobile communication, satellite communication, wireless local area networks (such as Wi-Fi), Bluetooth, Zigbee, etc. The advantages of wireless communication include high flexibility, convenience, and wide coverage.

[0003] Existing authentication exception handling methods mainly include several key steps such as monitoring, identification, and response. First, the system collects data by real-time monitoring of users' login behaviors and access patterns to detect abnormal activities. This usually involves using machine learning algorithms and behavior analysis techniques to identify situations deviating from normal behaviors, such as multiple failed login attempts, unauthorized access requests, or logins from abnormal geographical locations. Once a potential authentication exception is identified, the system will trigger a corresponding response mechanism. Common response measures include temporarily locking the account, requiring users to perform additional identity verification (such as two-factor authentication), or restricting access permissions. However, in existing authentication exception handling methods, due to insufficient response speed, obvious information silo phenomenon, and lack of dynamic adjustment ability in the authentication exception handling method, the system cannot take effective measures in time when identifying and dealing with exceptions, reducing the effectiveness of security protection, and thus leading to the exploitation of potential security vulnerabilities, bringing risks to user information and system resources. Therefore, how to perform dynamic verification when there is a response delay in permission allocation in the multi-role permission control logic to improve the effectiveness of authentication security protection in communication is a problem faced by the industry. Summary of the Invention

[0004] This application provides an authentication exception handling method and a handling system, which perform dynamic verification when there is a response delay in permission allocation in the multi-role permission control logic to improve the effectiveness of authentication security protection in communication.

[0005] In a first aspect, this application provides an authentication exception handling method. The handling method includes the following steps:

[0006] Obtain the session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal;

[0007] Generate a message authentication request for the server when receiving a message based on the session request data, and determine the authentication node between multiple parties when the server receives the message through the message authentication request;

[0008] Determine the rights management information when the client sends a message, distribute and merge the rights management information to obtain distributed authentication parameters for joint authentication, and determine the rights signature information when the client performs cross-domain access based on the distributed authentication parameters;

[0009] Determine the authority verification information when the client receives the message, generate a risk authentication feature when the node is separated between the client sending the request and receiving the reply based on the authority verification information and the authentication node, and then determine the reorganized authentication information when the client performs cross-domain access based on the risk authentication feature;

[0010] The authorization resource when the terminal authentication is abnormal is determined according to the authority signature information and the reorganized authentication information, and the authority request when the terminal authentication is abnormal is released according to the authorization resource.

[0011] In this embodiment, session request data refers to the identity, device, network path, and abnormal flag context information collected by the client when the user initiates a message or access request.

[0012] In this embodiment, generating a message authentication request for the server when receiving a message based on the session request data specifically includes:

[0013] Performing session verification on the session request data to obtain session identification information of the server when receiving the message;

[0014] A message authentication request of the server when receiving a message is determined according to the session identification information.

[0015] In this embodiment, determining the authentication node between multiple parties when the server receives the message through the message authentication request specifically includes:

[0016] Determining collaborative verification information of the server when receiving the message according to the message authentication request;

[0017] Determine the task thread queue between multiple communication parties when the server receives messages;

[0018] The server determines an authentication node among multiple parties in communication when receiving a message according to the collaborative verification information and the task thread queue.

[0019] In this embodiment, the rights management information refers to the range of rights set by the system for the user and his / her device, which controls the operations that the user can perform when sending messages.

[0020] In this embodiment, performing distributed fusion on the permission management information to obtain distributed authentication parameters during joint authentication specifically includes:

[0021] Determining the permission attribution information in permission management according to the permission management information;

[0022] Determining the encrypted signature of the distributed cache during joint authentication;

[0023] Mapping the permission attribution information into the encrypted signature to obtain the distributed authentication parameters during joint authentication.

[0024] In this embodiment, determining the permission signature information when the client performs cross - domain access according to the distributed authentication parameters specifically includes:

[0025] Determining the active node queue during cross - domain access according to the distributed authentication parameters;

[0026] Determining the identity identification parameters when the client performs cross - domain access;

[0027] Determining the permission signature information when the client performs cross - domain access according to the active node queue and the identity identification parameters.

[0028] In this embodiment, the permission verification information refers to the permission data related to the user, including the user's role and the message types that can be received.

[0029] In this embodiment, generating the risk authentication feature when the nodes are separated in the client's request and received reply according to the permission verification information and the authentication node specifically includes:

[0030] Determining the permission indication information when the nodes are separated in the client's request according to the permission verification information;

[0031] Determining the authentication allocation information when the nodes are separated in the client's received reply according to the authentication node;

[0032] Determining the risk authentication feature when the nodes are separated in the client's request and received reply through the permission indication information and the authentication allocation information.

[0033] In a second aspect, the present application provides an authentication exception handling system for executing an authentication exception handling method. The handling system includes:

[0034] A data acquisition module for acquiring the session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal;

[0035] An information processing module for generating a message authentication request of the server when receiving a message according to the session request data, and determining the authentication nodes during multi - party communication of the server when receiving a message through the message authentication request.

[0036] An information fusion module, configured to determine the permission management information when the client sends a message, perform distributed fusion on the permission management information to obtain distributed authentication parameters for joint authentication, and determine the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters;

[0037] A feature calibration module, configured to determine the permission verification information when the client receives a message, generate a risk authentication feature when the nodes in the client's request and received reply are separated according to the permission verification information and the authentication node, and further determine the reorganized authentication information for the client to perform cross-domain access from the risk authentication feature;

[0038] A permission execution module, configured to determine the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and release the permission request during the terminal authentication according to the authorized resources.

[0039] The technical solution provided by the disclosed embodiments of the present application has the following beneficial effects:

[0040] By obtaining the session request data of the mobile platform message client when the terminal authentication is abnormal;

[0041] Generating a message authentication request for the server when receiving a message according to the session request data, determining the authentication node among multiple-party communications when the server receives a message through the message authentication request; determining the permission management information when the client sends a message, performing distributed fusion on the permission management information to obtain distributed authentication parameters for joint authentication, and determining the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters; determining the permission verification information when the client receives a message, generating a risk authentication feature when the nodes in the client's request and received reply are separated according to the permission verification information and the authentication node, and further determining the reorganized authentication information for the client to perform cross-domain access from the risk authentication feature; determining the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and releasing the permission request during the terminal authentication according to the authorized resources.

[0042] It can be seen that in this application, dynamic verification can be performed when there is a slow response in the permission allocation of the multi-role permission control logic. Among them, obtaining session request data in real time helps to identify abnormal behaviors in a timely manner, enhance the monitoring ability of potential security threats, ensure that the system can respond quickly, and reduce potential risks. By generating effective message authentication requests, the authentication nodes in multi-party communication can be clarified, thereby enhancing the transparency of the system for multi-role permission control, helping to improve the accuracy of authentication, and reducing security risks caused by information silos. By distributing and integrating permission management information, effectively integrating the permission information of different roles, and providing a consistent authorization basis, it helps to eliminate information silos, improve the system's dynamic adaptation ability to complex permission logics, and thus reduce the slow response during permission allocation. By analyzing permission verification information and authentication nodes to generate risk authentication features, the security of requests can be dynamically evaluated. The generation of these features can achieve real-time evaluation of abnormal behaviors, help to respond quickly during the permission allocation process, and enhance the flexibility of the system. Determining authorized resources based on permission signature information and reorganized authentication information helps the system effectively manage and release permission requests that are no longer needed. This process can optimize the use of resources, improve the efficiency of communication, and ensure the security and effectiveness of the authorization process.

[0043] In summary, the technical solution adopted in this application can perform dynamic verification when there is a slow response in the permission allocation of the multi-role permission control logic, so as to improve the effectiveness of authentication security protection in communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0045] Figure 1 is a flowchart of an authentication exception handling method provided by the present application;

[0046] Figure 2 is a module structure diagram of an authentication exception handling system provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0048] An embodiment of the present application provides an authentication exception handling method and a handling system. The core is to obtain the session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal; generate a message authentication request for the server when receiving the message according to the session request data, and determine the authentication node between multi-party communications when the server receives the message through the message authentication request; determine the permission management information when the client sends the message, perform distributed fusion on the permission management information to obtain the distributed authentication parameters for joint authentication, and determine the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters; determine the permission verification information when the client receives the message, generate a risk authentication feature when the node is separated between the request sent by the client and the reply received according to the permission verification information and the authentication node, and further determine the reorganized authentication information for the client to perform cross-domain access from the risk authentication feature; determine the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and release the permission request during the terminal authentication according to the authorized resources. By adopting the above solution, dynamic verification can be performed when the permission allocation in the multi-role permission control logic is slow to respond, so as to improve the effectiveness of authentication security protection in communication.

[0049] To better understand the above technical solution, the above technical solution will be described in detail below in combination with the accompanying drawings of the specification and specific implementation manners. Refer to Figure 1 As shown, this figure is an exemplary flowchart of the authentication exception handling method according to the present embodiment of the present application. The handling method includes the following steps:

[0050] In step S1, obtain the session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal.

[0051] In specific implementation, when the terminal device detects authentication anomalies (such as invalid login credentials, expired tokens, or multiple authentication failures), the message client will immediately initiate an exception handling process to capture the current session request data. First, when an exception event on the mobile side is captured (such as connection timeout or authentication failure), the client system will automatically start the data collection module. Then, the client will extract key information from the session context, including: user identity information: user ID, role (such as administrator or ordinary user), device information: device type (such as iOS, Android), operating system version, IP address, time and location: session timestamp and geographical location information, and network path: if the message needs to pass through proxy or gateway nodes, record the addresses of these nodes, etc. At the same time, the client will package the type of the current authentication anomaly (such as timeout, access denied) into the request data for the server side to identify. Finally, the data is packaged in JSON format or embedded in the HTTP request header and then sent to the server side through an API or a messaging protocol (such as MQTT). In other embodiments, other methods may also be used to obtain the session request data of the mobile platform message client when the terminal authentication is abnormal, which is not limited here.

[0052] It should be noted that in this application, the session request data refers to the context information such as identity, device, network path, and exception flag collected by the client when the user initiates a message or access request, which can provide sufficient communication and authentication context for the server to ensure the traceability and security of the request.

[0053] In step S2, a message authentication request for the server when receiving a message is generated according to the session request data, and the authentication node in multi-party communication when the server receives the message is determined through the message authentication request.

[0054] In this embodiment, generating a message authentication request for the server when receiving a message according to the session request data can be implemented by the following steps:

[0055] Perform session verification on the session request data to obtain the session identification information for the server when receiving a message;

[0056] Determine the message authentication request for the server when receiving a message according to the session identification information.

[0057] In specific implementation, first, when the server receives the session request data sent by the client, it first performs session verification. The purpose of session verification is to verify whether the request comes from a trusted client and ensure that the session data has not been tampered with or reused, including: checking whether the session data is complete, including fields such as user ID, device information, timestamp, etc., verifying the timestamp in the request to ensure that the request has not timed out and avoid "replay attacks" (i.e., sending the same request multiple times), and matching the session status in the database based on the user ID and device information (such as whether the token is valid and whether the device is trusted). If an anomaly is detected (such as an invalid or tampered token), the server will reject the request and record a log for auditing. After the verification passes, the system generates a session identification information to uniquely identify the session; then, after the verification is successful, the server will construct a message authentication request based on the generated session identification information, including: embedding the session identification information into the message authentication request to ensure that subsequent communications are all based on the context of this session, attaching the user's permission information and device authentication information according to the system policy to ensure that the server clearly knows the scope of permissions it should handle, and encrypting the message authentication request (such as using TLS or HMAC) to prevent man-in-the-middle attacks and data leakage, which is not limited here.

[0058] It should be noted that in this application, the session identification information refers to the identity information and context characteristics that uniquely identify a session, used to ensure the uniqueness and security of subsequent communications; the message authentication request refers to the authentication request generated by the server when receiving a message, including the session identification and permission information, used to verify the legitimacy of the request and ensure the secure transmission of the message.

[0059] In this embodiment, the authentication node among multi-party communications when the server receives a message can be implemented by the following steps according to the message authentication request:

[0060] Determine the collaborative verification information when the server receives a message according to the message authentication request;

[0061] Determine the task thread queue among multi-party communications when the server receives a message;

[0062] Determine the authentication node among multi-party communications when the server receives a message according to the collaborative verification information and the task thread queue.

[0063] In specific implementation, first, the authentication node receives a message authentication request from the client and parses key data such as the session identifier and permission information in the request. The system allocates the verification logic to multiple server nodes based on the message content, session status, and the client's permissions. Each node generates its own collaborative verification information, which is used to coordinate the authentication results in a multi-party communication scenario. For example: Node A is responsible for verifying the user's identity; Node B is responsible for checking the token validity and permission status. Then, the system shares the collaborative verification information among the various nodes to ensure that the same data standard is used by different nodes. Next, the system disassembles the authentication process of the message into multiple small tasks, such as identity verification, token checking, permission matching, etc. Each task is assigned to a thread queue, and each queue is responsible for a different task type. For example: Thread queue 1: Handles user identity verification; Thread queue 2: Handles device authentication and IP checking. Then, the system uses parallel threads to process different task queues to improve processing efficiency. The task threads maintain data synchronization through the collaborative verification information. If an error occurs in a certain task thread (such as token expiration), the system will pause the operation of other thread queues and wait for the task to be retried or return an error status. Finally, based on the collaborative verification information and the task thread queues, the system selects a suitable authentication node to process the request. For example: If the request involves complex permission verification, it is allocated to a node with strong computing power; if it is a normal message verification, it is assigned to a lightweight node for processing. Then, the system dynamically selects the best authentication node according to the load situation of the current node to avoid overloading a certain node. After each node completes the authentication task, the results are aggregated to the main node, and the main node generates the final authentication response. The system will monitor the status of each authentication node in real time. If a certain node fails, the system will automatically switch to the standby node to process the task, which is not limited here.

[0064] It should be noted that in this application, the collaborative verification information is verification data shared among multiple nodes to ensure consistency among different nodes when processing the same request; the task thread queue is a task processing unit composed of multiple threads, which is used to process various verification tasks in authentication in parallel; the authentication node is a server node responsible for executing a part of the authentication task to ensure the security and efficiency of the system in a multi-party communication scenario.

[0065] In step S3, determine the permission management information when the client sends a message, perform distributed fusion on the permission management information to obtain the distributed authentication parameters for joint authentication, and determine the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters.

[0066] In specific implementation, the following method can be used to determine the permission management information when the client sends a message, that is: First, the system collects the user's identity information (such as user ID, role) and device information, and checks whether the device is in the trusted list. For sensitive operations, the system can enable two-factor authentication (such as password + fingerprint). Then, the system loads the user's permission model from the permission database or the RBAC (Role-Based Access Control) model, and binds these permissions to the session context to ensure consistency throughout the session. For example, a salesperson can only view orders within a session, while an administrator can delete orders. If the user's permissions change (such as upgrading from an ordinary user to an administrator), the system will automatically synchronize the latest permissions. Before sending a message, the client needs to initiate a permission verification request. The server verifies according to the permission status and returns an authorization token, which is attached to the message request. To improve performance, the system may temporarily store the permission information in the client cache and set an expiration time to prevent permission abuse. At the same time, the dynamic permission control mechanism adjusts permissions according to time or location. For example, sensitive requests can only be sent during working hours. The whole process ensures the legality of client operations, prevents unauthorized access, and improves system performance and user experience through caching and dynamic control, which will not be elaborated here.

[0067] It should be noted that in this application, the permission management information refers to the permission scope set by the system for users and their devices, which controls the operations that users can perform when sending messages.

[0068] In this embodiment, the distributed fusion of the permission management information to obtain the distributed authentication parameters for joint authentication can be implemented by the following steps:

[0069] Determine the permission attribution information in the permission management according to the permission management information;

[0070] Determine the encrypted signature of the distributed cache for joint authentication;

[0071] Map the permission attribution information into the encrypted signature to obtain the distributed authentication parameters for joint authentication.

[0072] In the specific implementation, first, the system extracts the owner of each permission (such as organization, user or node) from the client's permission management information, and clarifies the source and scope of the permission. For example, the permission for a certain data operation may belong to the "Finance Department" or a specific user role to ensure that there will be no permission conflicts when different departments are authorized. Permission information is classified by role, device or operation type, such as "read permission" and "write permission". Each permission record will be associated with a unique ownership identifier for subsequent permission mapping and signature operations. In cross-domain or multi-system scenarios, permission ownership information needs to be synchronized with multiple nodes to ensure consistency between different systems; then, to improve authentication efficiency, the system stores permission ownership information in a distributed cache so that each node can quickly access it. For example, cache systems such as Redis are used to store recently accessed permission information. To ensure the integrity of cached data Integrity and security, each cache record will generate an encrypted signature. The signature is usually based on a hash algorithm (such as SHA-256) and an encryption key. The system uses a key management service (KMS) to generate and store keys to ensure that the keys are securely shared between nodes and prevent signatures from being tampered with; finally, the system takes the permission ownership information as input, combines it with the encrypted signature in the distributed cache, and maps the permission information to the corresponding signature data. If user A's permission belongs to the "Finance Department", the system will generate a unique signature and bind the ownership information of the "Finance Department" to the signature. The mapped signature and permission ownership information are combined to form a distributed authentication parameter, which is used to determine the user's legitimate authority during joint authentication. When the client initiates an operation request, the system will compare the signature in the request with the signature in the cache to ensure that the permission information has not been tampered with and confirm whether the user has cross-node operation permissions.

[0073] It should be noted that in this application, authority attribution information refers to the organization, user or system node to which the authority belongs, which is used to identify the source and scope of the authority; the encrypted signature is a unique identifier generated based on the key and hash algorithm, which is used to verify the integrity and security of the data; the distributed authentication parameter is the parameter used for authority verification in joint authentication.

[0074] In this embodiment, determining the permission signature information when the client performs cross-domain access based on the distributed authentication parameters can be achieved by using the following steps:

[0075] Determine an active node queue during cross-domain access based on the distributed authentication parameters;

[0076] Determine the client's identity parameters when performing cross-domain access;

[0077] The permission signature information when the client performs cross-domain access is determined according to the active node queue and the identity identification parameter.

[0078] In specific implementation, first, an active node refers to a server or network node that is currently participating in cross-domain communication and contributing to authentication. The system will, according to the real-time status, screen the online and normally operating nodes to form an active node queue. For example, in a multi-server architecture, only the nodes with normal status and timely response will be added to the active queue. The system assigns weights to each node (such as based on latency and load) and arranges them in priority. The status and availability of the nodes will be dynamically updated in the cache to ensure the real-time nature of the queue. When a certain node fails or times out, the system will automatically remove this node and supplement the other nodes into the queue to ensure that the client always communicates with healthy nodes. Then, the identity identification parameter is a unique identifier generated according to the client's identity information (such as user ID, role, device ID) and is used to verify the cross-domain request of this client. The system will check the multi-factor authentication status to ensure that the dual authentication of the user and the device has passed. The system will bind the identity identification parameter with the session ID to ensure that the parameter is only valid in the current session and prevent malicious reuse. For example, the identification parameter of an access request may include a combination of user ID + session ID + timestamp to ensure uniqueness. If the client accesses multiple domains, the system will verify whether the identity identification matches the authorization rules of the target domain to prevent unauthorized access. Finally, the system matches the active node queue with the identity identification parameter and generates a unique permission signature information to verify the legality of the cross-domain request. The permission signature information is generated through an asymmetric encryption algorithm (such as RSA) to ensure that the signature cannot be forged. The server will distribute this signature to all active nodes for subsequent request verification. When the client sends a cross-domain request, the server will compare the signature in the request with the generated permission signature to confirm its authenticity. If the signatures match, access is allowed; if the signature is invalid, the request is rejected and logged, which will not be elaborated here.

[0079] It should be noted that in this application, the active node queue refers to the set of currently online nodes participating in authentication, which is used to ensure the real-time nature and stability of cross-domain access. The identity identification parameter is a unique identifier generated from user and device information and is used to label and verify the client's identity; the permission signature information is an encrypted signature in the identity identification and node status and is used to ensure the legality of cross-domain requests.

[0080] In step S4, determine the permission verification information when the client receives a message, generate a risk authentication feature when the nodes in the client's request and received reply are separated according to the permission verification information and the authentication nodes, and then determine the reorganized authentication information when the client performs cross-domain access from the risk authentication feature.

[0081] In specific implementation, the authority verification information when the client receives a message can be implemented in the following way: First, the system verifies the user's identity to ensure that the message receiver is a legitimate user. This identity confirmation can be achieved through login information, tokens, or biometric technologies. Next, the system loads the user's authority model to ensure that their authorities match their identity. Then, by analyzing session context information such as the session ID and message source, the system evaluates the current authority status to ensure consistency with the user's authority verification information. When obtaining the authority verification information for the message to be received, the system analyzes the message content to determine the involved authority requirements and compares this information with the user's authorities. If the user's authorities are insufficient, the system will reject the message and provide corresponding feedback indicating the reason for the insufficient authority, which will not be elaborated here.

[0082] It should be noted that in this application, the authority verification information refers to the authority data related to the user, including the user's role, the types of messages that can be received, etc.

[0083] In this embodiment, generating the risk authentication feature when the nodes in the client's request and received reply are separated according to the authority verification information and the authentication node can be implemented by the following steps:

[0084] Determine the authority indication information when the nodes in the client's request are separated according to the authority verification information;

[0085] Determine the authentication allocation information when the nodes in the client's received reply are separated according to the authentication node;

[0086] Determine the risk authentication feature when the nodes in the client's request and received reply are separated through the authority indication information and the authentication allocation information.

[0087] In specific implementation, first, the permission indication information is mainly generated by analyzing the permission verification information of the client. For example, if the client has the permission to access specific data, this permission information will be extracted and recorded as the permission indication information. When generating the permission indication information, the system will consider the current context factors, such as the type of request and the target node. This can ensure that the generated permission indication information is effective and reasonable in a specific scenario; then, the authentication node is a specific node responsible for verifying permissions in multi-party communication. The system needs to generate authentication allocation information based on the configuration and status of these nodes. For example, in some cases, the node may dynamically select an appropriate authentication node according to the nature of the request. The system will define an allocation strategy based on the permission indication information to clarify which nodes should be responsible for verifying which requests to achieve load balancing and security control. For example, for highly sensitive operations, the request can be assigned to a dedicated security node for additional verification; finally, the system comprehensively analyzes the permission indication information and the authentication allocation information to generate a complete risk authentication feature. This feature will clarify the risk level of the client request and the necessary security measures in the case of node separation. For example, if the permission indication information shows that the client requests a high-risk operation and there are not enough security nodes participating in the verification in the authentication allocation information, the system will identify this request as high-risk.

[0088] It should be noted that in this application, the permission indication information refers to the specific permission information in the client request in the case of node separation; the authentication allocation information: refers to the authentication verification information assigned to a specific request according to the configuration and status of the authentication node; the risk authentication feature: is a feature generated by combining the permission indication information and the authentication allocation information, used to identify and evaluate the security risk of the request.

[0089] In this embodiment, the recombined authentication information for the client to perform cross-domain access determined by the risk authentication feature can be implemented by the following steps:

[0090] Extract the authentication decision node for the client to perform cross-domain access from the risk authentication feature;

[0091] Determine the standby node queue for the client to perform cross-domain access;

[0092] Determine the recombined authentication information for the client to perform cross-domain access according to the authentication decision node and the standby node queue.

[0093] In specific implementation, first, from the generated risk authentication features, the system needs to extract the key authentication decision nodes. This node is responsible for finally confirming whether the cross-domain access request of the client is legal. For example, the risk authentication features may contain information of multiple nodes, and the system will screen out the authentication node with the highest priority based on this information. When extracting the authentication decision node, the system also needs to confirm the current status of this node (such as online, normal response, etc.) to ensure that it can execute the authentication decision. Then, the standby nodes refer to other nodes that can participate in the authentication process when the authentication decision node is unavailable. These nodes can provide backup support during request processing. The system will determine the standby node queue according to the network topology and node performance to ensure its ability to process authentication requests. The system will dynamically update the standby node queue according to factors such as the current network status, load balancing, and node response time. Only those nodes that are available under specific conditions will be included in the standby list. For example, in a group of servers, if a certain server has too high a load, the system will temporarily remove it from the standby queue to ensure that requests are processed by nodes with better performance. Finally, once the authentication decision node and the standby node queue are determined, the system will analyze these two pieces of information to generate the reorganized authentication information for the client during cross-domain access. This information contains all the parameters required for authentication among different nodes, including security protocols, identity information, access permissions, etc. The reorganized authentication information should be encrypted and digitally signed after generation to ensure the security of the information during transmission and prevent data from being tampered with or forged. The encryption method can be selected as symmetric or asymmetric encryption, which is adjusted according to the specific application scenario and security requirements.

[0094] It should be noted that in this application, the authentication decision node refers to the key node responsible for the final authentication decision in cross-domain access; the standby node queue refers to the set of nodes that can replace it for authentication when the authentication decision node is unavailable; the reorganized authentication information refers to a set of information generated to ensure the legality and security of the client request during multi-party communication or cross-domain access.

[0095] In step S5, according to the permission signature information and the reorganized authentication information, determine the authorized resources when the terminal authentication is abnormal, and release the permission request during terminal authentication according to the authorized resources.

[0096] In this embodiment, determining the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information can be implemented by the following steps:

[0097] Determine the first authentication interaction feature when the terminal authentication is abnormal through the permission signature information;

[0098] Determine the second authentication interaction feature when the terminal authentication is abnormal through the reorganized authentication information;

[0099] Determine the authorized resources when the terminal authentication is abnormal according to the first authentication interaction feature and the second authentication interaction feature.

[0100] In specific implementation, first, extract necessary parameters from the current permission signature information to understand the current permission status of the terminal. For example, if the permission signature information indicates that the terminal has a certain specific access permission, the system will record this information for subsequent analysis. Based on the extracted permission information, the system will construct the first authentication interaction feature, which mainly describes the capabilities and permissions of the terminal in the authentication interaction. This feature may include information related to user roles, session context, and permission scope. Then, the reorganized authentication information contains security parameters for cross-domain access of the client. Key data needs to be extracted from the reorganized authentication information. For example, extracting the reorganized authentication information may involve verifying identity information, access control lists, and other related security protocols. After obtaining the reorganized authentication information, the system will analyze this data and generate the second authentication interaction feature. This feature mainly reflects how the terminal performs security verification and resource access according to the reorganized authentication information in abnormal situations. This feature can include the status of the authentication node, the integrity of information transmission, and the context information of cross-domain access. Finally, after obtaining the first and second authentication interaction features, the system will perform a comprehensive analysis of these two features. Through comparison and matching, the system can identify the resources and permissions that need to be concerned about in the case of abnormal terminal authentication. For example, if the first feature indicates that the terminal has a certain permission, but the second feature shows that there is an abnormality in its authentication process, the system may decide to restrict the terminal from accessing specific resources.

[0101] It should be noted that in this application, the first authentication interaction feature is a feature generated based on the permission signature information, which describes the permission capabilities of the terminal in the authentication interaction; the second authentication interaction feature is a feature generated based on the reorganized authentication information, which describes the security verification and resource access of the terminal in abnormal situations. The authorized resources refer to the accessible resources and permissions determined according to the authentication interaction features in the case of abnormal terminal authentication.

[0102] In specific implementation, the permission request during the authorization resource release terminal authentication can be implemented in the following manner, that is: First, it is necessary to analyze the content of the permission request, including the request type, target resource, and identity information of the request initiator, to confirm the validity of the request. At the same time, the system will check the current authorization resource status, judge the availability of relevant resources and the ongoing permission interaction process, to ensure whether the request needs to be released; Next, the system will match the permission request with the previously determined authorization resources to verify whether the request complies with the security policy and resource allocation rules, and perform compliance checks to ensure compliance with relevant regulations. For example, some operations may require additional review processes to meet internal audit or external compliance requirements; Once it is confirmed that the request is valid and complies with the authorization resources, the system will update the status to release the permission request and record this operation in the database. At the same time, the system will notify the relevant parties (such as terminal users or administrators) to inform them that the permission request has been successfully released. In addition, if any permissions are temporarily granted during the permission request, the system should clean up these permissions in a timely manner after releasing the request to maintain the consistency and security of permission management; Finally, the system will record the detailed information of all release operations, including the timestamp, operator, and request content, to provide necessary evidence for subsequent audits. This process of releasing the permission request not only improves the security and management efficiency of the system, but also supports compliance requirements, ensuring the transparency and traceability of operations.

[0103] It can be seen that in this application, dynamic verification can be carried out when there is a slow response in permission allocation in the multi-role permission control logic; among them, obtaining session request data in real time helps to identify abnormal behaviors in a timely manner, enhances the monitoring ability of potential security threats, can ensure that the system can respond quickly, and reduces potential risks; by generating effective message authentication requests, the authentication nodes in multi-party communication can be clarified, thereby enhancing the transparency of the system for multi-role permission control, helping to improve the accuracy of authentication, and reducing security risks caused by information silos; by distributing and integrating permission management information, effectively integrating the permission information of different roles, providing a consistent authorization basis, helping to eliminate information silos, improving the system's dynamic adaptation ability to complex permission logic, and thus reducing the slow response during permission allocation; by analyzing permission verification information and authentication nodes to generate risk authentication features, the security of requests can be dynamically evaluated, and the generation of this feature can achieve real-time evaluation of abnormal behaviors, helping to respond quickly during the permission allocation process and enhancing the flexibility of the system; determining the authorization resources based on permission signature information and reorganized authentication information helps the system effectively manage and release permission requests that are no longer needed, this process can optimize the use of resources, improve the efficiency of communication, and ensure the security and effectiveness of the authorization process. To sum up, the technical solution adopted in this application can perform dynamic verification when there is a slow response in permission allocation in the multi-role permission control logic to improve the effectiveness of authentication security protection in communication.

[0104] This application provides an authentication exception handling system. Refer to Figure 2 As shown, this figure is a schematic diagram of the authentication exception handling system according to this embodiment of this application. The processing system includes:

[0105] A data acquisition module 100, configured to acquire session request data of information sent by a mobile platform message client when terminal authentication is abnormal;

[0106] An information processing module 200, configured to generate a message authentication request for the server when receiving a message according to the session request data, and determine an authentication node during multi-party communication when the server receives a message through the message authentication request;

[0107] An information fusion module 300, configured to determine permission management information when the client sends a message, perform distributed fusion on the permission management information to obtain distributed authentication parameters during joint authentication, and determine permission signature information for the client to perform cross-domain access according to the distributed authentication parameters;

[0108] A feature calibration module 400, configured to determine permission verification information when the client receives a message, generate a risk authentication feature when the node is separated in the request sent by the client and the reply received according to the permission verification information and the authentication node, and further determine reorganized authentication information for the client to perform cross-domain access from the risk authentication feature;

[0109] A permission execution module 500, configured to determine authorized resources when terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and release a permission request during terminal authentication according to the authorized resources.

[0110] This application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of this application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the specified functions in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0111] Those of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be accomplished by instructing relevant hardware through a program, which can be stored in a computer-readable storage medium. The storage medium includes read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc memories, magnetic disk memories, tape memories, or any other medium that can be used to carry or store data and is computer-readable.

[0112] It should also be noted that the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

Claims

1. A method for handling authentication anomalies, characterized in that, The processing method includes the following steps: Obtain the session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal. When the terminal device detects abnormal authentication, the message client will immediately start the abnormal handling process and capture the current session request data. The session request data refers to the identity, device, network path, and abnormal flag information collected by the client when the user sends a message or access request; Generate a message authentication request for the server when receiving a message according to the session request data, and determine the authentication node during multi-party communication when the server receives a message through the message authentication request; Determine the permission management information when the client sends a message, perform distributed fusion on the permission management information to obtain the distributed authentication parameters during joint authentication, and determine the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters; Determine the permission verification information when the client receives a message, generate a risk authentication feature when the node is separated between the request sent by the client and the reply received according to the permission verification information and the authentication node, and then determine the reorganized authentication information for the client to perform cross-domain access from the risk authentication feature; Determine the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and release the permission request during terminal authentication according to the authorized resources; 2. The authentication exception handling method according to claim 1, wherein Generating a message authentication request for the server when receiving a message according to the session request data specifically includes: Perform session verification on the session request data to obtain the session identification information when the server receives a message; Determine the message authentication request for the server when receiving a message according to the session identification information; 3. The authentication exception handling method according to claim 1, wherein, Determining the authentication node during multi-party communication when the server receives a message through the message authentication request specifically includes: Determine the collaborative verification information for the server when receiving a message according to the message authentication request; Determine the task thread queue during multi-party communication when the server receives a message; Determine the authentication node during multi-party communication when the server receives a message according to the collaborative verification information and the task thread queue; 4. The authentication exception handling method according to claim 1, wherein The permission management information refers to the permission range set by the system for users and their devices, which controls the operations that users can perform when sending messages; 5. The authentication exception processing method according to claim 1, characterized in that, Performing distributed fusion on the permission management information to obtain the distributed authentication parameters during joint authentication specifically includes: Determine the permission attribution information in the permission management according to the permission management information; Determine the encrypted signature of the distributed cache during joint authentication; Map the permission attribution information to the encrypted signature to obtain the distributed authentication parameters during joint authentication; 6. The authentication exception handling method according to claim 1, characterized in that Determining the permission signature information for the client to perform cross-domain access according to the distributed authentication parameters specifically includes: Determine the active node queue during cross-domain access according to the distributed authentication parameters; Determine the identity identification parameters for the client to perform cross-domain access; Determine the permission signature information for the client to perform cross-domain access according to the active node queue and the identity identification parameters; 7. The authentication exception handling method according to claim 1, wherein, The permission verification information refers to the permission data related to the user, including the user's role and the types of messages that can be received.

8. The authentication exception handling method according to claim 1, wherein Generating risk authentication features when nodes are separated in the request sent by the client and the response received, based on the permission verification information and the authentication node, specifically includes: Determining the permission indication information when nodes are separated in the request sent by the client according to the permission verification information; Determining the authentication allocation information when nodes are separated in the response received by the client according to the authentication node; Determining the risk authentication features when nodes are separated in the request sent by the client and the response received through the permission indication information and the authentication allocation information.

9. An authentication exception handling system for executing an authentication exception handling method according to any one of claims 1-8, characterized in that, The processing system includes: A data acquisition module, configured to acquire session request data of the information sent by the mobile platform message client when the terminal authentication is abnormal; An information processing module, configured to generate a message authentication request of the server when receiving a message according to the session request data, and determine the authentication node among multiple-party communications of the server when receiving a message through the message authentication request; An information fusion module, configured to determine the permission management information when the client sends a message, perform distributed fusion on the permission management information to obtain distributed authentication parameters for joint authentication, and determine the permission signature information when the client performs cross-domain access according to the distributed authentication parameters; A feature calibration module, configured to determine the permission verification information when the client receives a message, generate risk authentication features when nodes are separated in the request sent by the client and the response received according to the permission verification information and the authentication node, and further determine the reorganized authentication information when the client performs cross-domain access from the risk authentication features; A permission execution module, configured to determine the authorized resources when the terminal authentication is abnormal according to the permission signature information and the reorganized authentication information, and release the permission request during terminal authentication based on the authorized resources.

Images