An authorization management method, system, computer device, and readable storage medium

Abstract

The present invention discloses an authorization management method, system, computer device and readable storage medium. The method includes: receiving an authorization file; verifying the signature legality of the authorization file through an authorization center; if the signature legality of the authorization file passes the verification, extracting the authorization target type in the authorization item of the authorization file, where the authorization target type includes enterprise, individual or device; if the authorization target type is an enterprise, automatically associating the authorization item with the enterprise account; if the authorization target type is an individual or device, generating an unallocated authorization sub-entry, and through the distribution interface provided by the authorization center, binding the authorization sub-entry to the specified individual or device; recording the distribution status, validity period and recovery cooling period parameters of the authorization sub-entry, and restricting the authorization reallocation conditions according to the recovery cooling period parameters. By extracting the authorization target type in the authorization item, the system of the present invention can dynamically adapt the authorization distribution logic, avoiding the deployment of multiple sets of independent systems and reducing the management authorization cost.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly to an authorization management method, system, computer device, and readable storage medium. Background Art

[0002] In the fields of industrial software and enterprise-level cloud platforms, the authorization management of software functions needs to cover complex scenarios, such as authorizing to devices, individual users, and the enterprise as a whole at the same time. However, the existing authorization management systems have significant limitations:

[0003] Traditional solutions mostly adopt a single authorization target mode, such as only binding users or devices, and cannot adapt to industrial scenarios that require mixed authorization targets. For example, a certain barcode printing module needs to be authorized to a device, while the approval function needs to be authorized to an individual, resulting in the enterprise having to deploy multiple independent authorization systems, with high management costs.

[0004] Secondly, the existing systems lack refined control over the authorization life cycle. For example, when an employee leaves or a device is replaced, the authorization may be immediately reallocated after being recycled, resulting in overuse. Summary of the Invention

[0005] The purpose of the present invention is to provide an authorization management method, system, computer device, and readable storage medium, aiming to solve problems such as the single type of authorization target and the rigid distribution and recycling mechanisms in the existing authorization management systems.

[0006] In a first aspect, an embodiment of the present invention provides an authorization management method, including:

[0007] Receiving an authorization file, the authorization file containing at least one authorization item, where the authorization item includes a unique ID, name, description, authorization target type, function Key, parent node ID, recovery cooling period, authorization data field, or distributable authorization field;

[0008] Verifying the signature legality of the authorization file through an authorization center;

[0009] If the signature legality of the authorization file passes the verification, extracting the authorization target type in the authorization item, where the authorization target type includes an enterprise, an individual, or a device;

[0010] If the authorization target type is an enterprise, automatically associating the authorization item with the enterprise account;

[0011] If the authorization target type is an individual or a device, generating an unallocated authorization sub-entry, and providing a distribution interface through the authorization center to bind the authorization sub-entry to a specified individual or device;

[0012] Record the distribution status, validity period, and recovery cooling period parameters of the authorized sub-entries, and restrict the authorization reallocation conditions according to the recovery cooling period parameters.

[0013] In a second aspect, an embodiment of the present invention provides an authorization management system, including:

[0014] A receiving unit, configured to receive an authorization file, where the authorization file includes at least one authorization item, and the authorization item includes a unique ID, name, description, authorization target type, function Key, parent node ID, recovery cooling period, authorization data field, or distributable authorization field;

[0015] A verification unit, configured to verify the signature legality of the authorization file through an authorization center;

[0016] An extraction unit, configured to extract the authorization target type in the authorization item if the signature legality of the authorization file passes the verification, and the authorization target type includes an enterprise, an individual, or a device;

[0017] An association unit, configured to automatically associate the authorization item with an enterprise account if the authorization target type is an enterprise;

[0018] A binding unit, configured to generate an unallocated authorized sub-entry if the authorization target type is an individual or a device, and provide a distribution interface through the authorization center to bind the authorized sub-entry to a specified individual or device;

[0019] A recording unit, configured to record the distribution status, validity period, and recovery cooling period parameters of the authorized sub-entries, and restrict the authorization reallocation conditions according to the recovery cooling period parameters.

[0020] In a third aspect, an embodiment of the present invention further provides a computer device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the authorization management method described in the first aspect is implemented.

[0021] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the authorization management method described in the first aspect is implemented.

[0022] The present invention discloses an authorization management method, system, computer device, and readable storage medium. The method includes: receiving an authorization file; verifying the signature legality of the authorization file through an authorization center; if the signature legality of the authorization file passes the verification, extracting the authorization target type in the authorization item of the authorization file, where the authorization target type includes an enterprise, an individual, or a device; if the authorization target type is an enterprise, automatically associating the authorization item with the enterprise account; if the authorization target type is an individual or a device, generating an unallocated authorization sub-entry, and providing a distribution interface through the authorization center to bind the authorization sub-entry to a specified individual or device; recording the distribution status, validity period, and recovery cooling period parameters of the authorization sub-entry, and restricting the authorization reallocation condition according to the recovery cooling period parameters. By extracting the authorization target type in the authorization item, the system of the present invention can dynamically adapt the authorization distribution logic, avoiding the deployment of multiple sets of independent systems and reducing the management authorization cost. At the same time, by recording the recovery cooling period parameters of the authorization sub-entry and triggering the cooling period control during recovery, over-authorization is avoided, balancing the enterprise personnel change requirements and the rights and interests protection of software providers. Embodiments of the present invention also provide an authorization management system, a computer-readable storage medium, and a computer device, which have the above beneficial effects and will not be elaborated herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0024] Figure 1 It is a flowchart of the authorization management method;

[0025] Figure 2 It is a schematic block diagram of the authorization management system. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the protection scope of the present invention.

[0027] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprise" indicate the presence of the described features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0028] It should also be understood that the terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include the plural forms.

[0029] It should be further understood that the term "and / or" used in the specification of the present invention and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0030] In this embodiment, the industry cloud software package includes a cloud platform part and a client part.

[0031] The cloud platform is responsible for software distribution, management, connection with the client, etc., and at the same time provides direct access to some software functions based on B / S.

[0032] The client part is installed in the terminal and is used to run software functions that can only run on the terminal. After the client is installed on the terminal, it is required to log in with a personal account by default when starting up, keep connected with the cloud platform, install software modules from the cloud platform, and enable the corresponding functions.

[0033] Please refer to Figure 1 , this embodiment provides an authorization management method, including:

[0034] S101: Receive an authorization file, the authorization file includes at least one authorization item, and the authorization item includes a unique ID, name, description, authorization target type, function Key, parent node ID, recovery cooling period, authorization data field or distributable authorization field;

[0035] In this embodiment, the specific descriptions of each item within the authorization items are as follows: The unique ID is used to confirm uniqueness and for positioning; the description is for the exclusive reading of users; the authorization target types include enterprises, individuals, and devices; when the authorization target is an enterprise, in addition to the unique ID, name, description, authorization target type, parent node ID, and function key, there must be and only be an authorization data field. The function key is used to transmit function information to the authorized individual or device for identifying the authorized functions. The parent node ID is used to indicate that this authorization is an additional function attached to the authorization information pointed to by this attribute. The parent node ID is an optional item and can be selected according to the actual situation. The recovery cooling period is used to set the authorization status to "awaiting refresh" by the system when the authorization is cancelled. When the client refreshes next time, the authorization status becomes "in cooling", and the cooling end time is calculated based on the current time plus the recovery cooling period. Before the cooling time arrives, this authorization can only be restored and authorized to the same user or device. If the recovery cooling period is not provided in the authorization file, it is considered that recovery is not supported. The content of the authorization data field is the authorization key, and the authorization center will not parse the content of the authorization data field.

[0036] The distributable authorization fields include the following sub-fields:

[0037] The authorization quantity (the quantity available for distribution, optional, if not provided, it is considered that there is no quantity limit);

[0038] The cooling excess allowable value (if not provided, the default is 0);

[0039] The start and end times of the validity period (optional, if not provided, there is no limit);

[0040] The longest refresh time (if not provided, it is considered that refreshing is not supported).

[0041] In some embodiments, receiving an authorization file includes:

[0042] Receiving multiple authorization files and verifying the signature legality of each authorization file through the authorization center;

[0043] If the signature legality of the authorization file passes the verification, extract the authorization quantity from the authorization file;

[0044] Aggregate the authorization quantities of the extracted authorization files to generate the total authorization quota.

[0045] By combining security verification and resource aggregation, the problems of fragmentation, inefficiency, and security risks existing in traditional authorization management are solved, and it is especially applicable to the complex multi-authorization package procurement and dynamic allocation scenarios in the industrial field. It can transform scattered authorization resources into a resource pool that enterprises can uniformly plan and use flexibly, while protecting the rights and interests of software developers and platform providers.

[0046] Specifically, after receiving the authorization file uploaded by the sales center or software developer through a secure transmission protocol (such as HTTPS), first perform a file integrity check by verifying the file hash value (such as SHA-256) to ensure that the authorization file has not been tampered with during transmission. Then store the authorization file in a temporary storage area and wait for the subsequent signature verification process.

[0047] The signature verification process includes:

[0048] Verify the digital signature certificate chain in the authorization file. Extract the issuer certificate from the authorization file and verify it level by level up to the root certificate to ensure that the certificate is issued by the cloud platform trust center and has not expired or been revoked.

[0049] Then, according to the signature algorithm specified in the certificate (such as RSA-SHA256), decrypt the signature part of the authorization file to obtain the original file hash value, and compare it with the currently recalculated file hash value to verify whether the file content has been tampered with.

[0050] Then, for the authorization file issued by the sales center, the authorization center also needs to review whether the certificate of the sales center is in the trust chain to ensure the legality of the authorization source.

[0051] If the signature verification passes, the authorization file is transferred to the pending queue and waits for the subsequent authorization quantity extraction operation.

[0052] If the verification fails, the system records the reason for failure (such as invalid certificate, signature mismatch, etc.) and returns an error message to the file uploader, asking to re-upload or provide a valid authorization file.

[0053] After the signature verification passes, the authorization center parses the file using the corresponding parser according to the format of the authorization file (such as XML / JSON).

[0054] For the authorization item containing the distributable authorization field, directly extract the authorization quantity value from the field.

[0055] For the authorization item containing the authorization data field, traverse each sub-entry, regard each sub-entry as an independent authorization, and count the total number of sub-entries as the authorization quantity.

[0056] Then aggregate the authorization quantities of all authorization files to generate the total authorization quota.

[0057] In a specific embodiment, after negotiating with the software provider, the company confirmed the need to purchase 250 user licenses, one edge service component license, and one cloud service account. The software licenses provided by the software provider include: Package A (one cloud service account, one edge service component license, 50 user licenses), Package B (50 user licenses), Package C (10 user licenses), License D (one edge service component license), and License E (1 user license). Therefore, the company purchased one Package A and four Package Bs to meet its requirements. This action obtained a total of 5 license files, including License File 1: one cloud service account, one edge service component license, and 50 user licenses, and License Files 2 - 5 are all: 50 user licenses.

[0058] After obtaining the 5 license files, the license files will be automatically sent to the license center of the cloud platform. Then the license center verifies the signature legality of the 5 license files; when the signature legality of the 5 license files passes the verification, the license quantities in the 5 license files are extracted; then the license quantities of the 5 license files extracted are aggregated to generate the total license quota (250 user licenses, one edge service component license, one cloud service account).

[0059] Then the total license quota is integrated and displayed:

[0060] (1) There is one cloud service account. Since the authorization target of the cloud service account is the enterprise, the cloud service account is directly authorized to the current enterprise without further operations;

[0061] (2) There is one edge service component license. Select a device bound to the company to install this edge service component. This device should be a server. After the authorization is completed, the device will be automatically pushed with the software and installed;

[0062] (3) There are 250 user licenses. Select no more than 250 users associated with this company for authorization. After the authorization is completed, when the user logs in to the device, if the software is not in the device, the user can choose to install it;

[0063] (3A) If the user license issued by the software publisher contains an authorization data field, 250 authorization keys should be provided for each authorization (250 users). The license center will not parse the content of the authorization keys. This company needs to authorize them to the users respectively. After the software is installed on the device by the user, the software will obtain this authorization key through the user information, and determine whether it conforms to its internal rules and use it by itself;

[0064] (3B)If the user authorization issued by the software distributor includes a distributable authorization field, the number of authorizations is 250. The authorization center will allow the authorized company to distribute these authorizations to the corresponding users within the authorized quantity range. This method will provide more functions (such as cooling-off period and overuse, validity period management, authorization recovery function). After the user installs the software on the device, the software will obtain information from the authorization center through the user information and inform the user that the authorization for this software is included.

[0065] S102: Verify the signature legality of the authorization file through the authorization center;

[0066] S103: If the signature legality of the authorization file passes the verification, extract the authorization target type in the authorization item, and the authorization target type includes enterprise, individual or device;

[0067] The following is an explanation of the authorization target type:

[0068] Enterprise: The target of this authorization is the enterprise. All users and devices within the enterprise can use this function without further distributing the authorization;

[0069] Individual: Authorize to a specific user within the enterprise. It needs to be distributed to the specified user in the authorization center before it can be used. Individual authorization is the most common type of authorization, and the authorization provider can limit how many users within the enterprise have the right to use the authorized function;

[0070] Device: Authorize to a specific device within the enterprise. It needs to be distributed to the specified device in the authorization center before it can be used. Device authorization is usually used to authorize the right to use specific hardware, such as authorizing to a printer. Among them, it is also possible not to determine the function of the user.

[0071] Furthermore, an enterprise account, an individual account or a device account is respectively set for the enterprise, individual or device. The individual account is independently registered and created by the user through the cloud platform official website, and the ownership and right of use of the account both belong to the registrant himself. As a basic identity credential, the individual account can independently use the basic functions of the platform and is also a prerequisite for creating and managing the enterprise account.

[0072] Then, after logging in with the individual account, an enterprise account can be created. After the enterprise account is created, its creator automatically becomes the owner of the enterprise account, and this identity can be transferred to other individual accounts within the enterprise. An individual account can be associated with multiple enterprise accounts: after associating with multiple enterprise accounts, when logging in with the individual account, it is necessary to specify the enterprise account to be managed and can switch between different enterprise accounts. An enterprise account can be associated with multiple individual accounts, and different identities can be specified for the individual accounts, and permissions can be set for the identities and individuals.

[0073] After the client is installed on the terminal and logged in, the user can choose to register this terminal as a device account. When registering, this device account needs to be associated with the current enterprise account of the logged-in user. A device can only be registered as a device account under one enterprise account at a time. After being registered as a device account, the device can access without logging in to the personal account and only enjoys the authorization of this device account; if it logs in to the personal account, it will enjoy the authorization of both this device account and the logged-in personal account.

[0074] S104: If the authorization target type is an enterprise, automatically associate the authorization item with the enterprise account;

[0075] In the authorization management system of industry cloud software, when the authorization target type is an enterprise, the authorization item is automatically associated with the enterprise account in the following manner:

[0076] The authorization center receives the authorization file uploaded by the user through the access interface based on the B / S architecture. This file is signed by the publisher's certificate. The authorization center uses the public key of the publisher's certificate issued by the cloud platform's trust center to verify that the file content has not been tampered with and then parses it. The authorization item containing key information such as the authorization target type is extracted from the file. When the authorization target type is identified as an enterprise, proceed to the next step.

[0077] Then the system automatically associates the authorization item with the enterprise account specified in the current operation according to the unique identifier of the enterprise account in the platform. For example, when an enterprise purchases the authorization of a certain software and it includes the authorization of a cloud service account with the authorization target being an enterprise, after verifying the legality of the authorization file, the system will immediately establish an association relationship between this cloud service account authorization item and the enterprise account that purchased the authorization.

[0078] Then the authorization center displays the information of the associated authorization item in the authorization management interface corresponding to the enterprise account. The relevant management personnel of the enterprise account can view the detailed information such as the name and description of this authorization item in this interface. For such authorizations, there is no need for additional distribution operations, and all users and devices within the enterprise can directly use the software functions corresponding to this authorization. For example, for a set of enterprise-level management software authorizations purchased by an enterprise, after being associated with the enterprise account, when internal employees of the enterprise log in to the relevant system or use the corresponding client, they can directly use the various functions of this software without having to apply for a separate authorization.

[0079] Then the authorization center continuously monitors the status of this authorization item, including the validity period, whether there are any abnormalities, etc. If the authorization has a validity period, when it is approaching expiration, the system can automatically send a reminder message to the enterprise account management personnel; if an abnormality occurs, such as the authorization being illegally tampered with or used abnormally, the authorization center takes corresponding measures in a timely manner, such as suspending the authorization use and notifying the relevant personnel for handling, to ensure the legal and compliant use of the authorization by the enterprise.

[0080] S105: If the authorized target type is an individual or a device, generate an unallocated authorization sub-entry, and provide a distribution interface through the authorization center to bind the authorization sub-entry to the specified individual or device;

[0081] In some embodiments, if the authorized target type is an individual or a device, generating an unallocated authorization sub-entry and providing a distribution interface through the authorization center to bind the authorization sub-entry to the specified individual or device includes:

[0082] When the device is registered with the enterprise, collect the device's hardware ID and generate a device account; then associate the device account with the currently logged-in enterprise account, and bind the hardware ID to the authorization center database; then send the function Key in the authorization item to the device account.

[0083] When the device is registered, the hardware ID is collected and bound to the enterprise account, constructing a dual authentication system of device fingerprint + enterprise identity. Even if the account password is leaked, illegal devices still cannot activate the authorization, significantly improving security. After the hardware ID is bound to the account, a device-level trust chain can be achieved, significantly enhancing the security of device authorization. The atomic splitting of the function Key supports fine-grained permission control. This enables the enterprise to configure customized function packages for different positions.

[0084] In some specific embodiments, when the function of the device or its peripherals requires authorization, taking a barcode printer as an example, in a certain solution, the provider limits its usage quantity. For example, in Project A, the customer purchased 5 authorizations, which means that the provider allows a maximum of 5 devices in Project A to connect to the barcode printer, and the usage permission is bound to the device, not the user. That is, as long as the device is authorized, regardless of whether a user is logged in or which user is logged in, the barcode printer function can be used.

[0085] In addition, the concept of workstations is also applicable to this device authorization mode. For example, a certain solution limits the customer to have 10 workstations, but does not limit the total number of employees. Then, only the devices at these 10 workstations need to be authorized, without the need to authorize each user individually.

[0086] In some specific embodiments, the device itself undertakes the role of providing services without the need for user login. Among them, the edge service component is a typical example. This edge service component needs to be installed on the customer's server. Only by registering the server as a device account and obtaining the corresponding authorization can the software be normally installed and verified.

[0087] During the daily business operation, the edge service software installed in the server usually operates in the form of a background service, and no user needs to actively log in throughout the process. Based on this characteristic, it is not appropriate to authorize it to a specific user because its service is not targeted at a single user but the entire business process.

[0088] In view of this, it is particularly important to incorporate device type authorization into the software authorization model. This authorization method provides great convenience for software providers in the platform. They can use it to more effectively plan and manage software authorization methods, accurately control the number of authorizations, thereby improving the operation efficiency of the software, optimizing the user experience, and ensuring the stable operation of the entire software service system.

[0089] In some embodiments, if the authorization target type is an individual or a device, an unallocated authorization sub-entry is generated, and a distribution interface is provided through the authorization center to bind the authorization sub-entry to the specified individual or device. It also includes: generating a unique authorization Key for the authorization item containing the authorization data field and directly binding it to the individual or device; for the authorization item containing the distributable authorization field, recording the authorization quantity, the start time and end time of the validity period, the maximum refresh time, and the cooldown period parameters.

[0090] For the authorization item containing the authorization data field, a unique authorization Key is generated and directly bound to the individual or device. The use of the unique authorization Key enhances the security and uniqueness of the authorization, effectively preventing the authorization from being illegally copied or misused. Each authorization item has a unique identifier, which is convenient for accurate identification and verification in the system, ensuring that only the authorized individual or device can use the authorization.

[0091] For the authorization item containing the distributable authorization field, the authorization quantity, the start time and end time of the validity period, the maximum refresh time, and the cooldown period parameters are recorded. The recording of these detailed parameters provides rich information support for authorization management, enabling the administrator to precisely control the usage scope and time limit of the authorization. For example, the allocation of resources can be controlled by limiting the authorization quantity; the validity period can be set to ensure that the authorization is valid within a reasonable time range; the recording of the maximum refresh time and cooldown period parameters helps manage the usage frequency and rhythm of the authorization, avoiding overuse or misuse of authorization resources.

[0092] S106: Record the distribution status, validity period, and recovery cooldown period parameters of the authorization sub-entry, and limit the authorization reallocation conditions according to the recovery cooldown period parameters.

[0093] In some embodiments, there are certain functions that are not suitable for being authorized to devices. There are many users, but not many of them use the functions simultaneously. For example, for a certain service, it requires approval from its supervisor. The supervisor logs in to the system using their own mobile phone to use this function. The enterprise has shift production, and each shift has its own supervisor. The software provider believes that although not every supervisor needs to use this function at any time, every supervisor needs to obtain authorization. Considering that these supervisors do use it in shifts, the software provider may choose to sell at a reduced unit price, and the using enterprise does not need to authorize the supervisor at the beginning of each shift and reclaim the authorization for the supervisor of the next shift after the shift ends. However, some enterprises may take advantage of this mechanism to only purchase the supervisor authorization for one shift. After obtaining the low price from the software vendor, they still switch the authorization each time. This mechanism results in damage to the legitimate rights and interests of the software provider. For this reason, this embodiment provides authorization cooling, that is, within a certain period of time after an authorized user or device is de-authorized, the authorization enters a "cooling" state for a period of time. Before the cooling time arrives, this authorization can only be "re-authorized" to the same user and device, and cannot be authorized to other users and devices. After the cooling time arrives, the authorization will return to the un-authorized state. By setting the cooling time, the software provider can avoid the above-mentioned situation of authorization abuse. Specifically, record the distribution status, validity period, and recovery cooling period parameters of the authorization sub-entry, and limit the authorization re-distribution conditions according to the recovery cooling period parameters, including: obtaining the recovery cooling period parameters and the current time; then calculating the cooling end time according to the recovery cooling period parameters and the current time, marking the status of the authorization sub-entry as in cooling, and prohibiting its distribution to other objects; within the cooling period, only allow the same authorization to be restored to the original authorized personal account or device account; when the cooling period ends, reset the status of the authorization sub-entry to the un-allocated state, and release the authorization quota to the distributable pool.

[0094] In some specific embodiments, in the authorization management system of the industry cloud software, the recording of the distribution status, validity period, and recovery cooling period parameters of the authorization sub-entry and the implementation method of the relevant authorization re-distribution conditions are as follows:

[0095] When the user imports a file containing authorization information into the authorization center, the system will parse each authorization item. If the authorization item contains a distributable authorization field or involves settings related to the recovery cooling period, the system will record the distribution status (such as un-allocated, authorized, in cooling, waiting for refresh, etc.), validity period (including the start time and end time of the validity period), and recovery cooling period parameters (if not provided, it is considered not to support recovery, that is, there is no recovery cooling period) for each authorization sub-entry. For example, when processing the authorization of 50 users of a certain software purchased by an enterprise, if the authorization contains recovery cooling period parameters, the system will record these information for each authorization sub-entry in detail.

[0096] When a recovery operation is performed on an authorized sub-entry, the system will automatically obtain the recovery cooling period parameter corresponding to the sub-entry. At the same time, the system obtains the current operation time in real time. For example, when an enterprise decides to recover the software authorization of a certain user, the system immediately obtains the recovery cooling period information of the authorized sub-entry and the current system time.

[0097] Then, based on the obtained recovery cooling period parameter and the current time, a calculation is performed to obtain the cooling end time. For example, if the recovery cooling period is 3 days and the current time is 10:00 on October 1, 2024, then the cooling end time is 10:00 on October 4, 2024. After the calculation is completed, the system marks the status of the authorized sub-entry as "in cooling". During this period, it is prohibited to assign this authorization to other personal accounts or device accounts except the original authorized object.

[0098] During the cooling period, the system strictly restricts the operations of the authorization. Only allowing the same authorization to be restored to the original authorized personal account or device account. For example, during the above cooling period, if an enterprise decides to re-enable a previously recovered authorized user, the system can restore the authorization to this user, enabling them to regain the right to use the software.

[0099] When the cooling period ends, the system automatically resets the status of the authorized sub-entry to the "unassigned" state. At the same time, the authorization quota is released to the distributable pool, and the enterprise can assign it to eligible personal accounts or device accounts again. For example, when the cooling end time reaches 10:00 on October 4, 2024, the system automatically updates the status of the authorized sub-entry to unassigned, and the enterprise can assign this authorization to other users or devices in need in the authorization center.

[0100] Furthermore, for sub-entries in the unassigned state, corresponding assignments will be made according to different authorization targets. When the authorization target is an individual, it can be assigned to internal users of the enterprise; when the authorization target is a device, it is assigned to relevant devices within the enterprise. After the assignment is completed, the status of the sub-entry immediately changes to authorized.

[0101] If a recovery cooling period is set for an authorized sub-entry (i.e., the recovery cooling period is not empty), then a recovery operation is allowed. During the recovery, the system calculates the target time based on the current operation time plus the preset recovery cooling period. Before the target time arrives, the status of the sub-entry changes to "in cooling". During this period, the authorization of the original authorized individual or device is cancelled, but this authorization cannot be assigned to other individuals or devices; however, if necessary, it can be reassigned to the original authorized individual or device to restore it to the authorized state. When the cooling time ends, the status of the sub-entry finally becomes unassigned.

[0102] In this embodiment, for the authorization items containing distributable authorization fields, the system will display key information such as the authorization quantity, the allowable value of cooling excess, the start and end times of the validity period, and the maximum refresh time.

[0103] When performing authorization allocation, if the project has not reached the start time of the validity period, the user can allocate authorizations in advance; while for the projects that have exceeded the end time of the validity period, authorization allocation cannot be performed.

[0104] When the user distributes such authorizations to individuals or devices, a refresh time needs to be set. This refresh time cannot exceed the maximum refresh time specified by the system; if not specifically set, the maximum refresh time is adopted by default. After setting the refresh time, the end point of the validity period of the current authorization is determined by taking the later one of the set current time and the start time of the validity period and adding the refresh time. Before the authorization is about to expire, the client will automatically initiate a refresh request. When refreshing, the system will recalculate the end point of the validity period based on the time point when the refresh operation is initiated and adding the refresh time.

[0105] For individuals or devices that have obtained authorizations and support refreshing and have set a recovery cooling period, the user has the right to cancel the authorization. After canceling the authorization, the status of this authorization becomes "awaiting refresh", and during this period, this authorization is still regarded as a valid authorization. When the client refreshes again, the authorization status changes to "in cooling", and the system will calculate the end time of cooling based on the time of this refresh operation plus the recovery cooling period, and only then is the authorization truly cancelled. After the cooling time arrives, the authorization status becomes unallocated. It should be noted that when in the "awaiting refresh" or "in cooling" state, the authorized individuals and devices have actually been de-authorized, but during this period, this authorization cannot be temporarily allocated to other individuals or devices, but can be allocated to the original authorized individuals or devices to restore them to the authorized state.

[0106] In some embodiments, cooling brings another problem, that is, it cannot cope well with changes in personnel and equipment. For example, an enterprise needs 10 authorizations per shift and has 5 shifts, so 50 authorizations are purchased. However, personnel may leave or be replaced. When a new employee replaces an authorized old employee, due to the cooling mechanism, the authorization will not be released immediately, resulting in no available authorization for the new employee. Therefore, this embodiment provides a cooling overage allowance value for authorizations. That is to say, the number of authorizations including cooling and the number of authorizations without cooling are restricted. Therefore, the total number of individuals and devices that have obtained authorizations, plus the total number of authorizations in the "waiting to be refreshed" or "cooling" state, cannot exceed the number of authorizations plus the cooling overage allowance value, so as to ensure the rationality and effectiveness of authorization management. Specifically, recording the distribution status, validity period and recovery cooling period parameters of authorization sub-items, and restricting the authorization reallocation conditions according to the recovery cooling period parameters also includes: real-time monitoring of the number of distributed authorizations, the number of cooling authorizations and the number of authorizations waiting to be refreshed; calculating the current available authorization quota according to the total number of authorizations and the cooling overage allowance value in the authorization file, as well as the number of distributed authorizations, the number of cooling authorizations and the number of authorizations waiting to be refreshed; if the distribution request causes the total number to exceed the current available authorization quota, reject the distribution and generate an alarm notification.

[0107] Among them, the sum of the number of distributed authorizations and the number of authorizations waiting to be refreshed cannot exceed the total number of authorizations in the authorization file.

[0108] In some specific embodiments, according to the total number of authorizations and the cooling overage allowance value in the authorization file, combined with the number of distributed authorizations, the number of cooling authorizations and the number of authorizations waiting to be refreshed monitored in real time, the current available authorization quota is calculated. The calculation formula is: current available authorization quota = total number of authorizations + cooling overage allowance value - (number of distributed authorizations + number of cooling authorizations + number of authorizations waiting to be refreshed). For example, an enterprise purchases 100 software authorizations, the cooling overage allowance value is 10, currently 80 are distributed, 5 are in cooling, and 3 are waiting to be refreshed. Then the current available authorization quota = 100 + 10 - (80 + 5 + 3) = 22.

[0109] When receiving a request for distribution authorization, the system first calculates the current available authorization quota and then compares the quantity requested for distribution with the current available authorization quota. If the distribution request causes the total to exceed the current available authorization quota, the system will reject the distribution request and generate an alarm notification. The alarm notification will be sent to the relevant enterprise managers or authorization administrators in the form of system messages, emails, or text messages, informing them of the reason for the rejection of the distribution request. For example, an employee of an enterprise applies for a new software authorization. If approving this application at this time would cause the total number of authorizations to exceed the current available authorization quota, the system immediately rejects the application and sends an alarm notification to the administrator, reminding the administrator to pay attention to the authorization usage situation so as to make adjustments in a timely manner or apply for new authorizations.

[0110] In some embodiments, a calculation formula for defining the duration T of the recovery cooling period is: T = K×(1 + α×N), where K is the reference cooling duration, α is the excess attenuation coefficient, and N is the current excess authorization number;

[0111] A buffer queue is set up to store the authorizations to be cooled, and the queue capacity threshold Q = M + β×S is dynamically adjusted according to the cooling excess allowance value M, where β is the elasticity coefficient and S is the historical average excess value;

[0112] When the queue reaches the threshold, a forced cooling or capacity expansion request is triggered.

[0113] By defining the duration of the recovery cooling period and dynamically adjusting the queue capacity threshold, the management of the authorization recovery cooling period can be effectively achieved, improving the stability of the authorization management system and the resource utilization efficiency.

[0114] Furthermore, the buffer queue for converting the authorizations to be cooled adopts the LRU algorithm for management. When the queue length L > 0.5·Q, a forced state migration is triggered; specifically, the queue length L (i.e., the number of authorizations being cooled currently stored) is monitored in real time. When L > 0.5·Q, a forced state migration mechanism is triggered to prevent performance bottlenecks from occurring when the queue capacity approaches the threshold.

[0115] The process of the forced state migration mechanism is as follows:

[0116] According to the LRU algorithm, the 3 least recently accessed authorizations in the queue are selected.

[0117] If the remaining cooling time of these authorizations is less than the preset forced migration threshold (for example, the remaining cooling time < 10% of the reference duration K), their status is directly changed to unallocated and they are released to the authorization pool.

[0118] If the remaining cooling time is relatively long, they are migrated to the secondary buffer queue, their refresh priority is reduced, and the queue capacity is released simultaneously.

[0119] Use the LRU algorithm to select the 3 least recently accessed authorizations in the queue. This strategy can accurately locate authorization resources that have not been used for a long time. In actual business scenarios, these authorizations may no longer meet the priority of current business requirements. By screening and processing them, idle and waste of authorization resources can be avoided, enabling authorization resources to be more quickly reallocated to business needs, thereby improving the overall utilization efficiency of authorization resources. When the remaining time of the cooling period of the selected authorization is less than the preset forced migration threshold, directly change its status to unallocated and release it to the authorization pool. This operation can quickly bring idle authorization resources back into the allocable range, reducing business delays caused by tight authorization resources and ensuring smooth business operations.

[0120] In some embodiments, the remaining time of the recovery cooling period is inversely proportional to the usage frequency of the device, and the actual recovery cooling period duration is dynamically adjusted through an exponential decay algorithm.

[0121] Take a key device (Device C) on the production line as an example. It is in a high-load operation state during normal production and has a very high usage frequency. When a certain authorization of Device C enters the recovery cooling period due to special circumstances, the system calculates the remaining time of the cooling period through the exponential decay algorithm based on its historical usage frequency data. Since the usage frequency of Device C is high, according to the inverse relationship, the remaining time of its recovery cooling period will be relatively short. Assuming the initial cooling period is set to 24 hours, after algorithm calculation, the actual cooling duration may be adjusted to 12 hours.

[0122] On the contrary, for some devices with low usage frequency, such as a spare tablet computer (Device D) in the workshop, when its authorization enters the recovery cooling period, due to its low usage frequency, after calculation by the exponential decay algorithm, the actual recovery cooling period duration will be longer than the initially set recovery cooling period. This ensures that devices with low usage frequency have enough time for status adjustment and management during the recovery cooling period, while also avoiding excessive restrictions on high-usage frequency devices, guaranteeing the continuity and efficiency of enterprise production. During the recovery cooling period, the system will monitor the change in the usage frequency of the device in real time. If there is a large fluctuation in the usage frequency of the device, the remaining time of the recovery cooling period will be recalculated through the exponential decay algorithm again to achieve dynamic adjustment of the recovery cooling period.

[0123] In some embodiments, it further includes:

[0124] Parse the parent node ID in the authorization item and identify the dependency relationship between the parent node authorization and the sub-function authorization through the parent node ID; then, according to the dependency relationship, nest and display the sub-function authorization under the parent node authorization in the authorization center; when the parent node authorization is recycled, automatically trigger the cooling period process of all sub-function authorizations under it; when the parent node authorization is valid, allow distribution or refresh of the sub-function authorization.

[0125] Within the authorization center, sub - function authorizations are nested and displayed under the parent - node authorization according to the dependency relationship. This nested display method makes the presentation of authorization information more intuitive and orderly. Users can quickly locate the required authorization items, improving the efficiency of searching and management.

[0126] In some specific embodiments, when receiving an authorization file, the system will deeply analyze the authorization items and extract the parent - node ID information from them.

[0127] The parent - node ID is the key identifier for establishing the dependency relationship between the parent - node authorization and the sub - function authorization. By identifying the parent - node ID, the system can clarify which sub - function authorizations are subordinate to a specific parent - node authorization. For example, in an enterprise - level software system, the parent - node authorization may be the "Financial Management Module", and the sub - function authorizations may include "Accounting Processing", "Report Generation", and "Tax Declaration", etc. By analyzing the parent - node ID, the system can accurately identify the dependency relationship between these sub - function authorizations and the "Financial Management Module" parent - node authorization.

[0128] After identifying the dependency relationship between the parent - node authorization and the sub - function authorization, the authorization center will visually display the authorizations according to this relationship. On the management interface of the authorization center, the sub - function authorizations will be nested and displayed under the corresponding parent - node authorization. For example, in the tree - structure display of the authorization center, with the "Financial Management Module" as the parent node, "Accounting Processing", "Report Generation", and "Tax Declaration" and other sub - function authorizations will be displayed in an indented or hierarchical manner below it. Such a display method clearly presents the hierarchical relationship between the authorizations, facilitating administrators to manage and view.

[0129] When a recovery operation is performed on the parent - node authorization, the system will automatically trigger the cooling - period process for all sub - function authorizations under it. Suppose the administrator decides to recover the authorization of the "Financial Management Module". The system will immediately mark this parent - node authorization as "in recovery", and at the same time, automatically update the status of all sub - function authorizations such as "Accounting Processing", "Report Generation", and "Tax Declaration" to "waiting to enter the cooling period".

[0130] The system will calculate the cooling - end time for each sub - function authorization according to the pre - set recovery cooling - period parameters. During this period, the sub - function authorization is in the "cooling" state. The originally authorized individuals or devices have been de - authorized, and this authorization cannot be temporarily assigned to other individuals or devices, but can be assigned to the originally authorized individuals or devices to restore them to the authorized state. For example, if the recovery cooling - period is set to 7 days, when the system recovers the parent - node authorization, it will calculate the cooling - end time 7 days later for each sub - function authorization and perform corresponding restrictions and management within these 7 days.

[0131] When the authorization of the parent node is in an effective state, the system allows the distribution or refresh operation of the sub - function authorization under it. The administrator can select to distribute the sub - function authorization to the users or devices within the enterprise in the authorization center. For example, when the authorization of the parent node of the "Financial Management Module" is effective, the administrator can distribute the authorization of the "Accounting Processing" sub - function to the employees in the finance department for use.

[0132] When the authorization is approaching expiration, the client will initiate a refresh request. The system will recalculate the expiration point of the sub - function authorization based on the time point when the refresh operation is initiated, plus the preset refresh time. For example, if the refresh time of the "Report Generation" sub - function authorization is set to 30 days and the client initiates a refresh request 5 days before the authorization expires, the system will update the expiration point of the "Report Generation" sub - function authorization to the current time plus 30 days. In this way, under the premise that the parent - node authorization is effective, the sub - function authorization can be flexibly distributed and refreshed to meet the actual business needs of the enterprise.

[0133] In some embodiments, the authorization items are divided into three - level priorities: High, Medium, and Low. Among them, the permanently purchased authorizations (such as the enterprise core - function module) and the authorizations bound to the enterprise's key business processes (such as the device control rights of the production line) are set as high - priority; the periodically subscribed authorizations on demand (such as monthly / quarterly subscription services) and the basic - function authorizations of ordinary users (such as data - viewing permissions) are set as medium - priority; the trial - version or free - version authorizations (such as 30 - day trial functions) and non - core additional functions are set as low - priority; low - priority items are preferentially phased out during migration.

[0134] In some embodiments, a weight value is calculated for each authorization item, and the formula design needs to meet:

[0135] W = α / (T remaining + 1)+β*F access +γ*P;

[0136] Among them, W represents the weight value; α represents the weight coefficient of the remaining cooling - period time; T remaining represents the remaining cooling - period time, in days. The longer the remaining time, the longer the occupation of system resources, and the weight should be reduced. β represents the weight coefficient of the access frequency. F access represents the access frequency, which is the number of accesses within the most recent N days. The higher the frequency, the higher the weight should be increased. γ represents the weight coefficient of the priority. P represents the priority. For example: High = 3, Medium = 2, Low = 1.

[0137] After calculating the weight value of each authorization item according to the above formula, the LRU linked list is sorted from being sorted only by time to being sorted in ascending order of the weight value.

[0138] By combining priority tags with dynamic weight calculation, the system can manage authorized resources more intelligently, taking into account both business priorities and real-time usage.

[0139] In this embodiment, by extracting the authorized target type in the authorization item, the system can dynamically adapt the authorization distribution logic, avoiding the deployment of multiple independent systems and reducing the authorization management cost. At the same time, by recording the recovery cooling period parameter of the authorized sub-item and triggering the cooling period control during recovery, over-authorization is avoided, balancing the enterprise personnel change requirements and the protection of the rights and interests of software providers.

[0140] Please refer to Figure 2 , this embodiment provides an authorization management system 200, including:

[0141] A receiving unit 201 for receiving an authorization file, the authorization file containing at least one authorization item, and the authorization item including a unique ID, name, description, authorized target type, function Key, parent node ID, recovery cooling period, authorization data field or distributable authorization field;

[0142] A verification unit 202 for verifying the signature legality of the authorization file through an authorization center;

[0143] An extraction unit 203 for extracting the authorized target type in the authorization item if the signature legality of the authorization file passes the verification, and the authorized target type including enterprise, individual or device;

[0144] An association unit 204 for automatically associating the authorization item with an enterprise account if the authorized target type is an enterprise;

[0145] A binding unit 205 for generating an unallocated authorized sub-item if the authorized target type is an individual or a device, and providing a distribution interface through the authorization center to bind the authorized sub-item to a specified individual or device;

[0146] A recording unit 206 for recording the distribution status, validity period and recovery cooling period parameter of the authorized sub-item, and restricting the authorization reallocation condition according to the recovery cooling period parameter.

[0147] Furthermore, the receiving unit 201 includes:

[0148] A file verification sub-unit for receiving multiple authorization files and verifying the signature legality of each authorization file through the authorization center;

[0149] A quantity extraction sub-unit for extracting the authorization quantity in the authorization file if the signature legality of the authorization file passes the verification;

[0150] An aggregation subunit, configured to aggregate the authorized quantities of the extracted authorized documents to generate a total authorized quota.

[0151] Further, the binding unit 205 includes:

[0152] An account generation subunit, configured to collect the hardware ID of the device and generate a device account when the device is registered to an enterprise;

[0153] An account association subunit, configured to associate the device account with the currently logged-in enterprise account and bind the hardware ID to the authorization center database;

[0154] A distribution subunit, configured to distribute the function Key in the authorization item to the device account.

[0155] Further, the binding unit 205 includes:

[0156] An authorization Key generation subunit, configured to generate a unique authorization Key for an authorization item containing an authorization data field and directly bind it to an individual or a device;

[0157] A parameter recording subunit, configured to record the authorized quantity, the start time and end time of the validity period, the maximum refresh time, and the cooling period parameters for an authorization item containing distributable authorization fields.

[0158] Further, the recording unit 206 includes:

[0159] A parameter acquisition subunit, configured to acquire the recovery cooling period parameters and the current time;

[0160] An allocation prohibition subunit, configured to calculate the cooling end time according to the recovery cooling period parameters and the current time, mark the status of the authorization sub-entry as in cooling, and prohibit its allocation to other objects;

[0161] A restoration subunit, configured to, within the cooling period, limit the restoration of the same authorization to the original authorized personal account or device account only;

[0162] A release subunit, configured to, when the cooling period ends, reset the status of the authorization sub-entry to the unallocated state and release the authorized quota to the distributable pool.

[0163] Further, the recording unit 206 further includes:

[0164] A real-time monitoring subunit, configured to monitor the distributed authorized quantity, the authorized quantity in cooling, and the authorized quantity waiting for refresh in real time;

[0165] A quota calculation subunit, configured to calculate the current available authorization quota according to the total authorized quantity and the cooling excess allowance value in the authorization document, as well as the distributed authorization quantity, the authorized quantity in cooling, and the authorization quantity waiting for refresh;

[0166] A rejection distribution subunit, configured to reject the distribution and generate an alarm notification if the distribution request causes the total number to exceed the current available authorization quota.

[0167] Furthermore, it further includes:

[0168] An analysis unit, configured to analyze the parent node ID in the authorization item and identify the dependency relationship between the parent node authorization and the sub-function authorization through the parent node ID;

[0169] A nesting unit, configured to nest and display the sub-function authorization under the parent node authorization in the authorization center according to the dependency relationship;

[0170] A trigger unit, configured to automatically trigger the cooling period process of all sub-function authorizations thereunder when the parent node authorization is recycled;

[0171] A refresh unit, configured to allow the distribution or refresh of the sub-function authorization when the parent node authorization is valid.

[0172] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the above-mentioned devices and units can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0173] The present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed, the method provided in the above embodiments can be implemented. The storage medium may include: various media such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs that can store program codes.

[0174] The present invention also provides a computer device, which may include a memory and a processor. When the processor calls the computer program in the memory, the method provided in the above embodiments can be implemented. Of course, the computer device may also include various network interfaces, power supplies and other components.

[0175] The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description in the method section. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

[0176] It should also be noted that in this specification, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises", "comprising" or any other variant thereof are intended to cover non-exclusive inclusion.

[0177] Inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including an..." does not exclude the existence of another identical element in the process, method, article or device including the said element.

Claims

1. A license management method based on a cloud platform, characterized in that, Comprising: Receiving an authorization file, the authorization file containing at least one authorization item, the authorization item including a unique ID, name, description, authorization target type, function Key, parent node ID, recovery cooling period, authorization data field or distributable authorization field; Verifying the signature legality of the authorization file through an authorization center; If the signature legality of the authorization file passes the verification, extracting the authorization target type in the authorization item, the authorization target type including enterprise, individual or device; If the authorization target type is an enterprise, automatically associating the authorization item to an enterprise account; If the authorization target type is an individual or device, generating an unallocated authorization sub-entry and providing a distribution interface through the authorization center to bind the authorization sub-entry to a specified individual or device; Recording the distribution status, validity period and recovery cooling period parameters of the authorization sub-entry, and restricting the authorization reallocation condition according to the recovery cooling period parameters; The recording the distribution status, validity period and recovery cooling period parameters of the authorization sub-entry, and restricting the authorization reallocation condition according to the recovery cooling period parameters includes: Obtaining the recovery cooling period parameters and the current time; Calculating the cooling end time according to the recovery cooling period parameters and the current time, marking the status of the authorization sub-entry as cooling, and prohibiting its allocation to other objects; During the cooling period, restricting that only the same authorization is allowed to be restored to the original authorized personal account or device account; When the cooling period ends, resetting the status of the authorization sub-entry to the unallocated status and releasing the authorization quota to the distributable pool.

2. The authorization management method based on a cloud platform according to claim 1, characterized in that The receiving the authorization file includes: Receiving multiple authorization files and verifying the signature legality of each authorization file through the authorization center; If the signature legality of the authorization file passes the verification, extracting the authorization quantity in the authorization file; Aggregating the authorization quantities of the extracted authorization files to generate a total authorization quota.

3. The authorization management method based on a cloud platform according to claim 1, characterized in that The if the authorization target type is an individual or device, generating an unallocated authorization sub-entry and providing a distribution interface through the authorization center to bind the authorization sub-entry to a specified individual or device includes: When a device is registered to an enterprise, collecting the hardware ID of the device and generating a device account; Associating the device account to the currently logged-in enterprise account and binding the hardware ID to the authorization center database; Sending the function Key in the authorization item to the device account.

4. The authorization management method based on a cloud platform according to claim 1, characterized in that The if the authorization target type is an individual or device, generating an unallocated authorization sub-entry and providing a distribution interface through the authorization center to bind the authorization sub-entry to a specified individual or device further includes: For an authorization item containing an authorization data field, generating a unique authorization Key and directly binding it to an individual or device; For an authorization item containing a distributable authorization field, recording the authorization quantity, start time and end time of the validity period, maximum refresh time and cooling period parameters.

5. The authorization management method based on a cloud platform according to claim 1, wherein, The recording the distribution status, validity period and recovery cooling period parameters of the authorization sub-entry, and restricting the authorization reallocation condition according to the recovery cooling period parameters further includes: Real-time monitoring of the distributed authorization quantity, cooling authorization quantity and waiting-to-refresh authorization quantity; Calculate the current available authorization quota based on the total authorized quantity and the cooling excess allowance value in the authorization file, as well as the distributed authorization quantity, the authorized quantity in cooling, and the authorization quantity waiting for refresh. If the distribution request causes the total to exceed the current available authorization quota, reject the distribution and generate an alarm notification.

6. The authorization management method based on a cloud platform according to claim 1, wherein It also includes: Parse the parent node ID in the authorization item and identify the dependency relationship between the parent node authorization and the sub - function authorization through the parent node ID. Nest - display the sub - function authorization under the parent node authorization in the authorization center according to the dependency relationship. When the parent node authorization is recovered, automatically trigger the cooling - period process for all sub - function authorizations under it. When the parent node authorization is valid, allow the distribution or refresh of the sub - function authorization.

7. An authorization management system based on a cloud platform, characterized in that, It includes: A receiving unit for receiving an authorization file, where the authorization file contains at least one authorization item, and the authorization item includes a unique ID, name, description, authorization target type, function Key, parent node ID, recovery cooling period, authorization data field, or distributable authorization field. A verification unit for verifying the signature legality of the authorization file through the authorization center. An extraction unit for extracting the authorization target type in the authorization item if the signature legality of the authorization file passes the verification, and the authorization target type includes enterprise, individual, or device. An association unit for automatically associating the authorization item with an enterprise account if the authorization target type is enterprise. A binding unit for generating an unallocated authorization sub - entry if the authorization target type is individual or device, and providing a distribution interface through the authorization center to bind the authorization sub - entry to a specified individual or device. A recording unit for recording the distribution status, validity period, and recovery cooling - period parameters of the authorization sub - entry, and restricting the authorization re - distribution conditions according to the recovery cooling - period parameters. The recording unit includes: A parameter - acquisition sub - unit for acquiring the recovery cooling - period parameters and the current time. A distribution - prohibition sub - unit for calculating the cooling - end time according to the recovery cooling - period parameters and the current time, marking the status of the authorization sub - entry as in cooling, and prohibiting its distribution to other objects. A recovery sub - unit for restricting that only the same authorization is allowed to be restored to the original authorized personal account or device account during the cooling period. A release sub - unit for resetting the status of the authorization sub - entry to the unallocated state and releasing the authorization quota to the distributable pool when the cooling period ends.

8. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the authorization management method based on the cloud platform as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer - readable storage medium stores a computer program, and when the computer program is executed by the processor, it causes the processor to execute the authorization management method based on the cloud platform as described in any one of claims 1 to 6.

Images