Equipment centralized authentication and authorization emergency processing method, equipment, medium and product

Abstract

The invention discloses an equipment centralized authentication and authorization emergency processing method, equipment, a medium and a product, and relates to the technical field of telecommunication. The method comprises the following steps: establishing a heartbeat detection mechanism between a main server and the equipment; monitoring the communication state between the main server and the equipment in real time by adopting the heartbeat detection mechanism; and when the communication state between the main server and the equipment is abnormal, starting an emergency mode, and starting a local authentication and authorization mechanism in the emergency mode until the communication state between the main server and the equipment returns to normal. The heartbeat detection technology and the local emergency authentication mechanism are introduced, so that the problem that the service continuity cannot be ensured when the system is abnormal in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of telecommunication technology, and in particular to a method, device, medium, and product for emergency response to centralized authentication and authorization of equipment. Background Art

[0002] Current network device management systems typically use centralized authentication and authorization mechanisms. When the primary server fails, maintenance personnel are unable to log in to the device for maintenance and management. Existing technologies lack effective emergency response mechanisms, making it impossible to ensure business continuity during system anomalies. Summary of the Invention

[0003] To solve the above-mentioned problems, the present application provides a device centralized authentication and authorization emergency handling method, device, medium and product.

[0004] To achieve the above objectives, this application provides the following solutions: In a first aspect, the present application provides a method for emergency response to centralized authentication and authorization of devices, including: Establish a heartbeat detection mechanism between the main server and the device; The heartbeat detection mechanism is used to monitor the communication status between the main server and the device in real time; When the communication status between the main server and the device is abnormal, start the emergency mode and enable the local authentication and authorization mechanism in the emergency mode until the communication status between the main server and the device returns to normal; Among them, a heartbeat detection mechanism is established between the main server and the device, including: The primary server sends the public key to the device, which verifies the certificate chain and stores the public key. Set the heartbeat interval and heartbeat timeout threshold between the primary server and the device, and obtain the maximum or minimum interval allowed by the device hardware; Establish an encrypted channel based on the secure transport layer protocol, set the device's identity, and bind the device to the main server based on the device's identity; The main server adds the device to the heartbeat management list; the parameters of the heartbeat management list include: device unique identifier, heartbeat interval, heartbeat timeout threshold, maximum and minimum allowed intervals, timestamp of response received, consecutive failure count and network quality score; Reading parameters from the heartbeat management list and establishing a heartbeat channel based on the parameters; The heartbeat interval in the heartbeat management list is updated in real time based on the network quality score to generate a heartbeat packet of a heartbeat detection mechanism.

[0005] Optionally, the heartbeat detection mechanism is used to monitor the communication status between the main server and the device in real time, including: The main server broadcasts heartbeat packets to all devices at regular intervals. The devices verify the heartbeat packets and return a response packet of the device status. The main server monitors the response packets of the devices and obtains the monitoring response results. The communication status between the main server and the device is obtained based on the monitoring response result.

[0006] Optionally, the process of the device verifying the signature of the heartbeat packet includes: Decrypting the signature of the heartbeat packet based on the public key using a hash algorithm to obtain a first hash value; Perform hash calculation on the original data in the heartbeat packet using the hash algorithm to obtain a second hash value; determining whether the first hash value is equal to the second hash value; When the first hash value is equal to the second hash value, the verification is successful; When the first hash value is not equal to the second hash value, verification fails; When verification fails, the heartbeat packet is discarded and a security event is recorded; the security event includes the received heartbeat packet information and the reason for the verification failure; When multiple consecutive verification failures occur, the device's security protection mechanism is triggered.

[0007] Optionally, the process of the primary server monitoring the response packet of the device includes: Determining whether a response packet from the device is received within the heartbeat timeout threshold; When no response packet from the device is received within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered and a failure count is incremented; Obtain equipment performance indicators and proactive alarms in real time to comprehensively judge fault information and update equipment activity status; When a response packet from the device is received within the heartbeat timeout threshold, no processing is performed.

[0008] Optionally, the process of determining whether the communication status between the main server and the device is abnormal includes: Determining whether a heartbeat times out based on a relationship between the failure count and a set value; When the heartbeat times out, check whether the primary server has broadcasted; When the main server broadcasts, it checks the local state of the device and determines whether there is any abnormality in the local state of the device; When the local state of the device is abnormal, the communication state between the main server and the device is abnormal; When the heartbeat does not time out, the local state of the device is normal, or the master server does not broadcast, the communication state between the master server and the device is normal.

[0009] Optionally, the processing process of the local authentication and authorization mechanism includes: The authentication service stops triggering the heartbeat detection mechanism and loading the local credentials; Obtain the credentials entered by the user and perform local authentication and authorization based on the credentials entered by the user and the local credentials.

[0010] In a second aspect, the present application provides a computer device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-mentioned device centralized authentication and authorization emergency processing method.

[0011] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-mentioned device centralized authentication and authorization emergency processing method.

[0012] In a fourth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned device centralized authentication and authorization emergency processing method.

[0013] According to the specific embodiments provided in this application, this application has the following technical effects: This application provides a device centralized authentication and authorization emergency handling method, device, medium and product. By introducing heartbeat detection technology and a local emergency authentication mechanism, it realizes the coordinated control of the status between the main server and the device, which can solve the problem that the traditional centralized authentication system cannot guarantee business continuity under abnormal circumstances. It automatically switches to emergency mode when a fault is detected, ensuring that maintenance personnel can still manage the device, and after the communication status between the main server and the device returns to normal, it can smoothly transition back to the centralized authentication mode, achieving high availability, security and data consistency. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A flowchart of a method for emergency response to centralized authentication and authorization of devices provided in one embodiment of the present application; Figure 2 System architecture diagram for implementing the device centralized authentication and authorization emergency response method provided for this application; Figure 3A schematic diagram of a system monitoring process provided by an embodiment of the present application; Figure 4 A schematic diagram of an abnormality determination process provided in one embodiment of the present application; Figure 5 A schematic diagram of the heartbeat monitoring process provided in one embodiment of the present application; Figure 6 A schematic diagram of an emergency switching process provided in an embodiment of the present application; Figure 7 A schematic diagram of a system recovery process provided in an embodiment of the present application; Figure 8 A schematic diagram of the structure of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

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

[0017] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0018] In an exemplary embodiment, Figure 2 Taking the system architecture shown in FIG. 1 as an example, the implementation process of a device centralized authentication and authorization emergency handling method provided by this application is described as follows: Figure 1 As shown, the method includes: Step 100: Establish a heartbeat detection mechanism between the main server and the device. In actual application, the heartbeat detection mechanism can adopt a two-way verification method. The goal of this step is to establish a safe and reliable heartbeat channel between the main server and the device. This is mainly done by establishing a safe and reliable heartbeat channel between the main server and the device, and then establishing a heartbeat mechanism for subsequent real-time monitoring system. Based on this, the implementation process of step 100 may include: Step 100-1, key exchange: The primary server sends the public key (RSA public key) to the device (KeyExchange::sendPublicKey()). The device verifies the certificate chain and stores the public key (CertificateVerifier::verify()).

[0019] Step 100-2: Set the heartbeat interval and heartbeat timeout threshold between the master server and the device, and obtain the maximum or minimum interval allowed by the device hardware. In practice, this step is accomplished through parameter negotiation between the master server and the device. The master server and the device negotiate the heartbeat interval (for example, 30 seconds) and heartbeat timeout threshold (for example, 90 seconds). The device returns the maximum / minimum interval supported by the hardware (negotiateConfig()).

[0020] Step 100-3: Establish an encrypted channel based on the Transport Layer Security (TLS) protocol, set the device's identity, and bind the device to the primary server based on the device's identity to complete mutual authentication. For example, establish an encrypted channel based on TLS 1.3 (TLSSession::create()). This step primarily implements channel encryption.

[0021] Step 100-4: The primary server adds the device to the heartbeat management list (HeartbeatManager::registerDevice()). Heartbeat management list parameters include: device unique identifier (MAC / IP combination), heartbeat interval (default 30 seconds, dynamically adjustable between 30 and 60 seconds), heartbeat timeout threshold (default 90 seconds, typically three times the heartbeat interval), maximum allowed interval (system-preset upper limit, such as 60 seconds), minimum allowed interval (system-preset lower limit, such as 15 seconds), response received timestamp, consecutive failure count (three consecutive failures trigger an alarm), and network quality score (used to dynamically adjust the heartbeat interval). This step primarily facilitates registration and startup.

[0022] Step 100-5: Read parameters from the heartbeat management list and establish a heartbeat channel based on the parameters. For example, during the heartbeat channel establishment phase, when a new heartbeat channel is established through a HeartbeatInitializer (a heartbeat initializer or heartbeat initializer), parameters are read from the heartbeat management list.

[0023] Step 100-6: Update the heartbeat interval in the heartbeat management list in real time based on the network quality score to generate a heartbeat packet for the heartbeat detection mechanism.

[0024] Based on the above description, during the exception detection phase, the time interval between the current time and the previous heartbeat can be compared to detect timeouts. The device initiates the heartbeat response thread (deviceSideListener()). Based on this, exception handling includes: ① If key exchange fails (check the error message: During the connection process, the client will return a specific error message. Common error messages include "Key exchange failed" or "No compatible key exchange method found"), triggering a fallback protocol (such as a pre-shared key). ② If the channel establishment times out, for example, after three retries, the device is marked as unreachable.

[0025] Step 101: Use the heartbeat detection mechanism to monitor the communication status between the main server and the device in real time. When the heartbeat mechanism is perfect, monitoring can obtain information such as heartbeat timeout, resource load, and active alarm comprehensive fault judgment. Based on this, the implementation goal of this step is to continuously monitor the system status and maintain the heartbeat. In actual application, the implementation process of step 101 may include: Step 101-1: The master server broadcasts a heartbeat packet (HeartbeatPacket structure) to all devices at a scheduled interval (30 seconds). The devices verify the heartbeat packet and return a response packet containing their status. The master server listens for the device's response packet and obtains the monitoring response result. The device listens for the heartbeat request via a UDP port. After receiving the packet, the device verifies the signature and collects status (CPU / memory usage, etc.).

[0026] Verification is based on the following data: ① The device decrypts the signature of the heartbeat packet using the primary server's public key, obtaining the signature's hash value (denoted as H1). ② The device hashes the original data in the heartbeat packet (excluding the signature itself) using the same hash algorithm (such as SHA-256) to obtain H2. ③ H1 and H2 are compared: If they are identical, verification succeeds. Otherwise, verification fails. Verification failure handling: 1) The heartbeat packet is discarded without subsequent processing (such as collecting status and returning a response).

[0027] 2) Record security events, including received data packet information, verification failure reasons, etc., for subsequent audit and analysis.

[0028] 3) Multiple consecutive verification failures may trigger the device's security protection mechanism (such as temporarily blocking the IP address of the main server to prevent possible attacks).

[0029] Based on the above description, the process of verifying the signature of the heartbeat packet includes: Step (1): using a hash algorithm to decrypt the signature of the heartbeat packet based on the public key to obtain a first hash value.

[0030] Step (2): Use a hash algorithm to perform hash calculation on the original data in the heartbeat packet to obtain a second hash value.

[0031] Step (3): Determine whether the first hash value is equal to the second hash value.

[0032] Step (4): When the first hash value is equal to the second hash value, the verification is successful. When the first hash value is not equal to the second hash value, the verification fails.

[0033] If verification fails, the heartbeat packet is discarded and a security event is recorded. The security event includes the received heartbeat packet information and the reason for the verification failure. If verification fails multiple times in a row, the device's security protection mechanism is triggered.

[0034] Furthermore, the master server monitors the device response: ① Received response (i.e., received response packet): obtained heartbeat timeout (the master server periodically sends a detection packet (i.e., heartbeat packet) to the device. If no response is received within the set threshold (such as continuous packet loss or ACK timeout), a heartbeat timeout alarm is triggered), resource load (real-time collection of device CPU, memory, network bandwidth and other performance indicators), active alarm comprehensive fault judgment (hardware errors, service crash logs, heartbeat port abnormalities and other faults actively reported by the receiving device), and other information, and updates the device active status (lastSeen field). ② No response received: increment the failure count (failureCount++). Based on this, the process of the master server monitoring the device's response packet includes: Step (1) determines whether a response packet from the device is received within the heartbeat timeout threshold.

[0035] Step (2): When no response packet is received from the device within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered and the failure count is incremented.

[0036] Step (3) obtains the performance indicators of the equipment in real time and proactively warns of fault information, and updates the active status of the equipment.

[0037] Step (4): When a response packet from the device is received within the heartbeat timeout threshold, no processing is performed.

[0038] Step 101-2: Based on the monitoring response result, the communication status between the main server and the device is obtained. Based on the above description, the above process is repeated after the new interval period as follows: Figure 3 shown.

[0039] Step 102: When the communication status between the main server and the device is abnormal, emergency mode is activated and the local authentication and authorization mechanism is enabled in emergency mode until the communication status between the main server and the device returns to normal, at which point the system returns to centralized authentication mode. Centralized authentication mode refers to an architecture in which authentication requests from all devices in a network system are uniformly managed and verified by the main server. In actual applications, a hierarchical switching strategy can be used to switch between emergency modes. The local authentication and authorization mechanism uses pre-set encrypted credentials.

[0040] In actual applications, after an exception is detected during the exception determination phase, an atomic state switch is performed to avoid intermediate state risks. The specific manifestations of atomic state switching are: ① hardware-level atomic operations (atomic state switching refers to completing system mode changes in a single, indivisible operation); ② state switching transactions (acquiring a mutex (std::lock_guard), verifying system health (such as whether the log cache is full), atomically updating mode flags, releasing resources, and notifying observers); ③ state machine integrity (illegal jumps are prohibited: it is impossible to jump directly from CENTRAL to intermediate states such as RECOVERY). Based on this, the purpose of the exception determination phase is to comprehensively determine whether emergency conditions are triggered. The determination conditions include: 1) Heartbeat timeout: No response is received for three consecutive times (failureCount>= 3).

[0041] 2) Main server broadcast: Receives the emergency command actively sent by the server (EmergencyBroadcast::isReceived()).

[0042] 3) Local exceptions: ① CPU usage is greater than 95% for 5 minutes. ② Insufficient memory warning (SystemHealthChecker::checkMemory()).

[0043] Based on the above description, if Figure 4 As shown, the process of determining whether the communication status between the main server and the device is abnormal includes: Step (1), determining whether the heartbeat times out based on the relationship between the failure count and the set value; Step (2): When the heartbeat times out, check whether the primary server has broadcasted; Step (3): When the main server broadcasts, the local state of the device is checked to determine whether there is any abnormality in the local state of the device; Step (4), when the local state of the device is abnormal, the communication state between the main server and the device is abnormal; Step (5): When the heartbeat does not time out, the local status of the device is normal, or the master server does not broadcast, the communication status between the master server and the device is normal.

[0044] Furthermore, step 102 corresponds to the emergency switching stage. When an abnormal situation is detected based on the above content, the emergency mode is entered to achieve the purpose of safely switching to the local emergency mode. Based on this, the specific switching process includes: Step 1: Stop the centralized service. At this point, close the primary authentication connection (CentralAuthService::shutdown()). The primary server shutdown triggers a heartbeat anomaly detection mechanism: The primary server typically manages the core authentication process. When shutdown() is called to forcibly close its connection, the primary server's service stops responding to heartbeat probe requests. The heartbeat channel, an independent link for inter-node status monitoring, immediately detects the primary server's unresponsiveness and triggers a failover.

[0045] Step 2: Load local credentials. The emergency account can be decrypted from the TPM (Trusted Platform Module) security chip (LocalAuth::loadCredentials()).

[0046] Step 3. Restrict permissions. Only predefined commands, such as reboot, log_view, config_backup, service_restart, ping, and show_system_status, are allowed for system restart, log viewing, configuration backup / restore, service control, network diagnosis, and system status viewing.

[0047] Step 4: Start log caching. All operations are recorded in the encrypted local log (OperationLogger::startCaching()).

[0048] Step 5: Notify the maintenance client. Send a system status change alert (Notifier::broadcast()).

[0049] As an optional implementation of the present application, after entering the emergency mode, the following safe maintenance operation is performed. The purpose of the emergency operation phase is to safely perform maintenance operations in the emergency mode.

[0050] 1. Certification: ① The maintenance personnel enters local credentials (EmergencyOperator::handleLogin()) for authentication.

[0051] ② Verify the password hash (BCrypt::validate()). If the authentication is successful, proceed to the next step.

[0052] 2. Command execution: ① Check the command whitelist (PermissionManager::isAllowed()). When predefined commands are allowed, the check results are shown in Table 1.

[0053] ②Record commands and results (OperationLogger::logCommand()).

[0054] Table 1 Inspection results

[0055] 3. Audit: Generate security event report (SecurityLogger::generateReport()).

[0056] Based on the above description, the local authentication and authorization mechanism process includes: Step 1) The authentication service stops triggering the heartbeat detection mechanism and loading the local credentials.

[0057] Step 2) Obtain the credential information entered by the user and perform local authentication and authorization based on the credential information entered by the user and the local credentials.

[0058] As an optional implementation of this application, after the emergency operation, while the security incident report is generated by the safe execution of maintenance operations, the system recovery phase is carried out to achieve the goal of smoothly restoring to the centralized authentication mode. Based on this, the recovery process of the centralized authentication mode is as follows: (1) After receiving the device online notification, the main server verifies the device identity (verification of device certificate + MAC address binding).

[0059] (2) The primary server sends a digitally signed recovery command (RecoveryCommand structure) to the device.

[0060] (3) The device verifies the recovery command signature (verifyCommand()).

[0061] (4) Upload cache logs on the device side (breakpoint resume + compressed transmission).

[0062] (5) The master server receives and merges the device logs (conflict detection uses a timestamp priority strategy).

[0063] (6) The device side switches back to centralized authentication mode (AuthModeSwitcher::switchToCentral()).

[0064] (7) Clean up the local emergency status on the device side (delete temporary credentials).

[0065] Based on the above description, the device centralized authentication and authorization emergency handling method provided by this application continuously executes step 101 to perform heartbeat monitoring, and if there is another abnormality, it loops to execute step 102. Figure 2 The system architecture shown in this application provides a centralized authentication and authorization emergency response method for devices. The heartbeat monitoring process is as follows: Figure 5 As shown in the figure, the emergency switching process is as follows Figure 6 As shown in the following figure, the system recovery process is as follows Figure 7 shown.

[0066] As an optional implementation of the present application, a persistent connection solution is provided, which uses real-time monitoring based on persistent connections to replace the heartbeat mechanism. The following steps are performed: ①Use WebSocket or gRPC long connection instead of UDP heartbeat packet.

[0067] ②Achieve continuous state synchronization through bidirectional flow.

[0068] The comparison results between the long connection scheme in this embodiment and the method provided in this application are shown in Table 2.

[0069] Table 2 Comparison results

[0070] Based on the comparison results shown in Table 2, it can be concluded that the advantages of this application are: it can be combined with TPM hardware binding; and it supports dynamic load adjustment (by adjusting the data push frequency).

[0071] In summary, the core of the method provided by this application is to achieve collaborative control of the status between the main server and the device through a multi-stage handshake protocol, aiming to solve the problem that the traditional centralized authentication system cannot guarantee business continuity under abnormal circumstances. In addition, this application uses a multi-stage collaborative control mechanism to automatically switch to emergency mode when a fault is detected, ensuring that maintenance personnel can still manage the equipment, and smoothly transition back to the centralized authentication mode after the system is restored, achieving high availability, security and data consistency. Compared with the existing technology, this application not only defines the functions of each module, but also ensures the reliability of the entire process of fault detection, switching, and recovery through a complete request-response-confirmation (RRC) interaction chain.

[0072] Furthermore, when a single point of failure occurs in existing centralized authentication systems known to the inventors (such as RADIUS / TACACS+ servers), operations and maintenance personnel are unable to log in to the device, resulting in business interruption. Furthermore, traditional backup authentication solutions (such as local accounts) suffer from chaotic authority management and high security risks. They lack real-time monitoring and automatic switching mechanisms, rely on manual intervention, and have slow response speeds. The centralized authentication and authorization emergency response method for equipment provided in this application can achieve rapid detection and response to system anomalies, ensuring that maintenance personnel can still manage equipment in the event of system anomalies, providing a smooth system recovery mechanism, and ensuring business continuity. Furthermore, the maintenance operation availability of this application can be increased from 80% to 99.99%.

[0073] Based on the same inventive concept, the embodiments of the present application also provide a device for implementing the device centralized authentication and authorization emergency processing method involved above. The implementation solution provided by the device is similar to the implementation solution described in the above method. Therefore, the specific limitations in the embodiments of one or more device centralized authentication and authorization emergency processing devices provided below can be found in the above limitations on the device centralized authentication and authorization emergency processing method, and will not be repeated here.

[0074] In this embodiment, a device centralized authentication and authorization emergency processing apparatus is provided, comprising: a heartbeat monitoring module, a state determination module, and an emergency switching module.

[0075] The heartbeat monitoring module is used to establish a heartbeat detection mechanism between the main server and the device.

[0076] The status determination module is used to monitor the communication status between the main server and the device in real time using the heartbeat detection mechanism.

[0077] The emergency switching module is used to start the emergency mode when the communication status between the main server and the device is abnormal, and enable the local authentication and authorization mechanism in the emergency mode until the communication status between the main server and the device returns to normal and returns to the centralized authentication mode.

[0078] In an exemplary embodiment, a computer device is provided. The computer device may be a server or a terminal. The internal structure diagram thereof may be as follows: Figure 8As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store device centralized authentication and authorization emergency processing data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a device centralized authentication and authorization emergency processing method is implemented.

[0079] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0080] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0081] In an exemplary embodiment, a computer-readable storage medium is provided, storing a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0082] In an exemplary embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0083] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0084] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (RRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0085] The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may include, but are not limited to, general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic units, data processing logic units based on quantum computing, and the like.

[0086] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0087] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. At the same time, for those skilled in the art, based on the concept of this application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A device centralized authentication and authorization emergency handling method, characterized in that: include: Establish a heartbeat detection mechanism between the main server and the device; The heartbeat detection mechanism is used to monitor the communication status between the main server and the device in real time; When the communication status between the main server and the device is abnormal, start the emergency mode and enable the local authentication and authorization mechanism in the emergency mode until the communication status between the main server and the device returns to normal; Among them, a heartbeat detection mechanism is established between the main server and the device, including: The primary server sends the public key to the device, which verifies the certificate chain and stores the public key. Set the heartbeat interval and heartbeat timeout threshold between the primary server and the device, and obtain the maximum or minimum interval allowed by the device hardware; Establish an encrypted channel based on the secure transport layer protocol, set the device's identity, and bind the device to the main server based on the device's identity; The main server adds the device to the heartbeat management list; the parameters of the heartbeat management list include: device unique identifier, heartbeat interval, heartbeat timeout threshold, maximum and minimum allowed intervals, timestamp of response received, consecutive failure count and network quality score; Reading parameters from the heartbeat management list and establishing a heartbeat channel based on the parameters; The heartbeat interval in the heartbeat management list is updated in real time based on the network quality score to generate a heartbeat packet of a heartbeat detection mechanism.

2. The device centralized authentication and authorization emergency handling method according to claim 1, characterized in that: The heartbeat detection mechanism is used to monitor the communication status between the main server and the device in real time, including: The main server broadcasts heartbeat packets to all devices at regular intervals. The devices verify the heartbeat packets and return a response packet of the device status. The main server monitors the response packets of the devices and obtains the monitoring response results. The communication status between the main server and the device is obtained based on the monitoring response result.

3. The device centralized authentication and authorization emergency handling method according to claim 2, characterized in that: The process of the device verifying the signature of the heartbeat packet includes: Decrypting the signature of the heartbeat packet based on the public key using a hash algorithm to obtain a first hash value; Perform hash calculation on the original data in the heartbeat packet using the hash algorithm to obtain a second hash value; determining whether the first hash value is equal to the second hash value; When the first hash value is equal to the second hash value, the verification is successful; When the first hash value is not equal to the second hash value, verification fails; When verification fails, the heartbeat packet is discarded and a security event is recorded; the security event includes the received heartbeat packet information and the reason for the verification failure; When multiple consecutive verification failures occur, the device's security protection mechanism is triggered.

4. The device centralized authentication and authorization emergency handling method according to claim 2, characterized in that: The process of the main server monitoring the response packet of the device includes: Determining whether a response packet from the device is received within the heartbeat timeout threshold; When no response packet from the device is received within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered and a failure count is incremented; Obtain equipment performance indicators and proactive alarms in real time to comprehensively judge fault information and update equipment activity status; When a response packet from the device is received within the heartbeat timeout threshold, no processing is performed.

5. The device centralized authentication and authorization emergency handling method according to claim 4, characterized in that: The process of determining whether the communication status between the main server and the device is abnormal includes: Determining whether a heartbeat times out based on a relationship between the failure count and a set value; When the heartbeat times out, check whether the primary server has broadcasted; When the main server broadcasts, it checks the local state of the device and determines whether there is any abnormality in the local state of the device; When the local state of the device is abnormal, the communication state between the main server and the device is abnormal; When the heartbeat does not time out, the local state of the device is normal, or the master server does not broadcast, the communication state between the master server and the device is normal.

6. The device centralized authentication and authorization emergency handling method according to claim 1, characterized in that: The processing process of the local authentication and authorization mechanism includes: The authentication service stops triggering the heartbeat detection mechanism and loading the local credentials; Obtain the credentials entered by the user and perform local authentication and authorization based on the credentials entered by the user and the local credentials.

7. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the device centralized authentication and authorization emergency processing method according to any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the device centralized authentication and authorization emergency processing method according to any one of claims 1 to 6 is implemented.

9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the device centralized authentication and authorization emergency processing method according to any one of claims 1 to 6 is implemented.

Images