Authentication exception processing method and processing system

Abstract

The invention provides an authentication exception processing method and processing system, and relates to the technical field of wireless communication, and the method comprises the steps: obtaining session request data when the authentication of a terminal is exceptional; generating a message authentication request when the server receives a message according to the session request data, and determining authentication nodes among multi-party communication when the server receives the message through the message authentication request; determining distribution authentication parameters during joint authentication, and determining authority signature information during cross-domain access of the client according to the distribution authentication parameters; determining a risk authentication feature when the client sends the request and receives the node in the reply, and further determining recombination authentication information when the client performs cross-domain access; according to the method and the device, the authorization resource when the terminal authentication is abnormal is determined, the authority request when the terminal authentication is released according to the authorization resource, and dynamic check can be carried out when the response of authority distribution in the multi-role authority control logic is slow, so that the validity of authentication security protection in communication is improved.

Description

Technical Field

[0001] The present application relates to the field of wireless communication technology, and more specifically, to an authentication exception processing method and processing system. Background Art

[0002] Wireless communication refers to the technology of transmitting and receiving information through radio waves or other electromagnetic waves. It aims to realize remote data exchange between devices without physical connection. It relies on the propagation characteristics of electromagnetic waves to modulate information into signals, transmit them into the air through antennas, and then receive and demodulate them by the receiving device to restore the original information. Wireless communication technology covers multiple application areas, such as mobile communications, satellite communications, wireless LAN (such as Wi-Fi), Bluetooth, Zigbee, etc. The advantages of wireless communication include high flexibility, convenience and wide coverage.

[0003] The existing authentication anomaly handling methods mainly include several key steps such as monitoring, identification and response. First, the system collects data to detect abnormal activities by monitoring the user's login behavior and access mode in real time. This usually involves the use of machine learning algorithms and behavioral analysis techniques to identify deviations from normal behavior, such as multiple failed login attempts, unauthorized access requests, or logins from abnormal geographic locations. Once a potential authentication anomaly is identified, the system will trigger the corresponding response mechanism. Common response measures include temporarily locking the account, requiring the user to perform additional identity authentication (such as two-factor authentication), or restricting access rights. However, in the existing authentication anomaly handling methods, due to the insufficient response speed of the authentication anomaly handling methods, obvious information island phenomenon, and lack of dynamic adjustment capabilities, the system cannot take effective measures in time when identifying and responding to anomalies, which reduces the effectiveness of security protection, and then leads to potential security vulnerabilities being exploited, bringing risks to user information and system resources. Therefore, how to dynamically check when the permission allocation in the multi-role permission control logic is slow to respond to improve the effectiveness of authentication security protection in communication is a problem faced by the industry. Summary of the invention

[0004] The present application provides an authentication exception handling method and a processing system, which perform dynamic checks when permission allocation in a multi-role permission control logic produces a slow response, so as to improve the effectiveness of authentication security protection in communications.

[0005] In a first aspect, the present application provides a method for handling authentication exceptions, the method comprising the following steps: Obtaining session request data sent by the mobile platform message client when terminal authentication is abnormal; Generate a message authentication request for the server when receiving a message according to the session request data, and determine the authentication node between multiple parties when the server receives the message through the message authentication request; Determine the rights management information when the client sends a message, distribute and merge the rights management information, obtain the distributed authentication parameters during joint authentication, and determine the rights signature information when the client performs cross-domain access according to the distributed authentication parameters; Determine the authority verification information when the client receives the message, generate the risk authentication feature when the node is separated when the client sends the request and receives the reply according to the authority verification information and the authentication node, and then determine the reorganized authentication information when the client performs cross-domain access according to the risk authentication feature; 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.

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

[0007] In this embodiment, generating a message authentication request for the server when receiving a message according to the session request data specifically includes: Performing session verification on the session request data to obtain session identification information of the server when receiving the message; A message authentication request of the server when receiving a message is determined according to the session identification information.

[0008] In this embodiment, determining the authentication node between multiple parties when the server receives the message through the message authentication request specifically includes: Determining collaborative verification information of the server when receiving the message according to the message authentication request; Determine the task thread queue between multiple communication parties when the server receives messages; The authentication node between multiple parties in the server's multi-party communication when receiving the message is determined according to the collaborative verification information and the task thread queue.

[0009] In this embodiment, the permission management information refers to the permission range set by the system for the user and his / her device, which controls the operations that the user can perform when sending a message.

[0010] In this embodiment, the rights management information is distributed and integrated to obtain the distributed authentication parameters during joint authentication, which specifically include: Determine the authority attribution information in the authority management according to the authority management information; Determine the encrypted signature of the distributed cache during joint authentication; The authority attribution information is mapped to the encrypted signature to obtain the distributed authentication parameters for joint authentication.

[0011] In this embodiment, determining the permission signature information when the client performs cross-domain access according to the distributed authentication parameters specifically includes: Determine an active node queue during cross-domain access according to the distributed authentication parameters; Determine the identity parameters of the client when performing cross-domain access; The permission signature information when the client performs cross-domain access is determined according to the active node queue and the identity identification parameter.

[0012] In this embodiment, 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.

[0013] In this embodiment, the risk authentication features generated according to the authority check information and the authentication node when the node between the client sending the request and receiving the reply is separated specifically include: Determine, according to the permission verification information, the permission indication information when the node is separated in the request sent by the client; Determine, according to the authentication node, authentication allocation information when the node is separated in the client receiving the reply; The risk authentication characteristics when the nodes in the client sending the request and receiving the reply are separated are determined by the authority indication information and the authentication allocation information.

[0014] In a second aspect, the present application provides an authentication exception processing system for executing an authentication exception processing method, the processing system comprising: A data acquisition module, used to acquire session request data sent by the mobile platform message client when the terminal authentication is abnormal; An information processing module, used to generate a message authentication request for the server when receiving a message according to the session request data, and determine the authentication node between multiple parties in the server when receiving the message through the message authentication request; An information fusion module is used to determine the rights management information when the client sends a message, distribute and fuse the rights management information, obtain the distributed authentication parameters during joint authentication, and determine the rights signature information when the client performs cross-domain access according to the distributed authentication parameters; A feature calibration module is used to determine the authority verification information when the client receives a message, generate a risk authentication feature when the node is separated when the client sends a request and receives a 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; The permission execution module is used to determine the authorization resource 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 authorization resource.

[0015] The technical solution provided by the embodiments disclosed in this application has the following beneficial effects: By obtaining the session request data of the mobile platform message client when the terminal authentication is abnormal; Generate a message authentication request when the server receives a message according to the session request data, and determine the authentication node between multiple parties in the server's multi-party communication when receiving the message through the message authentication request; determine the authority management information when the client sends a message, distribute and merge the authority management information to obtain the distributed authentication parameters during joint authentication, and determine the authority signature information when the client performs cross-domain access according to the distributed authentication parameters; determine the authority verification information when the client receives the message, and generate the risk authentication feature when the node between the client sending the request and receiving the reply is separated according to the authority verification information and the authentication node, and then determine the reorganized authentication information when the client performs cross-domain access according to the risk authentication feature; determine the authorization resource when the terminal authentication is abnormal according to the authority signature information and the reorganized authentication information, and release the authority request when the terminal authentication is released according to the authorization resource.

[0016] It can be seen that in this application, dynamic inspection can be performed when the permission allocation in the multi-role permission control logic is slow to respond; among them, real-time acquisition of session request data helps to identify abnormal behavior in a timely manner, enhances the monitoring ability of potential security threats, and ensures that the system can respond quickly and reduce potential risks; by generating effective message authentication requests, it is possible to clarify the authentication nodes in multi-party communications, thereby enhancing the transparency of the system's multi-role permission control, helping to improve the accuracy of authentication and reduce security risks caused by information islands; by distributing and integrating permission management information, the permission information of different roles is effectively integrated to provide a consistent The authorization basis helps to eliminate information islands and improve the system's dynamic adaptability to complex permission logic, thereby reducing slow responses when allocating permissions; by analyzing permission check information and authentication nodes, risk authentication features are generated, which can dynamically evaluate the security of requests. The generation of this feature can achieve real-time evaluation of abnormal behavior, 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 resource usage, improve communication efficiency, and ensure the security and effectiveness of the authorization process.

[0017] In summary, the technical solution adopted in this application can perform dynamic checks 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 communications. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0019] Figure 1 is a flowchart of the authentication exception handling method provided by this application; Figure 2 It is a module structure diagram of the authentication exception handling system provided by this application. DETAILED DESCRIPTION

[0020] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0021] The embodiment of the present application provides an authentication exception processing method and processing system, the core of which is to obtain the session request data of the mobile platform message client sending information when the terminal authentication is abnormal; generate the message authentication request of the server when receiving the message according to the session request data, and determine the authentication node between the multi-party communication of the server when receiving the message through the message authentication request; determine the authority management information when the client sends the message, distribute and merge the authority management information, obtain the distributed authentication parameters when the joint authentication is performed, and determine the authority signature information when the client performs cross-domain access according to the distributed authentication parameters; determine the authority verification information when the client receives the message, and generate the risk authentication characteristics when the client sends the request and receives the reply node according to the authority verification information and the authentication node, and then determine the reorganized authentication information when the client performs cross-domain access according to the risk authentication characteristics; determine the authorized resources when the terminal authentication is abnormal according to the authority signature information and the reorganized authentication information, and release the authority request when the terminal authentication is abnormal according to the authorized resources. The above scheme can be used to perform dynamic inspection when the authority allocation in the multi-role authority control logic produces a slow response, so as to improve the effectiveness of authentication security protection in communication.

[0022] In order to better understand the above technical solution, the above technical solution will be described in detail below in conjunction with the accompanying drawings and specific implementation methods. Figure 1 As shown in the figure, this figure is an exemplary flow chart of the authentication exception processing method shown in this embodiment of the present application, and the processing method includes the following steps: In step S1, session request data of information sent by the mobile platform message client when terminal authentication is abnormal is obtained.

[0023] In specific implementation, when the terminal device detects an authentication anomaly (such as invalid login credentials, expired tokens, or multiple authentication failures), the message client will immediately start the exception handling process to capture the current session request data; first, when an abnormal event on the mobile terminal is captured (such as a connection timeout or authentication failure), the client system will automatically start the data acquisition 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 geographic location information and network path: if the message needs to pass through a proxy or gateway node, the addresses of these nodes are recorded, etc.; at the same time, the client will package the type of current authentication anomaly (such as timeout, access denied) into the request data for identification by the server side; finally, the data is packaged in JSON format or embedded in an HTTP request header, and then sent to the server side through an API or a message protocol (such as MQTT). In other embodiments, other methods can also be used to obtain the session request data of the mobile platform message client sending information when the terminal authentication is abnormal, which is not limited here.

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

[0025] In step S2, a message authentication request is generated according to the session request data when the server receives a message, and an authentication node between multiple parties in communication when the server receives a message is determined through the message authentication request.

[0026] In this embodiment, generating a message authentication request of the server when receiving a message according to the session request data can be implemented by the following steps: Performing session verification on the session request data to obtain session identification information of the server when receiving the message; A message authentication request of the server when receiving a message is determined according to the session identification information.

[0027] In specific implementation, first, after receiving the session request data sent by the client, the server first performs session verification on it. 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, and timestamp, checking the timestamp in the request, ensuring that the request has not timed out, and avoiding "replay attacks" (i.e., sending the same request multiple times), matching the session status in the database (such as whether the token is valid and whether the device is trustworthy) according to the user ID and device information, if an abnormality is detected (such as an invalid or tampered token), the server will reject the request and record the log for auditing, after the verification passes, the system generates a session identification information for uniquely identifying the session; then, after the verification succeeds, the server will construct a message authentication request based on the generated session identification information, including: embedding the session identification information in the message authentication request to ensure that subsequent communications are based on the context of the session, attaching the user's permission information and device authentication information according to the system policy, ensuring that the server is clear about the scope of authority 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 are not limited here.

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

[0029] In this embodiment, determining the authentication node between multiple parties when the server receives the message through the message authentication request can be implemented by the following steps: Determining collaborative verification information of the server when receiving the message according to the message authentication request; Determine the task thread queue between multiple communication parties when the server receives messages; The authentication node between multiple parties in the server's multi-party communication when receiving the message is determined according to the collaborative verification information and the task thread queue.

[0030] In the specific implementation, first, the authentication node receives the message authentication request from the client, parses the key data such as the session identifier and permission information in the request, and the system assigns the verification logic to multiple server nodes based on the message content, session status and client permissions. Each node will generate its own collaborative verification information to coordinate the authentication results in multi-party communication scenarios. 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 between nodes to ensure that different nodes use the same data standards; then, the system will break down the message authentication process into multiple small tasks, such as identity authentication, token checking, permission matching, etc. Each task is assigned to a thread queue, and each queue is responsible for different task types. For example: Thread queue 1: Processing user identity verification; Thread queue 2: Processing device authentication and IP checking. Then the system uses parallel threads to process different task queues to improve processing efficiency. Task threads keep data synchronized through collaborative verification information. If an error occurs in a task thread (such as token expiration), the system will suspend 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 queue, the system selects a suitable authentication node to process the request. For example: if the request involves complex permission verification, it is assigned 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 based on the load 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 monitors the status of each authentication node in real time. If a node fails, the system automatically switches to the backup node to process the task. There is no limitation here.

[0031] It should be noted that in this application, collaborative verification information is verification data shared between multiple nodes, which is used to ensure that different nodes maintain consistency 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 certain part of the authentication task, which is used to ensure the security and efficiency of the system in multi-party communication scenarios.

[0032] In step S3, the rights management information when the client sends a message is determined, the rights management information is distributed and integrated to obtain the distributed authentication parameters for joint authentication, and the rights signature information when the client performs cross-domain access is determined according to the distributed authentication parameters.

[0033] In specific implementation, the following method can be used to determine the permission management information when the client sends a message, namely: 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 RBAC (Role-based Access Control) model, and binds these permissions to the session context to ensure consistency throughout the session. For example, sales staff can only view orders in a session, while administrators 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. After passing, it returns an authorization token and attaches it 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 will adjust permissions based on time or location, such as sending sensitive requests during working hours. The entire process ensures that client operations are legal and prevents unauthorized access, while also improving system performance and user experience through caching and dynamic control. I will not go into details here.

[0034] It should be noted that, in this application, 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.

[0035] In this embodiment, the rights management information is distributed and integrated to obtain the distributed authentication parameters for joint authentication, which can be implemented by the following steps: Determine the authority attribution information in the authority management according to the authority management information; Determine the encrypted signature of the distributed cache during joint authentication; The authority attribution information is mapped to the encrypted signature to obtain the distributed authentication parameters for joint authentication.

[0036] 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 between different departments when authorizing. 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 generates 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 to prevent signatures from being tampered with. Finally, the system takes the authority ownership information as input and maps the authority information to the corresponding signature data in combination with the encrypted signature in the distributed cache. If user A's authority belongs to the "Finance Department", the system generates a unique signature and binds the "Finance Department"'s ownership information to the signature. The mapped signature and authority 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 compares the signature in the request with the signature in the cache to ensure that the authority information has not been tampered with and confirm whether the user has cross-node operation authority.

[0037] 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 a key and hash algorithm, which is used to verify the integrity and security of the data; the distributed authentication parameters are parameters used for authority verification in joint authentication.

[0038] In this embodiment, determining the permission signature information when the client performs cross-domain access according to the distributed authentication parameters can be implemented by the following steps: Determine an active node queue during cross-domain access according to the distributed authentication parameters; Determine the identity parameters of the client when performing cross-domain access; The permission signature information when the client performs cross-domain access is determined according to the active node queue and the identity identification parameter.

[0039] In specific implementation, first of all, active nodes refer to servers or network nodes that are currently participating in cross-domain communication and contributing to authentication. The system will filter online and normal nodes to form an active node queue based on real-time status. For example, in a multi-server architecture, only nodes with normal status and timely response will be added to the active queue. The system assigns a weight to each node (such as based on latency and load) and arranges them by priority. The status and availability of the node will be dynamically updated in the cache to ensure the real-time nature of the queue. When a node goes down or times out, the system will automatically remove the node and add other nodes to the queue to ensure that the client always communicates with healthy nodes. Then, the identity parameter is a unique identifier generated based on the client's identity information (such as user ID, role, device ID) and is used to verify the client's cross-domain request. The system will check the multi-factor authentication status to ensure that the dual authentication of the user and device has passed. The system will bind the identity parameter to the session ID to ensure that the parameter is only valid in the current session to 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 matches the authorization rules of the target domain to prevent unauthorized access. Finally, the system matches the active node queue with the identity parameter and generates a unique permission signature information to verify the legitimacy of the cross-domain request. The permission signature information is generated using an asymmetric encryption algorithm (such as RSA) to ensure that the signature cannot be forged. The server will distribute the 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 signature matches, access is allowed; if the signature is invalid, the request is rejected and the log is recorded. I will not go into details here.

[0040] It should be noted that in this application, the active node queue refers to the set of nodes that are currently online and participate in authentication, which is used to ensure the real-time and stability of cross-domain access. The identity identification parameter is a unique identifier generated by user and device information, which is used to mark and verify the client identity; the permission signature information is an encrypted signature in the identity identification and node state, which is used to ensure the legitimacy of cross-domain requests.

[0041] In step S4, the authority verification information when the client receives the message is determined, and the risk authentication characteristics when the node is separated when the client sends a request and receives a reply are generated based on the authority verification information and the authentication node, and then the reorganized authentication information when the client performs cross-domain access is determined by the risk authentication characteristics.

[0042] In specific implementation, the permission verification information when the client receives the message can be determined in the following way, namely: first, the system verifies the user's identity to ensure that the message recipient is a legitimate user. This identity confirmation can be achieved through login information, tokens, or biometric technology. Next, the system loads the user's permission model to ensure that its permissions match its identity. Then, by analyzing session context information, such as session ID and message source, the system evaluates the current permission status to ensure that it is consistent with the user's permission verification information. When obtaining the permission verification information of the message to be received, the system will analyze the message content, determine the permission requirements involved, and compare this information with the user's permissions. If the user's permissions are insufficient, the system will refuse to receive the message and provide corresponding feedback, prompting the user's reasons for insufficient permissions, which will not be repeated here.

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

[0044] In this embodiment, the risk authentication feature when the node is separated when the client sends a request and receives a reply can be generated according to the authority verification information and the authentication node, which can be implemented by the following steps: Determine, according to the permission verification information, the permission indication information when the node is separated in the request sent by the client; Determine, according to the authentication node, authentication allocation information when the node is separated in the client receiving the reply; The risk authentication characteristics when the nodes in the client sending the request and receiving the reply are separated are determined by the authority indication information and the authentication allocation information.

[0045] In the 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, the permission information will be extracted and recorded as the permission indication information. When generating the permission indication information, the system will consider the current contextual factors, such as the type of request and the target node. This ensures that the generated permission indication information is valid 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 based on 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, requests can be assigned to dedicated security nodes for additional verification; finally, the system will conduct a comprehensive analysis of the permission indication information and the authentication allocation information to generate a complete risk authentication feature. This feature will clarify the risk level of client requests and 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 involved in the verification in the authentication allocation information, the system will mark the request as high-risk.

[0046] It should be noted that in this application, permission indication information refers to the specific permission information in the client request when the nodes are separated; authentication allocation information refers to the authentication verification information assigned to a specific request based on the configuration and status of the authentication node; risk authentication feature refers to the feature generated by combining the permission indication information and the authentication allocation information, which is used to identify and assess the security risks of the request.

[0047] In this embodiment, the reorganization authentication information when the client performs cross-domain access determined by the risk authentication feature can be implemented by the following steps: Extracting an authentication decision node when a client performs cross-domain access from the risk authentication feature; Determine the candidate node queue when the client performs cross-domain access; The reorganized authentication information when the client performs cross-domain access is determined according to the authentication decision node and the candidate node queue.

[0048] In the specific implementation, first of all, the system needs to extract the key authentication decision node from the generated risk authentication features. This node is responsible for finally confirming whether the client's cross-domain access request is legal. For example, the risk authentication feature may contain information of multiple nodes. The system will filter 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 the node (such as online, normal response, etc.) to ensure that it can execute the authentication decision; then, the standby node refers 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 based on the network topology and node performance to ensure that it has the ability to process authentication requests. The system will dynamically update the standby node queue based on factors such as the current network status, load balancing, and node response time. Only those nodes that are available under certain conditions will be included in the standby list. For example, in a group of servers, if a server is overloaded, the system will temporarily remove it from the standby queue to ensure that the request is processed by a node 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 reorganized authentication information for client cross-domain access. This information contains all the parameters required for authentication between different nodes, including security protocols, identity information, and access rights. 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 symmetric or asymmetric, and can be adjusted according to the specific application scenario and security requirements.

[0049] 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 the authentication decision node for authentication when the authentication decision node is unavailable; the reorganized authentication information refers to a set of information generated during multi-party communication or cross-domain access to ensure the legitimacy and security of the client request.

[0050] In step S5, 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 during the terminal authentication is released according to the authorization resource.

[0051] In this embodiment, determining the authorization resource when the terminal authentication is abnormal according to the authority signature information and the reorganized authentication information can be implemented by the following steps: Determine the first authentication interaction feature when the terminal authentication is abnormal through the authority signature information; Determining a second authentication interaction feature when terminal authentication is abnormal by the reorganized authentication information; Determine the authorized resources when terminal authentication is abnormal according to the first authentication interaction feature and the second authentication interaction feature.

[0052] In the specific implementation, first, the necessary parameters are extracted 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 access right, 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 the user role, session context, and permission scope; then, the reorganized authentication information contains security parameters for cross-domain access to the client. It is necessary to extract key data 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 these data and generate the second authentication interaction feature. This feature mainly reflects how the terminal performs security verification and resource access based on the reorganized authentication information under abnormal circumstances. This feature may include the status of the authentication node, the integrity of information transmission, and the context information of cross-domain access; finally, the first and second authentication interaction features are obtained, and the system will conduct a comprehensive analysis of these two features. By comparing and matching, the system can identify resources and permissions that require attention in the event 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's access to specific resources.

[0053] It should be noted that in the present application, the first authentication interaction feature is a feature generated based on the authority signature information, which describes the authority 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 under abnormal circumstances, and the authorized resources represent the accessible resources and permissions determined according to the authentication interaction features under abnormal terminal authentication circumstances.

[0054] In specific implementation, the permission request during terminal authentication based on the authorized resource can be implemented in the following manner, namely: first, the content of the permission request needs to be analyzed, 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 authorized resource status, determine the availability of relevant resources and the ongoing permission interaction process, and ensure whether the request needs to be released; next, the system will match the permission request with the previously determined authorized resource 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 authorized resource, the system will update the status to release the permission request and record the operation in the database. At the same time, the system will notify the relevant parties (such as terminal users or administrators) that the permission request has been successfully released. In addition, if any permissions are temporarily granted during the permission request, the system should clear these permissions in time after the request is released to maintain the consistency and security of permission management; finally, the system will record the detailed information of all release operations, including timestamps, operators, and request contents, to provide necessary evidence for subsequent audits. This process of releasing permission requests not only improves the security and management efficiency of the system, but also supports compliance requirements and ensures transparency and traceability of operations.

[0055] It can be seen that in this application, dynamic inspection can be performed when the permission allocation in the multi-role permission control logic is slow to respond; among them, real-time acquisition of session request data helps to identify abnormal behavior in a timely manner, enhances the monitoring ability of potential security threats, and ensures that the system can respond quickly and reduce potential risks; by generating effective message authentication requests, it is possible to clarify the authentication nodes in multi-party communications, thereby enhancing the transparency of the system's multi-role permission control, helping to improve the accuracy of authentication and reduce security risks caused by information islands; by distributing and integrating permission management information, the permission information of different roles is effectively integrated to provide a consistent The authorization basis helps to eliminate information islands and improve the system's dynamic adaptability to complex permission logic, thereby reducing slow responses when allocating permissions; by analyzing permission verification information and authentication nodes, risk authentication features are generated, which can dynamically evaluate the security of requests. The generation of this feature can achieve real-time evaluation of abnormal behavior, which helps 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 to effectively manage and release permission requests that are no longer needed. This process can optimize resource usage, improve communication efficiency, and ensure the security and effectiveness of the authorization process. In summary, the technical solution adopted in this application can perform dynamic checks when permission allocation in the multi-role permission control logic produces slow responses, so as to improve the effectiveness of authentication security protection in communications.

[0056] This application provides an authentication exception handling system, referring to Figure 2 As shown, this figure is a schematic diagram of an authentication exception processing system according to this embodiment of the present application, and the processing system includes: The data acquisition module 100 is used to acquire the session request data of the mobile platform message client when the terminal authentication is abnormal; An information processing module 200 is used to generate a message authentication request for the server when receiving a message according to the session request data, and determine an authentication node between multiple parties when the server receives a message through the message authentication request; The information fusion module 300 is used to determine the rights management information when the client sends a message, distribute and fuse the rights management information, obtain the distributed authentication parameters during joint authentication, and determine the rights signature information when the client performs cross-domain access according to the distributed authentication parameters; The feature calibration module 400 is used to determine the authority verification information when the client receives the message, generate the risk authentication feature when the node is separated when the client sends the request and receives the reply according to the authority verification information and the authentication node, and then determine the reorganization authentication information when the client performs cross-domain access according to the risk authentication feature; The permission execution module 500 is used to determine the authorization resource 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 authorization resource.

[0057] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0058] A person skilled in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, the storage medium including a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically-erasable programmable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0059] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

Claims

1. A method for handling authentication exceptions, characterized in that: The processing method comprises the following steps: Obtaining session request data sent by the mobile platform message client when terminal authentication is abnormal; Generate a message authentication request for the server when receiving a message according to the session request data, and determine the authentication node between multiple parties when the server receives the message through the message authentication request; Determine the rights management information when the client sends a message, distribute and merge the rights management information, obtain the distributed authentication parameters during joint authentication, and determine the rights signature information when the client performs cross-domain access according to the distributed authentication parameters; Determine the authority verification information when the client receives the message, generate the risk authentication feature when the node is separated when the client sends the request and receives the reply according to the authority verification information and the authentication node, and then determine the reorganized authentication information when the client performs cross-domain access according to the risk authentication feature; 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.

2. The method for handling authentication exceptions according to claim 1, characterized in that: Session request data refers to the identity, device, network path, and exception flag context information collected by the client when the user initiates a message or access request.

3. The method for handling authentication exceptions according to claim 1, characterized in that: Generating a message authentication request for the server when receiving a message according to the session request data specifically includes: Performing session verification on the session request data to obtain session identification information of the server when receiving the message; A message authentication request of the server when receiving a message is determined according to the session identification information.

4. The method for handling authentication exceptions according to claim 1, wherein: Determining the authentication node between multiple parties when the server receives the message through the message authentication request specifically includes: Determining collaborative verification information of the server when receiving the message according to the message authentication request; Determine the task thread queue between multiple communication parties when the server receives messages; The authentication node between multiple parties in the server's multi-party communication when receiving the message is determined according to the collaborative verification information and the task thread queue.

5. The method for handling authentication exceptions according to claim 1, characterized in that: Permission management information refers to the scope of permissions set by the system for users and their devices, which controls the operations that users can perform when sending messages.

6. The method for handling authentication exceptions according to claim 1, characterized in that: The rights management information is distributed and integrated to obtain the distributed authentication parameters for joint authentication, which specifically include: Determine the authority attribution information in the authority management according to the authority management information; Determine the encrypted signature of the distributed cache during joint authentication; The authority attribution information is mapped to the encrypted signature to obtain the distributed authentication parameters for joint authentication.

7. The method for handling authentication exceptions according to claim 1, characterized in that: Determining the permission signature information when the client performs cross-domain access according to the distributed authentication parameters specifically includes: Determine an active node queue during cross-domain access according to the distributed authentication parameters; Determine the identity parameters of the client when performing cross-domain access; The permission signature information when the client performs cross-domain access is determined according to the active node queue and the identity identification parameter.

8. The method for handling authentication exceptions according to claim 1, characterized in that: 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.

9. The method for handling authentication exceptions according to claim 1, characterized in that: The risk authentication features generated according to the authority verification information and the authentication node when the client sends a request and receives a reply in a node separation specifically include: Determine, according to the permission verification information, the permission indication information when the node is separated in the request sent by the client; Determine, according to the authentication node, authentication allocation information when the node is separated in the client receiving the reply; The risk authentication characteristics when the nodes in the client sending the request and receiving the reply are separated are determined by the authority indication information and the authentication allocation information.

10. An authentication exception handling system, used to execute an authentication exception handling method according to any one of claims 1 to 9, characterized in that: The processing system comprises: A data acquisition module, used to acquire session request data sent by the mobile platform message client when the terminal authentication is abnormal; An information processing module, used to generate a message authentication request for the server when receiving a message according to the session request data, and determine the authentication node between multiple parties in the server when receiving the message through the message authentication request; An information fusion module is used to determine the rights management information when the client sends a message, distribute and fuse the rights management information, obtain the distributed authentication parameters during joint authentication, and determine the rights signature information when the client performs cross-domain access according to the distributed authentication parameters; A feature calibration module is used to determine the authority verification information when the client receives a message, generate a risk authentication feature when the node is separated when the client sends a request and receives a 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; The permission execution module is used to determine the authorization resource 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 authorization resource.

Images