Method for managing authorizations

Abstract

The application provides an authorization management method, and relates to the technical field of computers. An authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier. The authorization center receives an authorization request sent by a target client, and the authorization request includes a target authorization identifier determined by the target client based on received target authorization identifier information. The target authorization identifier is verified according to the saved authorization identifier. When the verification is passed, the authorization center sends authorization response information including a target authorization file corresponding to the target authorization identifier to the target client. Otherwise, the target authorization file is not sent to the target client. In this way, the authorization management does not need to be strongly bound to hardware, but the authorization center sends the authorization file to the client according to the target authorization identifier sent by the client, which is not strongly bound to the hardware, so that even if the device where the client is located is repaired or the hardware is updated, the client does not need to apply for authorization again.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to an authorization management method. BACKGROUND

[0002] The traditional authorization management scheme is basically bound with hardware devices, the identification codes of hardware modules such as hard disk, memory, CPU and network card on the hardware devices are collected and obtained, a hardware code with unique identification ability is calculated through a specific algorithm, and then an encrypted file recording the authorization control range which can only be opened by the hardware code is generated as an authorization file to realize the uniqueness of authorization. However, this traditional authorization management method is strongly bound with hardware, and when the user repairs the device or updates the hardware module, the original authorization will fail, and the authorization application needs to be re-applied. SUMMARY

[0003] The embodiments of the present application provide an authorization management method, device, electronic equipment and readable storage medium, which do not strongly bind the authorization management with hardware, but send an authorization file to a client according to a target authorization identifier determined by the client based on received target authorization identifier information, so that even if the device where the client is located is repaired or the hardware module is updated, the authorization application does not need to be re-applied.

[0004] The embodiments of the present application can be implemented as follows:

[0005] In a first aspect, the embodiments of the present application provide an authorization management method applied to an authorization center, wherein the authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the method comprises the following steps:

[0006] receiving an authorization request sent by a target client, wherein the authorization request includes a target authorization identifier determined by the target client based on received target authorization identifier information;

[0007] checking the target authorization identifier according to the saved authorization identifier;

[0008] in a case where the target authorization identifier passes the check, sending an authorization response information to the target client, wherein the authorization response information includes a target authorization file corresponding to the target authorization identifier;

[0009] in a case where the target authorization identifier does not pass the check, not sending the target authorization file to the target client.

[0010] In a second aspect, the embodiments of the present application provide an authorization management method applied to a client device, wherein the client device includes a client, and the method comprises the following steps:

[0011] sending an authorization request to the authorization center, wherein the authorization request includes a target authorization identifier determined based on the received target authorization identifier information;

[0012] receiving authorization response information sent by the authorization center in a case where the target authorization identifier passes verification, wherein the authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the authorization response information includes a target authorization file corresponding to the target authorization identifier.

[0013] In a third aspect, an authorization management method is provided, which is applied to an authorization system including an authorization center and a client device in communication connection with the authorization center. The authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier. The client device includes a client. The method includes the following steps.

[0014] sending an authorization request to the authorization center, wherein the authorization request includes a target authorization identifier determined based on the received target authorization identifier information;

[0015] verifying the target authorization identifier according to the saved authorization identifier;

[0016] in a case where the target authorization identifier passes verification, sending authorization response information to the client, wherein the authorization response information includes a target authorization file corresponding to the target authorization identifier;

[0017] in a case where the target authorization identifier does not pass verification, not sending the target authorization file to the client.

[0018] In a fourth aspect, an authorization management device is provided, which is applied to an authorization center. The authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier. The device includes the following modules.

[0019] a request receiving module configured to receive an authorization request sent by a target client, wherein the authorization request includes a target authorization identifier determined by the target client based on received target authorization identifier information;

[0020] an identifier verifying module configured to verify the target authorization identifier according to the saved authorization identifier;

[0021] a first processing module configured to, in a case where the target authorization identifier passes verification, send authorization response information to the target client, wherein the authorization response information includes a target authorization file corresponding to the target authorization identifier;

[0022] The first processing module is further configured to, in a case where the target authorization identifier fails to pass the verification, not send the target authorization file to the target client.

[0023] In a fifth aspect, an authorization management apparatus is provided, which is applied to a client device, and the client device comprises a client. The apparatus comprises:

[0024] The request sending module is configured to send an authorization request to an authorization center, wherein the authorization request comprises a target authorization identifier determined based on the received target authorization identifier information.

[0025] The file receiving module is configured to receive authorization response information sent by the authorization center in a case where the target authorization identifier passes the verification, wherein the authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the authorization response information comprises a target authorization file corresponding to the target authorization identifier.

[0026] In a sixth aspect, an electronic device is provided, which comprises a processor and a memory. The memory stores machine executable instructions capable of being executed by the processor. The processor can execute the machine executable instructions to implement the authorization management method in the foregoing embodiments.

[0027] In a seventh aspect, a readable storage medium is provided, which stores a computer program. The computer program is executed by a processor to implement the authorization management method in the foregoing embodiments.

[0028] The authorization management method, the authorization management apparatus, the electronic device and the readable storage medium provided in the embodiments of the present application have the following advantages. The target client determines a target authorization identifier based on received target authorization identifier information, and then sends the target authorization identifier to the authorization center in an authorization request. The authorization center verifies the target authorization identifier according to the saved authorization identifier. In a case where the target authorization identifier passes the verification, the authorization center sends a target authorization file corresponding to the target authorization identifier to the target client in authorization response information according to the stored at least one authorization identifier and the authorization file corresponding to the authorization identifier. In a case where the target authorization identifier fails to pass the verification, the authorization center does not send the target authorization file to the target client. The embodiments of the present application do not strongly bind the authorization management to hardware, but send the authorization file to the client according to the target authorization identifier sent by the client, which is not strongly bound to the hardware, to grant the client corresponding permissions, so that even if the device where the client is located is repaired or the hardware is updated, the client does not need to reapply for authorization. BRIEF DESCRIPTION OF DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some of the embodiments of the present application, and therefore should not be regarded as a limitation to the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor.

[0030] Figure 1 The block schematic diagram of the authorization system provided by the embodiments of the present application;

[0031] Figure 2 The function item schematic diagram of the authorization center provided by the embodiments of the present application;

[0032] Figure 3 The function item schematic diagram of the client provided by the embodiments of the present application;

[0033] Figure 4 The block schematic diagram of the electronic device provided by the embodiments of the present application;

[0034] Figure 5 The flow schematic diagram of the authorization management method provided by the embodiments of the present application;

[0035] Figure 6 The schematic diagram of the environment where the authorization center and the software system are located provided by the embodiments of the present application;

[0036] Figure 7 The schematic diagram of the environment where the authorization center and the software system are located provided by the embodiments of the present application;

[0037] Figure 8 The flow schematic diagram of the authorization management method provided by the embodiments of the present application;

[0038] Figure 9 The timing diagram of the random code and the heartbeat of the authorization center provided by the embodiments of the present application;

[0039] Figure 10 The flow schematic diagram of the authorization management method provided by the embodiments of the present application;

[0040] Figure 11 The flow schematic diagram of the step S170 included in the method provided by the embodiments of the present application; Figure 10

[0041] The flow schematic diagram of the step S170 included in the method provided by the embodiments of the present application; Figure 12 Figure 10

[0042] Figure 13 The flow schematic diagram of the authorization management method provided by the embodiments of the present application;

[0043] ​​Figure 14 Flowchart of the authorization management method provided by the embodiment of the present application No. 5;

[0044] Figure 15 Flowchart of the authorization management method provided by the embodiment of the present application No. 6;

[0045] Figure 16 Flowchart of the authorization management method provided by the embodiment of the present application No. 7;

[0046] Figure 17 Block diagram of the authorization management device provided by the embodiment of the present application;

[0047] Figure 18 Block diagram of another authorization management device provided by the embodiment of the present application No. 1;

[0048] Figure 19 Block diagram of another authorization management device provided by the embodiment of the present application No. 2.

[0049] Icon: 10-authorization system; 100-authorization center; 200-client device; 300-electronic device; 310-memory; 320-processor; 330-communication unit; 500(600)-authorization management device; 510-request receiving module; 520-identity verification module; 530-first processing module; 610-request sending module; 620-file receiving module; 630-second processing module. DETAILED DESCRIPTION

[0050] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. The components of the embodiments of the present application described and shown in the accompanying drawings can be arranged and designed in various different configurations.

[0051] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0052] It is to be noted that the relational terms herein, such as first and second, and the like, are used solely to distinguish one from another entity or action without necessarily requiring or implying any actual relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0053] The following first explains the terms involved in the present application.

[0054] Cloud system: a software system deployed based on cloud services.

[0055] Public cloud system: an application system deployed in an Internet public cloud service.

[0056] Private cloud system: an application system deployed in an isolated network private cloud service.

[0057] Isolated network: a network environment physically isolated from the Internet.

[0058] Authorization: a restriction on a sold hardware device or software system, including available resources, performance, functional permissions, usage time, and the like.

[0059] Authorization file: a file recording the authorization control range.

[0060] Authorization management: a software program that controls the authorization items of a hardware device or software system through authorization file information.

[0061] Authorization center: a platform that can generate authorization files and authorization IDs and can uniformly manage authorization.

[0062] Authorization identifier: a unique identifier that can be used to identify authorization files and authorization information.

[0063] Currently, when a software system is deployed on a hardware device, the software system obtains the identification codes of the hardware modules such as hard disk, memory, CPU, network card and the like on the hardware device, calculates a hardware code with unique identification ability through a specific algorithm. Then, the hardware code is used to the corresponding authorization platform to generate an authorization file that can only be decrypted by the hardware code. After the authorization file is imported into the software system, it is managed and used by the corresponding authorization management module in the software system to control the use permission of the software system. This traditional authorization management method is strongly bound with hardware. When the user repairs the device or updates the hardware module, the original authorization will be invalid, and a new authorization application needs to be made.

[0064] To solve the above problems, the embodiments of the present application provide an authorization management method, device, electronic equipment and readable storage medium, which do not strongly bind the authorization management with the hardware, but send the authorization file to the client according to the target authorization identification determined by the client based on the received target authorization identification information. In this way, even if the device where the client is located is repaired or the hardware module is updated, there is no need to reapply for authorization.

[0065] Some embodiments of the present application will be described in detail below with reference to the accompanying drawings. In the case of no conflict, the embodiments described below and the features in the embodiments can be combined with each other.

[0066] Please refer to Figure 1 , Figure 1 The block diagram of the authorization system 10 provided by the embodiments of the present application is shown. The authorization system 10 can include an authorization center 100 and at least one client device 200 in communication connection with the authorization center 100. The authorization center 100 can store at least one authorization identification and the authorization file corresponding to the authorization identification. The software system in the client device 200 can be a public cloud system or a private cloud system, or not a cloud system, which can be set according to actual needs. The software system in the client device 200 includes a client, which is an authorization management component in the client device 200, and the client can also be called an authorization management client.

[0067] In the embodiment, the client can send an authorization request to the authorization center 100. The authorization request includes a target authorization identifier determined by the client based on the received target authorization identifier information. The authorization center checks the target authorization identifier according to the saved authorization identifier. When the target authorization identifier passes the check, the authorization center sends a target authorization file corresponding to the target authorization identifier to the client in an authorization response information. When the target authorization identifier fails the check, the authorization center does not send the target authorization file to the client. In this way, the authorization management is separated from the hardware, so that even if the device where the client is located is repaired or the hardware module is updated, it is not necessary to reapply for authorization.

[0068] The authorization center 100 is a service end of authorization control. The authorization center can be deployed on a physical server or other devices as long as it can realize authorization control of the client device 200. The client device 200 can be a computer or other device that needs system authorization management. The authorization center 100 and the client device 200 can be located in an Internet environment or an isolated network environment, which can be determined according to actual conditions.

[0069] Optionally, as shown in Figure 2 The authorization file in the authorization center can be generated by a third-party device, imported into the authorization center, and then the authorization center can perform heartbeat check, function control and the like on the client based on the imported authorization file, and also supports parsing, storage and updating of the authorization file. The authorization identifier of the authorization center can be generated by the authorization center or other devices. The authorization identifier stored in the authorization center is subjected to deduplication check to ensure that the authorization identifier is not repeated.

[0070] The authorization center can also respond to the client heartbeat, parse the heartbeat information of the client and store it in the database, and obtain the resource usage of the client device, so as to complete heartbeat management. The authorization center can periodically calculate authorization availability, and then determine whether to change the authorization state, so as to complete authorization check. The authorization center can include a blacklist and a whitelist, and the source IP of access and heartbeat response can be limited according to the blacklist and the whitelist. It should be noted that the above function items of the authorization center are only for illustration, and the function items of the authorization center are not limited herein.

[0071] Optionally, as shown in Figure 3As shown, the client can be used to upload an authorization identifier and connect to the authorization center for verification to obtain an authorization file including authorization information, thereby performing function control on the software system. The client can also perform heartbeat management, maintain a heartbeat with the authorization center in the process, and regard the authorization possessed by the client as invalid authorization when the heartbeat is abnormal. The client can also provide an authorization verification interface, which is used to verify whether the function can be normally used when the software system uses a function related to authorization, that is, control the use of the function of the software system based on the permission granted to the client, thereby realizing Figure 3 authorization verification. The client can also perform permission restriction, periodically check the authorization availability of the software system, and disable the related function module when the authorization is invalid. It should be noted that the above function items of the client are only for illustration, and the function items of the client are not specifically limited herein.

[0072] Please refer to Figure 4 , Figure 4 The block schematic diagram of an electronic device 300 provided by the embodiments of the present application is shown. The electronic device 300 can implement the authorization center 100 and the client device 200 described above. The electronic device 300 can include a memory 310, a processor 320, and a communication unit 330. The memory 310, the processor 320, and the communication unit 330 are directly or indirectly electrically connected to each other to realize the transmission or interaction of data. For example, these elements can be electrically connected to each other through one or more communication buses or signal lines.

[0073] The memory 310 is used to store programs or data. The memory 310 can be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), and the like.

[0074] The processor 320 is configured to read / write data or programs stored in the memory 310, and perform corresponding functions. For example, the memory 310 stores an authorization management apparatus, which includes at least one software function module stored in the memory 310 in the form of software or firmware. The processor 320 performs various function applications and data processing by running the software programs and modules stored in the memory 310, i.e., implements the authorization management method in the embodiments of the present application.

[0075] The communication unit 330 is configured to establish a communication connection between the electronic device 300 and other communication terminals through a network, and configured to receive / transmit data through the network.

[0076] It should be understood that, Figure 4 The structure shown is only a structural schematic diagram of the electronic device 300, and the electronic device 300 can further include more or less components than those shown in the drawings, or have a different configuration from that shown in the drawings. Figure 4 The components shown in the drawings can be implemented in hardware, software, or a combination thereof. Figure 4 Figure 4 The components shown in the drawings can be implemented in hardware, software, or a combination thereof.

[0077] Please refer to Figure 5 , Figure 5 One of the flowcharts of the authorization management method provided by the embodiments of the present application. The method is applied to an authorization center. The specific flow of the authorization management method is described in detail below. In the present embodiment, the authorization management method can include steps S110-S140.

[0078] Step S110, receiving an authorization request sent by a target client.

[0079] In the present embodiment, the target client is a client for which the authorization management of the authorization center is performed. For example, there are clients A, B, and C, and when the authorization management of the authorization center for the clients A, B, and C is described respectively, the clients A, B, and C can be taken as the target clients in the corresponding descriptions, for example, when the authorization management of the authorization center for the client A is described, the client A can be taken as the target client.

[0080] The target client can obtain target authorization identification information according to the input operation of the user or the information sent by other devices, so as to determine the target authorization identification. That is, the target authorization identification information is used to determine the target authorization identification. The target authorization identification is the authorization identification required by the client to obtain corresponding authorization from the authorization center.

[0081] ​For example, the user can input a target authorization identifier into the client device, so that the client in the client device obtains the target authorization identifier, and the information received by the client device describing the input operation of the target authorization identifier is the target authorization identifier information. Alternatively, at least one authorization identifier to be selected can be displayed in the client device, and the user inputs an authorization identifier selection operation into the client device, and the client determines the selected authorization identifier according to the selection operation, and takes the selected authorization identifier as the target authorization identifier, and the information describing the authorization identifier selection operation of the user is the target authorization identifier information.

[0082] After determining the target authorization identifier, the client can send the target authorization identifier in an authorization request to the authorization center, so that the authorization center grants the client corresponding permissions based on the target authorization identifier.

[0083] In step S120, the target authorization identifier is verified according to the saved authorization identifier.

[0084] The authorization center stores at least one authorization identifier and an authorization file corresponding to each saved authorization identifier. The authorization identifier and the authorization file stored in the authorization center can be generated by itself or by another device, which is not limited here.

[0085] Upon receiving the target authorization identifier sent by the target client, the authorization center can compare the target authorization identifier with the authorization identifier saved by itself. If the target authorization identifier is the same as one of the saved authorization identifiers, it is determined that the target authorization identifier passes the verification. If the target authorization identifier is different from all the saved authorization identifiers, it is determined that the target authorization identifier fails the verification.

[0086] In step S130, if the target authorization identifier passes the verification, an authorization response information is sent to the target client.

[0087] If the target authorization identifier passes the authorization identifier verification, it is determined that the target authorization identifier corresponds to an authorization. In this case, the authorization center searches the saved authorization identifier-authorization file group to find the authorization file corresponding to the target authorization identifier, and takes the authorization file corresponding to the target authorization identifier as a target authorization file. Then, an authorization response information is sent to the target client, and the target authorization file is included in the authorization response information. The target authorization file is a file recording the authorization control range, and the client can perform function control on the software system according to the authorization information described in the target authorization file after receiving the authorization response information. The authorization response information can also include an authorization state, and the authorization state at this time is valid.

[0088] In a case where the target authorization identifier fails to pass the verification, the target authorization file is not sent to the target client.

[0089] In a case where the target authorization identifier fails to pass the verification, the target authorization file is not sent to the target client.

[0090] In the embodiment, the authorization management is strongly bound with hardware, and the authorization file is sent to the client according to the target authorization identifier determined based on the received target authorization identifier information sent by the client. In this way, even if the device where the client is located is repaired or the hardware module is updated, it is not necessary to reapply for authorization.

[0091] In the embodiment, the authorization center can be in two forms according to the network environment. If the authorization center is located in an environment that can access the Internet, that is, an Internet authorization center, the deployment form of the authorization service end corresponding to the authorization center is not fixed, and the control right of the device where the authorization center is located is obtained, so that the authorization center can communicate with the client device to complete the authorization control of the client device. If the authorization center is located in an environment that cannot access the Internet, that is, an isolated network authorization center, the authorization service end corresponding to the authorization center can be deployed on a physical server. When the authorization center is located in an Internet environment, in order to ensure the high availability of the authorization center, a combination of Nginx+Keepalived+CDN service can be used.

[0092] In the embodiment, the client is a service component deployed in the software system to be controlled. The software system is located in the client device. Correspondingly, the client device can also be located in an environment that can access the Internet or an environment that cannot access the Internet.

[0093] The authorization center and the client can communicate based on the RESTful API of https. Alternatively, a fixed domain name or a fixed IP address can be built in the client. After the software is deployed, the client can communicate with the authorization center according to the built-in fixed domain name or fixed IP address. That is, the fixed domain name built in the client is the domain name of the authorization center, and the fixed IP address built in the client is the IP address of the authorization center.

[0094] Wherein, the IP address can change, while the domain name is generally less changed. If the fixed IP address is built-in in the client, when the IP address of the authorization center changes, the fixed IP address built-in in the client needs to be changed. In order to reduce the case of updating the fixed IP address in the client, the fixed domain name can be built-in in the client, so that even if the IP address of the authorization center changes, the fixed IP address built-in in the client does not need to be changed.

[0095] In the embodiment, when deploying the client, the software system can be deployed first, and then it is judged whether the client device where the software system is located can access the Internet. If the Internet cannot be accessed, the hosts can be configured to ensure that the authorization management center can be accessed.

[0096] The following will be combined Figure 6 and Figure 7 to briefly describe how the authorization center located in different environments obtains the authorization identifier-authorization file group and how to perform authorization verification.

[0097] As a possible implementation manner, as shown in Figure 6 , when the authorization center is an Internet authorization center, in this manner, the service end corresponding to the authorization center can be deployed in any device in the Internet environment, and the network is configured to ensure that the software system network is reachable. First, the Internet authorization center can generate a random code according to certain rules, and compare the generated random code with the historical generated authorization identifier to perform deduplication processing. Then, the newly generated random code after deduplication processing is used as a newly generated authorization identifier. Wherein, one random code can be used as one authorization identifier.

[0098] After generating the authorization identifier, the Internet authorization center can generate an encrypted file for one authorization identifier and corresponding authorization information (and authorization information bound with the authorization identifier), as the authorization file corresponding to the authorization identifier. Wherein, the authorization file can only be opened by the corresponding authorization identifier. That is, when the authorization center is an Internet authorization center, the authorization center generates an authorization identifier-authorization file group.

[0099] The Internet authorization center can provide the authorization identifier to a customer or an implementation and deployment personnel, which inputs the authorization identifier into the client. The client can connect to the Internet authorization center through a built-in domain name, and send the authorization identifier to the Internet authorization center. The Internet authorization center can perform authorization identifier verification on the received authorization identifier, and send the corresponding authorization file to the client if the verification is passed. The client can decrypt the received authorization file, obtain the authorization information in the authorization file, and save the authorization information in the database of the current time. Alternatively, the Internet authorization center can also communicate with the client to perform other authorization verifications.

[0100] The authorization file can also include a corresponding authorization identifier. If the received authorization identifier ID is verified, the Internet authorization center can find the target authorization file according to the correspondence between the stored authorization identifier and the authorization file, then extract the authorization identifier from the target authorization file, and compare the extracted authorization identifier with the received authorization identifier. If they are consistent, the target authorization file is sent to the client. In this way, it can be ensured that the authorization file sent is accurate.

[0101] As another possible implementation, as shown in Figure 7 The authorization center is an isolated network authorization center. In the mode, the service end corresponding to the authorization center can be deployed in a hardware device, and a network is configured to ensure that the software system network is reachable.

[0102] The isolated network authorization center or the Internet authorization center can generate a non-repetitive random code as an authorization identifier. Then, the authorization identifier is uploaded to the Internet authorization center, which can generate an encrypted file as the corresponding authorization file in combination with the corresponding authorization information for each authorization identifier. In this way, the Internet authorization center obtains an authorization identifier-authorization file group. In this embodiment, by generating the authorization file by the Internet authorization center, the situation that the authorization is insecure due to being easily attacked when the authorization file is generated by the isolated network authorization center can be avoided.

[0103] Then, the authorization identifier can be provided to a customer or an implementation and deployment personnel, which inputs the authorization identifier into the client. The relevant information can also be imported into the isolated network authorization center by the corresponding personnel. For example, the authorization identifier-authorization file group generated by the Internet authorization center can be directly uploaded to the isolated network authorization center; or only the generated authorization file is uploaded to the isolated network authorization center, the authorization file includes the corresponding authorization identifier, and the isolated network authorization center can parse the uploaded authorization files to obtain the authorization identifier corresponding to each authorization file, so as to facilitate subsequent authorization verification.

[0104] After obtaining the authorization identifier, the client can determine the IP address of the isolated network authorization center according to the configured fixed domain name and hosts, and then send the authorization identifier to the isolated network authorization center. The isolated network authorization center performs authorization identifier verification on the authorization identifier to determine whether to send the corresponding target authorization file to the client. Subsequently, the isolated network authorization center can also perform other authorization management on the client. How the isolated network authorization center determines the target authorization file can be referred to the description of how the Internet authorization center determines the target authorization file above, and will not be described here.

[0105] Before the target client obtains the target authorization identifier, when the user logs in to the software system, no other function can be used except the authorization import interface. After the target client obtains the target authorization identifier, the target client can connect the authorization center for activation. If the target authorization identifier passes the authorization identifier verification of the authorization center, the authorization starts to take effect, and the software system can be normally used. If the authorization corresponding to the target authorization identifier is invalid, the corresponding function is disabled, and the user can only view but cannot operate, that is, cannot edit; when the authorization changes from invalid to valid, the system can be normally used.

[0106] In the case where the target authorization identifier passes the authorization identifier verification of the authorization center, the target client can parse the received target authorization file according to the target authorization identifier, obtain target authorization information, and save the target authorization information to the software system database. When the authorization takes effect, all operations related to authorization restrictions need to pass the authorization information verification before being normally executed.

[0107] Optionally, in the present embodiment, the authorization center can also obtain the IP address of the target client when receiving the authorization request. The authorization center can compare the IP address of the target client with the IP addresses in the stored blacklist. If the IP address of the target client is not in the blacklist and the target authorization identifier passes the verification, the authorization center can send the target authorization file to the target client in the authorization response information. If the IP address of the target client is in the blacklist, the authorization center can not send the target authorization file to the target client regardless of whether the target authorization identifier passes the verification, in which case the authorization center can not respond.

[0108] After the target authorization identifier passes the authorization identifier verification, the target client can maintain a heartbeat with the authorization center. When the heartbeat is abnormal or the authorization is invalid, part of the functions of the software system are disabled.

[0109] Please refer to Figure 8 , Figure 8Flowchart two of the authorization management method provided by the embodiments of the present application is shown. In this embodiment, after step S130, the method can further include step S150 and step S160.

[0110] In step S150, the first heartbeat message sent by the target client is received.

[0111] In step S160, the authorization of the target client is managed according to the first heartbeat message currently received.

[0112] In this embodiment, the target client can be configured to maintain the heartbeat with the authorization center after receiving the authorization response information including the target authorization file. Optionally, the heartbeat frequency can be configured, for example, 10 minutes / once. The target client can send the first heartbeat message to the target client after receiving the authorization response information or the second heartbeat message of the authorization center. The second heartbeat message represents the heartbeat message sent by the authorization center, and the second heartbeat message and the authorization response information are both response information sent by the authorization center to the target client. The first heartbeat message represents the heartbeat message sent by the target client. The first heartbeat message can include system time or any other information, which can be determined according to actual needs.

[0113] The authorization center can perform heartbeat verification according to the received first heartbeat message, and manage the authorization of the target client according to the heartbeat verification. In this way, after the client obtains the authorization, the authorization verification is also performed to ensure the security. The specific heartbeat verification method can correspond to the information included in the first heartbeat message, which can be determined according to actual needs.

[0114] The inventors of the present application have found that the hardware modules of the cloud service system can be customized through the cloud platform, and the deployed system can be copied at any time. Under this condition, the hardware codes of multiple cloud service systems are consistent. The ability of the traditional authorization management scheme to ensure the uniqueness of the authorization will also disappear. Therefore, as the cloud service is used more and more widely, the traditional authorization management scheme bound to the hardware will also be gradually eliminated. In view of the fact that the uniqueness of the authorization cannot be guaranteed in the cloud service environment and is easily copied and used by users, the embodiments of the present application provide the following methods to enable an authorization file to be activated and used by only one client.

[0115] In the embodiment, the first authorization center random code is included in the response information sent by the authorization center to the target client, and the second authorization center random code is included in the first heartbeat message sent by the target client after receiving the response information sent by the authorization center. That is, the random code is included in the response information sent by the authorization center, and the random code is also included in the heartbeat message sent by the target client. The random code sent by the authorization center is different each time.

[0116] After receiving a first heartbeat message, the authorization center can extract the second authorization center random code included in the first heartbeat message, and then compare the second authorization center random code with the first authorization center random code sent by the target authorization identifier last time. If the two are different, it means that the target client does not pass the heartbeat check this time, and the second heartbeat message can not be sent in response to the first heartbeat message received this time. In this way, the target client will still not obtain the response of the authorization center when the heartbeat times out, and will determine the number of heartbeat abnormities.

[0117] When the number of continuous heartbeat abnormities is greater than the preset number of heartbeat abnormities, the authorization state of the target authorization identifier is set to an invalid state in the local, so that the authorization function corresponding to the target authorization identifier is disabled, until the heartbeat is normal or the user replaces a valid authorization identifier. The number of continuous heartbeat abnormities includes not only the number of times when the authorization center does not respond when the heartbeat times out, but also other heartbeat abnormities. The other heartbeat abnormities can be set according to actual needs, for example, the response analysis failure can be regarded as a heartbeat abnormality, or the number of times when the target client fails to connect the authorization center continuously is greater than the preset number of times, which is also regarded as a heartbeat abnormality. The preset number of heartbeat abnormities can be set to 3, or other values, which can be determined according to actual needs. In this way, when the same authorization identifier is used in multiple software systems, only one of the multiple systems can be used because the random codes in the heartbeat are different.

[0118] The authorization center random code and the time sequence of the heartbeat are as shown in Figure 9 The client in Figure 9 is the target client. As shown in Figure 9 , the authorization center random code is regenerated by the authorization center each time and provided to the target client, and the authorization center uses the authorization center random code sent last time as a check next time. If the authorization center random code carried by the target client is inconsistent with the random code recorded by the authorization center, the next heartbeat response will not be performed.

[0119] Optionally, in the embodiment, the first heartbeat packet can further include a source IP address and the target authorization identifier. When the first heartbeat packet includes the source IP address of the target client, the authorization center can determine whether the source IP address of the target client belongs to the IP addresses in the saved blacklist. If the source IP address of the target client belongs to the IP addresses in the saved blacklist, it indicates that the target client does not pass the heartbeat check this time, and the authorization center can not send the second heartbeat packet in response to the currently received first heartbeat packet.

[0120] When the first heartbeat packet includes the target authorization identifier, the authorization center can determine whether the target authorization identifier is a usable authorization identifier according to the current unusable authorization identifier. The current unusable authorization identifier can be set by a staff in the authorization center or set by other devices. If the target authorization identifier is the same as an unusable authorization identifier, it can be determined that the target authorization identifier is not a usable authorization identifier. If the target authorization identifier is different from all unusable authorization identifiers, it can be determined that the target authorization identifier is a usable authorization identifier. The target authorization identifier being not a usable authorization identifier indicates that the target client does not pass the heartbeat check this time, and the authorization center can not send the second heartbeat packet in response to the currently received first heartbeat packet.

[0121] In the embodiment, the first heartbeat information can include at least one of a second authorization center random code, a source IP address and a target authorization identifier. When there is a result in the corresponding determination result of the included item indicating that the target client does not pass the heartbeat check this time, the authorization center does not send the second heartbeat packet in response to the currently received first heartbeat packet, so that the target client determines that the heartbeat is abnormal once, and further determines that the authorization is invalid when the number of consecutive heartbeat abnormalities is greater than the preset heartbeat abnormality number. When there is no result in the corresponding determination result of the included item indicating that the target client does not pass the heartbeat check this time, the authorization center can determine that the target client passes the heartbeat check this time, and can send the second heartbeat packet in response to the currently received first heartbeat packet.

[0122] For example, when the second authorization center random code, the source IP address and the target authorization identifier are included in the first heartbeat information, if the source IP address in the first heartbeat message is not in the blacklist, the target authorization identifier is a valid authorization identifier, and the second authorization center random code in the current first heartbeat message is the same as the first authorization center random code in the last sent first heartbeat message, a second heartbeat message is sent to the target client to respond. The second heartbeat message sent includes the first authorization center random code regenerated by the authorization center. The data in the heartbeat of the authorization center and the target client can be encrypted for transmission to ensure security.

[0123] Optionally, in the embodiment, the authorization center can record the heartbeat information in the received heartbeat message from each client for authorization verification. The authorization verification based on the recorded heartbeat information can be periodic or non-periodic, which can be determined according to actual needs.

[0124] Please refer to Figure 10 , Figure 10 The third flowchart of the authorization management method provided by the embodiment of the present application is shown. In the embodiment, after step S130, the method further includes steps S170-S180.

[0125] Step S170: According to the received heartbeat message sent by at least one client, it is judged whether the authorization corresponding to the target authorization identifier is abnormal authorization.

[0126] Step S180: When it is determined that the authorization corresponding to the target authorization identifier is abnormal authorization, the authorization state of the target authorization identifier is set to an invalid state, so that the authorization of the target client is invalidated.

[0127] The at least one client is a client using the target authorization identifier. The authorization center can determine whether there is an abnormality in the authorization process of the target authorization identifier according to the received heartbeat message sent by the at least one client. If there is an abnormality, it is determined that the authorization corresponding to the target authorization identifier is abnormal authorization. If there is no abnormality, it is determined that the authorization corresponding to the target authorization identifier is not abnormal authorization.

[0128] Optionally, as a possible implementation, the determination of whether the authorization corresponding to the target authorization identifier is abnormal authorization can be made by the method shown in Figure 11 Please refer to Figure 11 , Figure 11 For Figure 10One of flowchart of sub-steps included in step S170. In the embodiment, the at least one heartbeat message sent by the client includes the first heartbeat message sent by the target client, and step S170 can include sub-step S171 and sub-step S172.

[0129] Sub-step S171, determining the actual heartbeat frequency according to the received first heartbeat message sent by the target client.

[0130] Sub-step S172, judging whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the preset heartbeat frequency and the actual heartbeat frequency.

[0131] The first heartbeat message can include system time, and the actual heartbeat frequency used by the target client when sending the first heartbeat message can be calculated according to the system time. Alternatively, when judging whether the authorization corresponding to the target authorization identifier is an abnormal authorization based on the recorded heartbeat information periodically, the actual heartbeat frequency can be calculated according to the first heartbeat message received in the last period. The authorization center can compare the actual heartbeat frequency with the preset heartbeat frequency, and judge whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the comparison result. The comparison result is used to indicate whether the heartbeat frequency of the target client is abnormal.

[0132] The preset heartbeat frequency can be based on the heartbeat frequency setting configured at the target client. For example, the preset heartbeat frequency is the heartbeat frequency configured at the target client. Alternatively, when the actual heartbeat frequency is greater than the preset heartbeat frequency, it can be determined that the heartbeat frequency of the target client is abnormal; and when the actual heartbeat frequency is not greater than the preset heartbeat frequency, it can be determined that the heartbeat frequency of the target client is normal.

[0133] When the heartbeat frequency of the target client is abnormal, it can be determined that the authorization corresponding to the target authorization identifier is an abnormal authorization. When the heartbeat frequency of the target client is normal, it can be determined that the authorization corresponding to the target authorization identifier is a normal authorization, or the authorization corresponding to the target authorization identifier can be determined to be an abnormal authorization in combination with other judgments on heartbeat information.

[0134] Alternatively, as another possible implementation manner, the authorization corresponding to the target authorization identifier can be judged to be an abnormal authorization by Figure 12 Please refer to Figure 12 , Figure 12 for Figure 10 One of flowchart of sub-steps included in step S170. Step S170 can include sub-step S174 and sub-step S175.

[0135] In the sub-step S174, the authorization usage corresponding to the target authorization identifier is obtained according to the received heartbeat message.

[0136] In the sub-step S175, whether the authorization corresponding to the target authorization identifier is an abnormal authorization is determined according to the authorization usage.

[0137] In the embodiment, the authorization center can receive the heartbeat message of each client using the target authorization identifier, and analyze to obtain the authorization usage corresponding to the target authorization identifier. The authorization usage is used to describe the number of devices using the target authorization identifier. Then, whether the authorization corresponding to the target authorization identifier is an abnormal authorization is determined according to the authorization usage.

[0138] For example, the activation time of the authorization corresponding to the target authorization identifier and the IP address of the client using the target authorization identifier can be obtained according to the received heartbeat message. Then, if the activation time of the authorization corresponding to the target authorization identifier and the IP address of the client using the target authorization identifier obtained according to the above analysis are determined to be greater than a preset activation number and greater than a preset number within a preset time period, it can be determined that the authorization usage is abnormal, and in this case, it can be determined that the authorization corresponding to the target authorization identifier is an abnormal authorization.

[0139] The preset time period can be set according to actual needs. For example, if the authorization corresponding to the target authorization identifier is determined to be an abnormal authorization based on the recorded heartbeat information periodically, the authorization usage can be obtained according to the heartbeat message of the at least one client received in the last period. At this time, the preset time period can be the period used in the periodic verification, for example, one month.

[0140] For example, if it is analyzed that the target authorization identifier is activated more than 5 times in one month, and the number of IP addresses of the client using the target authorization identifier is greater than 3, the target authorization identifier can be marked as a dangerous authorization identifier, and the authorization corresponding to the target authorization identifier is an abnormal authorization.

[0141] The authorization center can record the heartbeat message sent by the client as a behavior data each time the client inputs the authorization identifier for authorization activation. The record data can include: the authorization identifier used for activation, the IP address of the activation client, and the activation time. The authorization identifier used for activation in the behavior data is the authorization identifier in the heartbeat message sent by the client, and the activation time in the behavior data is the system time in the heartbeat message sent by the client. In this way, the authorization verification based on the recorded heartbeat information can be facilitated.

[0142] The authorization corresponding to the target authorization identifier can be determined as an abnormal authorization when the authorization use condition corresponding to the target authorization identifier is abnormal. The authorization corresponding to the target authorization identifier can also be determined as a normal authorization when the authorization use condition corresponding to the target authorization identifier is normal, or the authorization corresponding to the target authorization identifier can be determined as an abnormal authorization in combination with other judgments on the heartbeat information.

[0143] Alternatively, as another possible implementation, the heartbeat frequency of the target client can be determined as abnormal through sub-step S171 to sub-step S172, and the use condition of the target authorization identifier can be determined as abnormal through sub-step S174 to sub-step S175. If either of them is abnormal, the authorization corresponding to the target authorization identifier can be determined as an abnormal authorization. If both of them are normal, the authorization corresponding to the target authorization identifier can be determined as a normal authorization.

[0144] When the authorization corresponding to the target authorization identifier is determined as an abnormal authorization, the authorization center can set the authorization state of the target authorization identifier as an invalid state, so as to invalidate the authorization of the target client. Alternatively, the authorization center can directly send the information that the authorization state of the target authorization identifier is set as an invalid state to the target client, so that the target client sets the authorization state of the target authorization identifier as an invalid state locally, so as to invalidate the authorization of the target client.

[0145] Alternatively, the authorization center can carry the information that the authorization state of the target authorization identifier is an invalid state in a second heartbeat message sent to the target client subsequently. After receiving the second heartbeat message, if the target client parses the authorization state of the target authorization identifier from the second heartbeat message as invalid, the target client sets the authorization state of the target authorization identifier as an invalid state locally, so as to invalidate the authorization of the target client.

[0146] After the authorization center invalidates the authorization corresponding to the target authorization identifier based on the recorded heartbeat information, if an administrator confirms in the authorization center and modifies the authorization state of the target authorization identifier as an available state, the authorization corresponding to the target authorization identifier can continue to be used.

[0147] Optionally, the authorization center can carry at least one of the authorization identifier, the hash value of the authorization file corresponding to the target authorization identifier, the authorization state corresponding to the target authorization identifier, etc. in the heartbeat response sent to the target client. The target client can compare the target authorization identifier sent by itself to the authorization center previously with the authorization identifier in the heartbeat response. If the two are different, it can be determined that the authorization of the target client is invalid, i.e., the authorization of the software system in which the target client is located is invalid. It can also be analyzed whether the authorization state in the heartbeat response is valid. If it is not valid, the target client updates the local authorization state to an invalid state and disables the system function.

[0148] The target client can also compare the target authorization file obtained previously by itself with the hash value of the authorization file in the heartbeat response. If the two are different, it means that the authorization corresponding to the target authorization identifier is updated. In this case, the target client can update the local authorization state to an invalid state, disable the system function, and send an authorization request to the authorization center again to obtain the updated authorization.

[0149] Optionally, the target authorization file sent by the authorization center can also include authorization expiration time description information. After obtaining the target authorization file, the target client can parse the authorization expiration time description information from the target authorization file and determine whether the authorization corresponding to the target authorization is expired according to the authorization expiration time description information. In the case where it is determined that the authorization corresponding to the target authorization identifier is expired, the target client can set the authorization state to invalid in the local to invalidate the authorization of the target client.

[0150] The embodiments of the present application decouple the relationship between authorization management and hardware binding, remotely manage the authorization of different systems through an additional authorization center, thereby realizing the monitoring and management of the uniqueness and legality of authorization, preventing loss caused by malicious copying of users, and enabling the software system that can only be deployed on hardware devices to have more deployment schemes, which can expand the sales form of products and systems.

[0151] Please refer to Figure 13 , Figure 13 The fourth flowchart of the authorization management method provided by the embodiments of the present application is shown. Figure 13 The authorization management method shown in the figure is applied to a client device, the client device includes a client, and the method can include steps S210-S220.

[0152] Step S210, send an authorization request to an authorization center.

[0153] The authorization request includes a target authorization identifier determined based on the received target authorization identifier information.

[0154] At step S220, the authorization response information sent by the authorization center in the case that the target authorization identifier is verified is received.

[0155] The authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the authorization response information includes a target authorization file corresponding to the target authorization identifier.

[0156] Please refer to Figure 14 , Figure 14 The fifth flowchart of the authorization management method provided in the embodiments of the present application is shown. In the embodiments, after step S220, the method further includes steps S230 and S240.

[0157] At step S230, a first heartbeat message is sent to the authorization center.

[0158] At step S240, the authorization of the local device is managed according to whether a second heartbeat message responding to the first heartbeat message is received and / or according to the second heartbeat message responding to the first heartbeat message sent by the authorization center.

[0159] Optionally, in the embodiments, the second heartbeat message can include at least one of a hash value of an authorization file, an authorization state and an authorization identifier. It can be determined whether the authorization identifier in the second heartbeat message is consistent with the target authorization identifier, whether the authorization state is valid, and whether the hash value of the authorization file is the same as the hash value of the target authorization file received. When at least one of the determination results is false, the authorization state is set to invalid in the local device, so that the authorization of the client is invalidated.

[0160] Optionally, in the embodiments, the client device can send an authorization request to the authorization center again to update the authorization.

[0161] Optionally, in the embodiments, the client device can set the authorization state to invalid in the local device when the number of continuous heartbeat exceptions is greater than a preset heartbeat exception number, so that the authorization of the client is invalidated. When a heartbeat timeout does not obtain a response from the authorization center and / or the response fails to be parsed, the heartbeat exception is determined.

[0162] Please refer to Figure 15 , Figure 15The sixth flowchart of the authorization management method provided in the embodiments of the present application is shown in FIG. 6. Optionally, in the embodiment, the authorization file includes authorization expiration time description information. After step S220, the method can further include step S250 and step S260.

[0163] In step S250, it is determined whether the authorization corresponding to the target authorization identifier is expired according to the authorization expiration time description information.

[0164] In step S260, in the case where it is determined that the authorization corresponding to the target authorization identifier is expired, the authorization status is set to invalid locally, so as to invalidate the authorization of the client.

[0165] In the embodiment, the specific description of the authorization management method applied to the client device is the same as the description of the authorization management method applied to the authorization center, which is not repeated here.

[0166] Please refer to Figure 16 , Figure 16 The seventh flowchart of the authorization management method provided in the embodiments of the present application is shown in FIG. 7. Figure 16 The authorization management method shown in FIG. 7 is applied to an authorization system, which includes an authorization center and a client device in communication connection with the authorization center. The authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier. The authorization management method applied to the authorization system can include steps S310-S340.

[0167] In step S310, the client sends an authorization request to the authorization center.

[0168] In the authorization request, the target authorization identifier determined by the client based on the received target authorization identifier information is included.

[0169] In step S320, the authorization center verifies the target authorization identifier according to the saved authorization identifier.

[0170] In step S330, in the case where the target authorization identifier passes the verification, the authorization center sends authorization response information to the client.

[0171] In the authorization response information, the target authorization file corresponding to the target authorization identifier is included.

[0172] In step S340, in the case where the target authorization identifier fails the verification, the authorization center does not send the target authorization file to the client.

[0173] In the embodiment, the authorization management method applied to the authorization system is described above, and the authorization management method applied to the authorization center is described above, and thus the description is omitted here.

[0174] To perform the corresponding steps in the above embodiment and each possible way, the implementation of the authorization management device is given below, which can be used in the above Figure 4 The device structure of the electronic equipment is shown. It should be noted that the authorization management device provided in the embodiment has the same basic principles and technical effects as the above embodiment. For brief description, the part not mentioned in the embodiment can refer to the corresponding content in the above embodiment.

[0175] Please refer to Figure 17 , Figure 17 A block diagram of an authorization management device 500 provided in an embodiment of the application is shown. Figure 17 The authorization management device 500 shown is applied to an authorization center, and the authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier. The authorization management device 500 can include a request receiving module 510, an identifier verification module 520, and a first processing module 530.

[0176] The request receiving module 510 is configured to receive an authorization request sent by a target client. The authorization request includes a target authorization identifier determined by the target client based on received target authorization identifier information.

[0177] The identifier verification module 520 is configured to verify the target authorization identifier according to the saved authorization identifier.

[0178] The first processing module 530 is configured to send authorization response information to the target client if the target authorization identifier passes the verification. The authorization response information includes a target authorization file corresponding to the target authorization identifier.

[0179] The first processing module 530 is further configured to not send the target authorization file to the target client if the target authorization identifier fails the verification.

[0180] Optionally, the first processing module 530 is further configured to perform authorization verification after the target client obtains the target authorization file.

[0181] Please refer to Figure 18 , Figure 18 A block diagram of another authorization management device 600 provided in an embodiment of the application is shown. Figure 18The authorization management apparatus 600 shown in the figure is applied to a client device including a client, and can include a request sending module 610 and a file receiving module 620.

[0182] The request sending module 610 is configured to send an authorization request to an authorization center. The authorization request includes a target authorization identifier determined based on the received target authorization identifier information.

[0183] The file receiving module 620 is configured to receive authorization response information sent by the authorization center in a case where the target authorization identifier passes verification. The authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the authorization response information includes a target authorization file corresponding to the target authorization identifier.

[0184] For reference Figure 19 , Figure 19 Another block schematic diagram of an authorization management apparatus provided by the embodiment is shown in FIG. 2. In the embodiment, the authorization management apparatus 600 can further include a second processing module 630 configured to perform authorization management after the client device obtains the target authorization file.

[0185] Optionally, the above modules can be stored in the memory 310 shown in the figure or solidified in an operating system (OS) of the electronic device 300 in the form of software or firmware (Firmware), and can be executed by the processor 320 in the electronic device 300. Meanwhile, data, program codes and the like required for execution of the above modules can be stored in the memory 310. Figure 4 Figure 4

[0186] The embodiment of the present application further provides a readable storage medium having a computer program stored thereon, and the computer program is executed by a processor to implement the authorization management method.

[0187] ​​To sum up, the embodiment of the present application provides an authorization management method and device, an electronic device and a readable storage medium. A target client determines a target authorization identifier based on received target authorization identifier information, and then sends the target authorization identifier in an authorization request to an authorization center. The authorization center checks the target authorization identifier according to a saved authorization identifier. When the check is passed, the authorization center sends a target authorization file corresponding to the target authorization identifier to the target client in an authorization response information according to the saved at least one authorization identifier and the authorization file corresponding to the authorization identifier. When the check is not passed, the authorization center does not send the target authorization file to the target client. The embodiment of the present application does not strongly bind the authorization management to hardware, but sends the authorization file to the client according to the target authorization identifier not strongly bound to the hardware sent by the client to grant the client corresponding permissions, so that even if the device where the client is located is repaired or the hardware is updated, the client does not need to reapply for authorization.

[0188] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can also be implemented by other manners. The apparatus embodiments described above are only schematic, for example, the flowcharts and block diagrams in the drawings show the possible implementation architectures, functions and operations of the apparatus, method and computer program product according to the embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should also be noted that, in some alternative implementation manners, the functions noted in the blocks can also occur in different order from that noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system for implementing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0189] In addition, each functional module in the embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0190] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts of the prior art that make contributions or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0191] The above only describes optional embodiments of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. An authorization management method characterized by, The method is applied to an authorization center which stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, and the method comprises the following steps: receiving an authorization request sent by a target client, wherein the authorization request comprises a target authorization identifier determined by the target client based on received target authorization identifier information; checking the target authorization identifier according to the saved authorization identifier; in the case that the target authorization identifier passes the check, sending authorization response information to the target client, wherein the authorization response information comprises a target authorization file corresponding to the target authorization identifier and a first authorization center random code; in the case that the target authorization identifier fails to pass the check, not sending the target authorization file to the target client; receiving a first heartbeat packet sent by the target client, wherein the first heartbeat packet sent by the target client after receiving the response information sent by the authorization center comprises a second authorization center random code; managing the authorization of the target client according to the currently received first heartbeat packet; wherein the management of the authorization of the target client according to the currently received first heartbeat packet comprises: judging whether the second authorization center random code in the current first heartbeat packet is the same as the first authorization center random code sent last time; if the second authorization center random code in the current first heartbeat packet is different from the first authorization center random code sent last time, not sending a second heartbeat packet to respond to the currently received first heartbeat packet, wherein when the number of continuous heartbeat abnormities is greater than a preset heartbeat abnormity number, the target client sets the authorization state of the target authorization identifier to an invalid state in the local, and the number of continuous heartbeat abnormities comprises the number of times of not responding by the authorization center when the heartbeat is timed out.

2. The method of claim 1, wherein, The first heartbeat packet further comprises a source IP address and the target authorization identifier, and the management of the authorization of the target client according to the currently received first heartbeat packet further comprises: judging whether the source IP address in the first heartbeat packet is in a blacklist and / or whether the target authorization identifier is a usable authorization identifier; if the source IP address in the first heartbeat packet is in the blacklist and / or the target authorization identifier is not a usable authorization identifier, not sending a second heartbeat packet to respond to the currently received first heartbeat packet; in the case that the source IP address in the first heartbeat packet is not in the blacklist, the target authorization identifier is a usable authorization identifier, and the second authorization center random code in the current first heartbeat packet is the same as the first authorization center random code sent last time, sending a second heartbeat packet to respond to the target client, wherein the second heartbeat packet comprises a newly generated first authorization center random code.

3. The method according to any one of claims 1-2, characterized in that, After the authorization response information is sent to the target client, the method further comprises: determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the received heartbeat message sent by at least one client, wherein the at least one client is a client using the target authorization identifier; when it is determined that the authorization corresponding to the target authorization identifier is an abnormal authorization, setting the authorization state of the target authorization identifier to an invalid state, so as to invalidate the authorization of the target client.

4. The method of claim 3, wherein, The heartbeat message sent by the at least one client includes the first heartbeat message sent by the target client, and the determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the received heartbeat message sent by at least one client comprises: determining an actual heartbeat frequency according to the received first heartbeat message sent by the target client; determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the preset heartbeat frequency and the actual heartbeat frequency.

5. The method of claim 3, wherein, The determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the received heartbeat message sent by at least one client comprises: obtaining an authorization usage of the target authorization identifier according to the received heartbeat message, wherein the authorization usage is used to describe the number of devices using the target authorization identifier; determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the authorization usage.

6. The method of claim 5, wherein, The obtaining the authorization usage of the target authorization identifier according to the received heartbeat message comprises: obtaining an authorization activation time of the target authorization identifier and an IP address of a client using the target authorization identifier according to the received heartbeat message; The determining whether the authorization corresponding to the target authorization identifier is an abnormal authorization according to the authorization usage comprises: if the number of activations of the target authorization identifier is greater than a preset number of activations and the number of IP addresses of the clients using the target authorization identifier is greater than a preset number within a preset time length, it is determined that the authorization corresponding to the target authorization identifier is an abnormal authorization.

7. An authorization management method characterized by, The method is applied to a client device, the client device comprises a client, and the method comprises: sending an authorization request to an authorization center, wherein the authorization request comprises a target authorization identifier determined based on received target authorization identifier information; receiving authorization response information sent by the authorization center in the case that the target authorization identifier passes verification, wherein the authorization center stores at least one authorization identifier and an authorization file corresponding to the authorization identifier, the authorization response information comprises a target authorization file corresponding to the target authorization identifier and a first authorization center random code; sending a first heartbeat message to the authorization center; managing the authorization of the local device according to whether a second heartbeat message responding to the first heartbeat message is received and / or according to the received second heartbeat message sent by the authorization center in response to the first heartbeat message; The management of the authorization of the local device according to whether the second heartbeat message responding to the first heartbeat message is received and / or according to the second heartbeat message responding to the first heartbeat message sent by the authorization center comprises: In a case where the number of continuous heartbeat exceptions is greater than the preset heartbeat exception number, the authorization state is set to invalid locally, so that the authorization of the client is invalidated, wherein the heartbeat exception is determined when the response of the authorization center is not obtained within the heartbeat timeout and / or the response fails to be parsed.

8. The method of claim 7, wherein, The second heartbeat message comprises at least one of the hash value of the authorization file, the authorization state and an authorization identifier, and the management of the authorization of the local device according to the second heartbeat message responding to the first heartbeat message sent by the authorization center comprises: It is judged whether the authorization identifier in the second heartbeat message is consistent with the target authorization identifier, whether the authorization state is valid, and whether the hash value of the authorization file is the same as the hash value of the target authorization file received, and in a case where at least one of the judgment results is no, the authorization state is set to invalid locally, so that the authorization of the client is invalidated.

9. The method according to any of claims 7-8, characterized by, The authorization file comprises authorization expiration time description information, and the method further comprises: It is judged according to the authorization expiration time description information whether the authorization corresponding to the target authorization identifier is expired; In a case where it is determined that the authorization corresponding to the target authorization identifier is expired, the authorization state is set to invalid locally, so that the authorization of the client is invalidated.

Images