Authorization management method and system, computer equipment and readable storage medium

Abstract

The invention discloses an authorization management method and system, computer equipment and a readable storage medium. The method comprises the following steps: receiving an authorization file; verifying the signature legality of the authorization file through the authorization center; if the signature legality of the authorization file passes verification, an authorization target type in an authorization item of the authorization file is extracted, and the authorization target type comprises an enterprise, an individual or equipment; 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 equipment, generating an undistributed authorization sub-entry, providing a distribution interface through the authorization center, and binding the authorization sub-entry to the specified individual or equipment; and recording distribution states, validity periods and recovery cooling period parameters of the authorization sub-entries, and limiting authorization redistribution conditions according to the recovery cooling period parameters. According to the method, the authorization target type in the authorization item is extracted, so that the system can dynamically adapt to the authorization distribution logic, deployment of multiple sets of independent systems is avoided, and the authorization management cost is reduced.

Description

Technical Field

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

[0002] In the field of industrial software and enterprise-level cloud platforms, the authorization management of software functions needs to cover complex scenarios, such as authorizing devices, individual users, and the entire enterprise at the same time. However, the existing authorization management system has significant limitations: Traditional solutions mostly use a single authorization target mode, such as binding only to users or devices, which cannot adapt to industrial scenarios that require mixed authorization targets. For example, a barcode printing module needs to be authorized to the device, while the approval function needs to be authorized to an individual, resulting in the need for enterprises to deploy multiple independent authorization systems, which is costly to manage.

[0003] Second, the existing system lacks fine-grained control over the authorization lifecycle. 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

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

[0005] In a first aspect, an embodiment of the present invention provides an authorization management method, including: Receive an authorization file, the authorization file comprising at least one authorization item, the authorization item including a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field or a distributable authorization field; Verify the legitimacy of the signature of the authorization document through the authorization center; If the legality of the signature of the authorization document is verified, the authorization target type in the authorization item is extracted, and the authorization target type includes an enterprise, an individual, or a device; If the authorization target type is an enterprise, the authorization item is automatically associated with the enterprise account; If the authorization target type is an individual or a device, an unassigned authorization sub-entry is generated, and the authorization sub-entry is bound to the designated individual or device through a distribution interface provided by the authorization center; The distribution status, validity period and recycling cooling-off period parameters of the authorization sub-item are recorded, and authorization reallocation conditions are restricted according to the recycling cooling-off period parameters.

[0006] In a second aspect, an embodiment of the present invention provides an authorization management system, including: A receiving unit, configured to receive an authorization file, wherein the authorization file includes at least one authorization item, wherein the authorization item includes a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field, or a distributable authorization field; A verification unit, used to verify the legitimacy of the signature of the authorization document through the authorization center; An extraction unit, configured to extract the authorization target type in the authorization item if the validity of the signature of the authorization document is verified, wherein the authorization target type includes an enterprise, an individual or a device; an associating unit, for automatically associating the authorization item with an enterprise account if the authorization target type is an enterprise; A binding unit, configured to generate an unassigned authorization sub-entry if the authorization target type is an individual or a device, and bind the authorization sub-entry to a designated individual or device through a distribution interface provided by the authorization center; The recording unit is used to record the distribution status, validity period and recycling cooling period parameters of the authorization sub-item, and limit the authorization reallocation conditions according to the recycling cooling period parameters.

[0007] 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 in the memory and executable on the processor, wherein the processor implements the authorization management method described in the first aspect when executing the computer program.

[0008] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein 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 above is implemented.

[0009] The present invention discloses an authorization management method, system, computer equipment and readable storage medium, the method comprising: receiving an authorization file; verifying the legality of the signature of the authorization file through an authorization center; if the legality of the signature of the authorization file is verified, extracting the authorization target type in the authorization item of the authorization file, the authorization target type including 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 unassigned authorization sub-item, and providing a distribution interface through the authorization center to bind the authorization sub-item to a specified individual or device; recording the distribution status, validity period and recovery cooling period parameters of the authorization sub-item, and limiting the authorization redistribution conditions according to the recovery cooling period parameters. The present invention enables the system to dynamically adapt the authorization distribution logic by extracting the authorization target type in the authorization item, avoiding the deployment of multiple independent systems and reducing the cost of managing authorization. At the same time, by recording the recovery cooling period parameters of the authorization sub-item and triggering the cooling period control during recovery, excessive authorization is avoided, and the demand for enterprise personnel changes and the protection of the rights and interests of software providers are balanced. The embodiments of the present invention also provide an authorization management system, a computer-readable storage medium and a computer device, which have the above-mentioned beneficial effects and are not described in detail here. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

[0011] Figure 1 A flowchart of the authorization management method is provided; Figure 2 A schematic block diagram of an authorization management system. DETAILED DESCRIPTION

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

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

[0014] It should also be understood that the terms used in this 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, the singular forms "a", "an" and "the" are intended to include plural forms unless the context clearly indicates otherwise.

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

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

[0017] The cloud platform is responsible for software distribution, management, and connection with clients, while also providing direct access to some B / S-based software functions.

[0018] The client part is installed in the terminal and is used to run software functions that can only be 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 it is started, maintain a connection with the cloud platform, install software modules from the cloud platform, and enable corresponding functions.

[0019] See also Figure 1 , this embodiment provides an authorization management method, including: S101: receiving an authorization file, wherein the authorization file includes at least one authorization item, wherein the authorization item includes a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field, or a distributable authorization field; In this embodiment, the specific description of each item in the authorization item is as follows: the unique ID is used to confirm the uniqueness and positioning; the description is used for user reading only; the authorization target type includes enterprise, individual and device; 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 is only and must be an authorization data field. The function key is used to transmit the function information to the authorized individual or device for identifying the authorized function. The parent node ID is used to indicate that this authorization is an additional function, which is attached to the authorization information pointed to by this attribute. The parent node ID is an optional option and can be selected according to the actual situation. The recovery cooling period is used when the authorization is canceled, and the system sets the authorization status to "waiting for refresh" according to the recovery cooling period. When the client refreshes next time, the authorization status becomes "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 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.

[0020] The Distributable Authorization field contains the following subfields: Authorized quantity (the quantity available for distribution, optional. If not provided, it is assumed that there is no quantity limit); Cooling excess allowance (default is 0 if not provided); Validity start and end time (optional, no limit if not provided); Maximum refresh time (if not provided, refresh is assumed not to be supported).

[0021] In some embodiments, receiving the authorization file includes: Receive multiple authorization documents and verify the legitimacy of the signatures of each authorization document through the authorization center; If the signature legitimacy of the authorization file is verified, extract the authorization quantity in the authorization file; Aggregate the authorization quantities of each extracted authorization file to generate the total authorization quota.

[0022] Through the combination of security verification and resource aggregation, it solves the fragmentation, inefficiency and security risk problems existing in traditional authorization management, and is particularly suitable for complex multi-authorization package procurement and dynamic allocation scenarios in the industrial field. It can transform scattered authorization resources into a resource pool that can be uniformly planned and flexibly used by enterprises, while protecting the rights and interests of software developers and platform parties.

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

[0024] The signature verification process includes: Verify the digital signature certificate chain in the authorization file. Extract the publisher certificate from the authorization file and verify it step by step until the root certificate is reached to ensure that the certificate is issued by the cloud platform trust center and has not expired or been revoked.

[0025] Then, according to the signature algorithm specified in the certificate (such as RSA-SHA256), the signature part of the authorized file is decrypted to obtain the original file hash value, and compared with the recalculated current file hash value to verify whether the file content has been tampered with.

[0026] Then, for the authorization document issued by the sales center, the authorization center must also review whether the sales center's certificate is in the trust chain to ensure the legitimacy of the authorization source.

[0027] If the signature verification passes, the authorization file will be transferred to the processing queue, waiting for the subsequent authorization quantity extraction operation.

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

[0029] When the signature verification is passed, the authorization center uses the corresponding parser to parse the file according to the format of the authorization file (such as XML / JSON).

[0030] For authorization items that contain a distributable authorization field, the authorization quantity value is directly extracted from the field.

[0031] For authorization items that contain authorization data fields, traverse each sub-entry, treat each sub-entry as an independent authorization, and count the total number of sub-entries as the number of authorizations.

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

[0033] In a specific embodiment, after negotiating with the software provider, the company confirmed that it needed to purchase 250 user authorizations, one side service component authorization, and one cloud service account. The software authorizations provided by the software provider include: Package A (one cloud service account, one side service component authorization, 50 user authorizations), Package B (50 user authorizations), Package C (10 user packages), D authorization (one side service component authorization), and E authorization (1 user authorization). Therefore, the company purchased one Package A and four Package B to cover its needs. This behavior obtained a total of 5 authorization files, including Authorization File 1: one cloud service account, one side service component authorization, 50 user authorizations, and Authorization Files 2-5 are all: 50 user authorizations.

[0034] After obtaining the five authorization files, the authorization files will be automatically sent to the authorization center of the cloud platform. The authorization center then verifies the legitimacy of the signatures of the five authorization files. When the legitimacy of the signatures of the five authorization files is verified, the authorization quantities in the five authorization files are extracted. The authorization quantities of the five extracted authorization files are then aggregated to generate a total authorization quota (250 user authorizations, one side service component authorization, and one cloud service account).

[0035] The total authorized quota is then combined to display: (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 operation; (2) There is one authorization for the side service component. Select a device bound to the company to install this side service component. This device should be a server. After the authorization is completed, the device will automatically be pushed the software and installed; (3) There are 250 user authorizations. Select no more than 250 users associated with this company to authorize. After the authorization is completed, when the user logs in to the device, if the device does not have this software, they can choose to install it; (3A) If the user authorization issued by the software publisher contains the authorization data field, then an authorization key (250) should be provided for each authorization (250 users). The authorization center will not parse the content of the authorization key. The company needs to authorize it to each user. After the user installs the software on the device, the software will obtain the authorization key through the user information, determine whether it meets its internal rules, and use it; (3B) If the user authorization issued by the software publisher contains 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. This method will provide more functions (such as cooling-off period and overuse, validity period management, and authorization recovery functions). After the user installs the software on the device, the software will obtain information from the authorization center through the user information, informing the user that the authorization for this software is included.

[0036] S102: Verify the legitimacy of the signature of the authorization document through the authorization center; S103: If the legality of the signature of the authorization document is verified, extracting the authorization target type in the authorization item, where the authorization target type includes an enterprise, an individual, or a device; The following describes the authorization target types: Enterprise: This license is targeted at enterprises. All users and devices within the enterprise can use this feature without the need to redistribute the license; Individual: Authorized to specific users within the enterprise. It needs to be distributed to designated users in the authorization center before it can be used. Individual authorization is the most common authorization, and the authorization provider can limit how many users within the enterprise are entitled to use the authorized functions; Device: Authorization is for 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 use of specific hardware, such as authorization to a printer, in which case it is not necessary to determine the user's function.

[0037] Furthermore, corresponding to enterprises, individuals or devices, there are enterprise accounts, personal accounts or device accounts. Personal accounts are created by users through the cloud platform official website. The ownership and use rights of the account belong to the registrant himself. As a basic identity credential, a personal account can independently use the basic functions of the platform, and it is also a prerequisite for creating and managing enterprise accounts.

[0038] After logging in with a personal account, you can create a business account. After a business account is created, its creator automatically becomes the owner of the business account, and this identity can be transferred to other personal accounts within the business. A personal account can be associated with multiple business accounts: When multiple business accounts are associated, the personal account needs to specify the business account to be managed when logging in, and can switch between different business accounts. A business account can be associated with multiple personal accounts, and different identities can be specified for personal accounts, and permissions can be set for identities and individuals.

[0039] After the client is installed on the terminal and logged in, you can choose to register this terminal as a device account. When registering, you need to associate this device account with the current corporate account of the logged-in user. A device can only be registered as a device account under one corporate account at a time. After registering as a device account, the device does not need to log in to a personal account, but only enjoys the authorization of this device account; if you log in to a personal account, you enjoy the authorization of both this device account and the logged-in personal account.

[0040] S104: If the authorization target type is an enterprise, automatically associate the authorization item with the enterprise account; In the authorization management system of industry cloud software, when the authorization target type is enterprise, the authorization item is automatically associated with the enterprise account as follows: The authorization center receives the authorization file uploaded by the user through the access interface based on the B / S architecture. The file is signed by the publisher's certificate. The authorization center uses the publisher's certificate public key issued by the cloud platform's credit center to verify that the file content has not been tampered with before parsing. The authorization items containing key information such as the authorization target type are extracted from the file. When the authorization target type is identified as an enterprise, the next step is taken.

[0041] Then the system automatically associates the authorization item with the enterprise account specified by the current operation based on the unique identifier of the enterprise account in the platform. For example, when an enterprise purchases a software license, if the license target includes the enterprise's cloud service account authorization, the system will immediately associate the cloud service account authorization item with the enterprise account that purchased the license after verifying the legitimacy of the authorization file.

[0042] The authorization center will then display the associated authorization item information in the authorization management interface corresponding to the enterprise account. The relevant managers of the enterprise account can view the name, description and other detailed information of the authorization item on this interface. For this type of authorization, no additional distribution operations are required, and all users and devices within the enterprise can directly use the software functions corresponding to the authorization. For example, after an enterprise purchases a set of enterprise-level management software licenses and associates it with the enterprise account, when internal employees log in to related systems or use corresponding clients, they no longer need to make a separate authorization application and can directly use the various functions of the software.

[0043] Then the authorization center continuously monitors the status of the authorization item, including validity period, whether there are any abnormalities, etc. If the authorization has a validity period, the system can automatically send a reminder message to the enterprise account manager when it is about to expire; if there is an abnormality, such as the authorization is illegally tampered with or used abnormally, the authorization center will take corresponding measures in a timely manner, such as suspending the use of the authorization and notifying relevant personnel to handle it, to ensure that the enterprise uses the authorization legally and in compliance with regulations.

[0044] S105: If the authorization target type is an individual or a device, an unassigned authorization sub-entry is generated, and the authorization sub-entry is bound to a designated individual or device through a distribution interface provided by the authorization center; In some embodiments, if the authorization target type is a person or a device, generating an unassigned authorization sub-entry and binding the authorization sub-entry to the specified person or device through a distribution interface provided by the authorization center includes: When the device is registered to the enterprise, the hardware ID of the device is collected and a device account is generated; then the device account is associated with the currently logged-in enterprise account, and the hardware ID is bound to the authorization center database; then the function key in the authorization item is sent to the device account.

[0045] When registering a device, the hardware ID is collected and bound to the enterprise account, building a dual authentication system of device fingerprint + enterprise identity. Even if the account password is leaked, illegal devices cannot activate the authorization, which significantly improves security. After the hardware ID is bound to the account, a device-level trust chain can be implemented, which significantly improves the security of device authorization. The atomic splitting of function keys supports fine-grained permission control. This allows enterprises to configure customized function packages for different positions.

[0046] In some specific embodiments, when the functions of a device or its peripherals require authorization, taking a barcode printer as an example, in a certain solution, the provider limits the number of its uses. 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 rights are bound to the device, not the user. That is, as long as the device is authorized, the barcode printer function can be used regardless of whether the user is logged in or which user is logged in.

[0047] In addition, the concept of workstations also applies to this device authorization model. For example, if a solution limits a customer to 10 workstations but does not limit the total number of employees, then only the devices in these 10 workstations need to be authorized, without the need to authorize each user separately.

[0048] In some specific embodiments, the device itself plays the role of providing services without the need for user login, of which the side service component is a typical example. This side service component needs to be installed on the client's server. Only when the server is registered as a device account and the corresponding authorization is obtained, can the software be installed and verified normally.

[0049] In the daily business operation process, the side service software installed in the server usually operates in the form of background services, without any user actively logging in. Based on this feature, it is inappropriate to authorize it to a specific user, because its service is not for a single user, but for the entire business process.

[0050] In view of this, it is particularly important to include device type authorization in the software authorization model. This authorization method provides great convenience for software providers on the platform, who can use it to more effectively plan and manage software authorization methods, accurately control the number of authorizations, and thus improve software operational efficiency, optimize user experience, and ensure the stable operation of the entire software service system.

[0051] In some embodiments, if the authorization target type is an individual or a device, an unassigned authorization sub-entry is generated, and a distribution interface is provided through the authorization center. Binding the authorization sub-entry to a specified individual or device also includes: for authorization items containing authorization data fields, generating a unique authorization key and binding it directly to the individual or device; and for authorization items containing distributable authorization fields, recording the number of authorizations, the start and end time of the validity period, the maximum refresh time, and the cooling-off period parameters.

[0052] For authorization items that contain authorization data fields, a unique authorization key is generated and directly bound to an individual or device. The use of a unique authorization key enhances the security and uniqueness of the authorization, and can effectively prevent the authorization from being illegally copied or abused. Each authorization item has a unique identifier, which facilitates accurate identification and verification in the system, ensuring that only authorized individuals or devices can use the authorization.

[0053] For authorization items that contain distributable authorization fields, the number of authorizations, the start and end time of the validity period, the maximum refresh time, and the cooling-off period parameters are recorded. The recording of these detailed parameters provides rich information support for authorization management, allowing administrators to accurately control the scope of use and time limits of authorizations. For example, resource allocation can be controlled by limiting the number of authorizations; the setting of the validity period can ensure that the authorization is valid within a reasonable time range; the recording of the maximum refresh time and cooling-off period parameters helps to manage the frequency and rhythm of authorization use to avoid excessive use or abuse of authorized resources.

[0054] S106: Record the distribution status, validity period and recycling cooling-off period parameters of the authorization sub-item, and restrict authorization reallocation conditions according to the recycling cooling-off period parameters.

[0055] In some embodiments, some functions are not suitable for authorization to devices. There are many users, but not many users at the same time. For example, a business requires approval from its supervisor. The supervisor uses his own mobile phone to log in to the system to use this function. The company works in shifts, and each shift has its own supervisor. The software provider believes that although not every supervisor needs to use this function at any time, each supervisor needs to be authorized. Considering that these supervisors are indeed used in shifts, the software provider may choose to reduce the unit price for sale, and the using enterprise does not need to authorize the supervisor at the beginning of each shift and recycle the authorization after the shift ends for the supervisor of the next shift. However, some companies may use this mechanism to purchase only the supervisor authorization of one shift, and after obtaining the low price from the software supplier, they still switch the authorization every time. This mechanism causes the legitimate rights and interests of the software provider to be damaged. For this reason, this embodiment provides authorization cooling, that is, when an authorized user or device is deauthorized for a period of time, the authorization enters the "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 be restored to the unauthorized state. By setting a cooling-off period, software providers can avoid the above-mentioned abuse of authorization. Specifically, the distribution status, validity period, and recycling cooling-off period parameters of the authorization sub-item are recorded, and the authorization redistribution conditions are restricted according to the recycling cooling-off period parameters, including: obtaining the recycling cooling-off period parameters and the current time; then calculating the cooling-off end time according to the recycling cooling-off period parameters and the current time, marking the status of the authorization sub-item as cooling-off, and prohibiting its allocation to other objects; during the cooling-off period, only the same authorization is allowed to be restored to the original authorized personal account or device account; when the cooling-off period ends, the status of the authorization sub-item is reset to the unallocated state, and the authorization quota is released to the distributable pool.

[0056] In some specific embodiments, in the authorization management system of the industry cloud software, the distribution status, validity period, and recycling cooling period parameters of the authorization sub-items and the implementation methods of the related authorization reallocation conditions are as follows: When the user imports a file containing authorization information in 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 recycling cooling-off period, the system will record the distribution status (such as unallocated, authorized, cooling down, waiting for refresh, etc.), validity period (including validity start time and end time) and recycling cooling-off period parameters for each authorization sub-item (if not provided, it is considered that recycling is not supported, that is, there is no recycling cooling-off period). For example, when processing 50 user authorizations for a certain software purchased by an enterprise, if the authorization contains recycling cooling-off period parameters, the system will record this information for each authorization sub-item in detail.

[0057] When a recovery operation is performed on an authorized sub-item, the system automatically obtains the recovery cooling period parameters corresponding to the sub-item. At the same time, the system obtains the current operation time in real time. For example, if an enterprise decides to recover a user's software authorization, the system immediately obtains the recovery cooling period information of the authorization sub-item and the current system time.

[0058] Then, the system calculates the cooling-off period parameters and the current time to get the cooling-off end time. For example, if the cooling-off period is 3 days and the current time is 10:00 on October 1, 2024, then the cooling-off end time is 10:00 on October 4, 2024. After the calculation is completed, the system marks the status of the authorization sub-item as cooling-off. During this period, the authorization is prohibited from being assigned to other personal accounts or device accounts except the original authorized object.

[0059] During the cooling-off period, the system strictly limits the authorized operations. The same authorization is only allowed to be restored to the original authorized personal account or device account. For example, during the cooling-off period, if the enterprise decides to re-enable a user whose authorization was previously revoked, the system can restore the authorization to the user, allowing the user to regain the authorization to use the software.

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

[0061] Furthermore, for sub-items in the unassigned state, they will be assigned accordingly according to the authorization target. When the authorization target is an individual, it can be assigned to users within the enterprise; when the authorization target is a device, it is assigned to the relevant devices within the enterprise. After the assignment is completed, the status of the sub-item will be changed to authorized.

[0062] If a recycling cooling-off period is set for an authorized sub-item (i.e., the recycling cooling-off period is not empty), recycling operations are allowed. When recycling, the system will calculate the target time based on the current operation time plus the preset recycling cooling-off period. Before the target time is reached, the status of the sub-item is changed to "Cooling Down". During this period, the authorization of the original authorized individual or device is revoked, but this authorization cannot be assigned to other individuals or devices; however, if necessary, it can be reallocated to the original authorized individual or device to restore it to the authorized state. When the cooling-off period ends, the status of the sub-item eventually changes to Unassigned.

[0063] In this embodiment, for authorization items that include a distributable authorization field, the system displays key information such as the authorization quantity, the cooling excess allowance, the validity start and end time, and the maximum refresh time.

[0064] When allocating authorization, if the project has not yet reached the start time of the validity period, the user can pre-allocate authorization; however, for projects that have exceeded the end time of the validity period, authorization cannot be allocated.

[0065] When users distribute such authorizations to individuals or devices, they need to set a refresh time. The refresh time cannot exceed the maximum refresh time specified by the system; if not specifically set, the maximum refresh time is used by default. After the refresh time is set, the end point of the validity period of the authorization is determined by taking the later of the current time and the start time of the validity period plus 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 plus the refresh time.

[0066] For individuals or devices that have been authorized and support refresh and have set a recycling cooling-off period, the user has the right to cancel the authorization. After canceling the authorization, the status of the authorization changes to "Waiting for Refresh". During this period, the authorization is still considered a valid authorization. When the client refreshes again, the authorization status changes to "Cooling Off". The system will calculate the cooling-off end time based on the time of this refresh operation plus the recycling cooling-off period. Only then is the authorization considered to be truly canceled. After the cooling-off time is reached, the authorization status changes to Unassigned. It should be noted that in the "Waiting for Refresh" or "Cooling Off" status, the authorized individuals and devices have actually been deauthorized. However, during this period, the authorization cannot be temporarily assigned to other individuals or devices, but can be assigned to the original authorized individuals or devices to restore them to an authorized state.

[0067] In some embodiments, cooling will bring another problem, that is, it cannot cope well with changes in personnel and equipment. For example, an enterprise needs 10 authorizations for each shift and has 5 teams, so 50 authorizations are purchased. However, personnel may resign or be replaced. When a new employee replaces an old authorized employee, the authorization will not be released immediately due to the cooling mechanism, resulting in the new employee having no available authorization. For this reason, this embodiment provides an excess allowance for cooling in the authorization. In other words, the number of authorizations with cooling and the number of authorizations without cooling are limited. Therefore, the total number of authorized individuals and devices, plus the total number of authorizations in the "waiting for refresh" or "cooling" state, cannot exceed the number of authorizations plus the excess allowance for cooling, so as to ensure the rationality and effectiveness of authorization management. Specifically, the distribution status, validity period and recycling cooling period parameters of the authorization sub-items are recorded, and the authorization reallocation conditions are restricted according to the recycling cooling period parameters, including: real-time monitoring of the number of distributed authorizations, the number of authorizations being cooled down, and the number of authorizations waiting to be refreshed; calculating the current available authorization quota according to the total number of authorizations and the allowed value for cooling down in the authorization file, as well as the number of distributed authorizations, the number of authorizations being cooled down, and the number of authorizations waiting to be refreshed; if the distribution request causes the total number to exceed the current available authorization quota, the distribution is rejected and an alarm notification is generated.

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

[0069] In some specific embodiments, the current available authorization quota is calculated based on the total number of authorizations and the cooling excess allowance in the authorization file, combined with the real-time monitored number of distributed authorizations, number of cooling authorizations, and number of authorizations waiting to be refreshed. The calculation formula is: Current available authorization quota = total number of authorizations + cooling excess allowance - (number of distributed authorizations + number of cooling authorizations + number of waiting to be refreshed). For example, a company purchased 100 software licenses, the cooling excess allowance is 10, 80 have been distributed, 5 are cooling, and 3 are waiting to be refreshed, then the current available authorization quota = 100 + 10 - (80 + 5 + 3) = 22.

[0070] When receiving a request to distribute authorization, the system will first calculate the current available authorization quota, and then compare the number of distribution requests with the current available authorization quota. If the distribution request causes the total number 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 why the distribution request was rejected. For example, an employee of an enterprise applies for a new software authorization, but if the application is approved at this time, the total number of authorizations will exceed the current available authorization quota. The system will immediately reject the application and send an alarm notification to the administrator, reminding the administrator to pay attention to the use of authorizations so that adjustments can be made or new authorizations can be applied for in a timely manner.

[0071] In some embodiments, the calculation formula for the recovery cooling period T is defined as: T=K×(1+α×N), where K is the reference cooling period, α is the excess attenuation coefficient, and N is the current excess authorization number; Set a buffer queue to store pending cooling authorizations, and dynamically adjust the queue capacity threshold Q = M + β × S according to the cooling excess allowable value M, where β is the elasticity coefficient and S is the historical average excess value; When the queue reaches the threshold, a forced cooling or expansion request is triggered.

[0072] By defining the duration of the recycling cool-down period and dynamically adjusting the queue capacity threshold, the authorization recycling cool-down period management can be effectively implemented, improving the stability and resource utilization efficiency of the authorization management system.

[0073] Furthermore, the buffer queue for the conversion of authorizations to be cooled is managed using the LRU algorithm. 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 currently stored in cooling) is monitored in real time. When L>0.5·Q, a forced state migration mechanism is triggered to prevent performance bottlenecks when the queue capacity approaches the threshold.

[0074] The process of the mandatory state migration mechanism is: According to the LRU algorithm, the three authorizations that have not been accessed for the longest time in the queue are filtered out.

[0075] If the remaining cool-down period of these authorizations is less than the preset forced migration threshold (for example, the remaining cool-down period < 10% of the benchmark duration K), their status will be directly changed to unallocated and released to the authorization pool.

[0076] If the remaining time of the cooling period is long, it will be migrated to the secondary buffer queue and its refresh priority will be reduced, while the queue capacity will be released.

[0077] The LRU algorithm is used to filter out the three authorizations that have not been accessed for the longest time in the queue. This strategy can accurately locate those 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 needs. By screening and processing them, the idleness and waste of authorization resources can be avoided, and authorization resources can be reallocated to businesses in need more quickly, thereby improving the overall utilization efficiency of authorization resources. When the remaining time of the screened authorization cooling period is less than the preset forced migration threshold, its status is directly changed to unallocated and released to the authorization pool. This operation can quickly bring idle authorization resources back into the allocable range, reduce business delays caused by tight authorization resources, and ensure the smooth development of business.

[0078] In some embodiments, the remaining time of the recycling cool-down period is inversely proportional to the frequency of use of the device, and the actual recycling cool-down period duration is dynamically adjusted through an exponential decay algorithm.

[0079] 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 is used very frequently. When a certain authorization of device C enters the recycling cooling period due to special circumstances, the system calculates the remaining time of the cooling period through an exponential decay algorithm based on its historical usage frequency data. Since device C is used frequently, according to the inverse relationship, the remaining time of its recycling cooling period will be relatively short. Assuming that the initial cooling period is set to 24 hours, after algorithm calculation, the actual cooling time may be adjusted to 12 hours.

[0080] On the contrary, for some devices with low usage frequency, such as the spare tablet computer (device D) in the workshop, when its authorization enters the recycling cooling period, due to its low usage frequency, after calculation through the exponential decay algorithm, the actual recycling cooling period will be longer than the initially set recycling cooling period. This ensures that low-frequency devices have enough time to adjust and manage their status during the recycling cooling period, while also avoiding excessive restrictions on high-frequency devices, ensuring the continuity and efficiency of corporate production. During the recycling cooling period, the system will monitor the changes in the frequency of use of the equipment in real time. If the frequency of use of the equipment fluctuates significantly, the remaining time of the recycling cooling period will be recalculated through the exponential decay algorithm to achieve dynamic adjustment of the recycling cooling period.

[0081] In some embodiments, 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; then nest the sub-function authorization under the parent node authorization in the authorization center according to the dependency relationship; when the parent node authorization is reclaimed, the cooling-off period process of all sub-function authorizations under it is automatically triggered; when the parent node authorization is valid, the distribution or refresh of the sub-function authorization is allowed.

[0082] In the authorization center, sub-function authorizations are nested and displayed under parent node authorizations according to dependencies. 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 search and management.

[0083] In some specific embodiments, when receiving the authorization file, the system will perform an in-depth analysis of the authorization items and extract the parent node ID information therefrom.

[0084] 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 clearly identify 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 "Financial Management Module", while the sub-function authorizations may include "Accounting Processing", "Report Generation" and "Tax Declaration". By parsing the parent node ID, the system can accurately identify the dependency relationship between these sub-function authorizations and the parent node authorization of "Financial Management Module".

[0085] After identifying the dependency relationship between the parent node authorization and the sub-function authorization, the authorization center will visualize the authorization according to this relationship. On the management interface of the authorization center, the sub-function authorization will be nested and displayed under the corresponding parent node authorization. For example, in the tree structure display of the authorization center, the "Financial Management Module" is the parent node, and the sub-function authorizations such as "Accounting Processing", "Report Generation" and "Tax Declaration" will be displayed in an indented or hierarchical manner. This display method clearly presents the hierarchical relationship between authorizations, making it easier for administrators to manage and view.

[0086] When the parent node authorization is reclaimed, the system will automatically trigger the cooling-off period for all its sub-function authorizations. Assuming that the administrator decides to reclaim the authorization of the "Financial Management Module", the system will immediately mark the parent node authorization as "reclaiming", and automatically update the status of all sub-function authorizations such as "accounting processing", "report generation" and "tax declaration" to "waiting to enter the cooling-off period".

[0087] The system will calculate the cooling end time of each sub-function authorization based on the preset recycling cooling period parameters. During this period, the sub-function authorization is in the "cooling down" state, the original authorized individual or device has been deauthorized, and this authorization cannot be assigned to other individuals or devices for the time being, but can be assigned to the original authorized individual or device to restore it to the authorized state. For example, if the recycling cooling period is set to 7 days, the system will calculate the cooling end time after 7 days for each sub-function authorization when recycling the parent node authorization, and perform corresponding restrictions and management within these 7 days.

[0088] When the parent node authorization is valid, the system allows the distribution or refresh of the sub-function authorization under it. The administrator can choose to distribute the sub-function authorization to users or devices within the enterprise in the authorization center. For example, when the parent node authorization of the "Financial Management Module" is valid, the administrator can distribute the "Accounting Processing" sub-function authorization to employees in the Finance Department.

[0089] When the authorization is about to expire, the client will initiate a refresh request. The system will recalculate the end point of the validity period 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 end point of the validity period 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 valid, the sub-function authorization can be flexibly distributed and refreshed to meet the actual business needs of the enterprise.

[0090] In some embodiments, authorization items are divided into three levels of priority: high, medium, and low. Among them, paid permanent authorizations (such as enterprise core function modules) and authorizations bound to key business processes of the enterprise (such as equipment control rights for production lines) are set to high priority: periodic authorizations subscribed on demand (such as monthly / quarterly subscription services) and basic function authorizations for ordinary users (such as data viewing permissions) are set to medium priority: trial version or free version authorizations (such as 30-day trial functions) and non-core additional functions are set to low priority: low-priority items are eliminated first during migration.

[0091] In some embodiments, a weight value is calculated for each authorization item, and the formula design needs to satisfy: W = α / (T remaining +1)+β*F access +γ*P; Where W represents the weight value; α represents the weight coefficient of the remaining time of the cooling period; T remaining Indicates the remaining time of the cooling period, in days. The longer the remaining time, the longer the system resources are occupied, and the lower the weight should be. β indicates the access frequency weight coefficient. F access Indicates the access frequency. If the number of visits in the last N days is higher, the higher the frequency, the higher the weight should be. γ indicates the priority weight coefficient. P indicates the priority, for example: High=3, Medium=2, Low=1.

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

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

[0094] This embodiment extracts the authorization target type from the authorization item, so that the system can dynamically adapt the authorization distribution logic, avoids the deployment of multiple independent systems, and reduces the cost of managing authorization. At the same time, by recording the recovery cooling period parameters of the authorization sub-item and triggering the cooling period control when recovering, it avoids excessive authorization and balances the needs of enterprise personnel changes with the protection of the rights and interests of software providers.

[0095] See also Figure 2 This embodiment provides an authorization management system 200, including: The receiving unit 201 is used to receive an authorization file, wherein the authorization file includes at least one authorization item, wherein the authorization item includes a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field or a distributable authorization field; Verification unit 202, used to verify the legitimacy of the signature of the authorization document through the authorization center; The extraction unit 203 is used to extract the authorization target type in the authorization item if the legality of the signature of the authorization document is verified, and the authorization target type includes an enterprise, an individual or a device; An associating unit 204, configured to automatically associate the authorization item with an enterprise account if the authorization target type is an enterprise; A binding unit 205, configured to generate an unassigned authorization sub-entry if the authorization target type is an individual or a device, and bind the authorization sub-entry to a specified individual or device through a distribution interface provided by the authorization center; The recording unit 206 is used to record the distribution status, validity period and recycling cooling period parameters of the authorization sub-item, and limit the authorization reallocation conditions according to the recycling cooling period parameters.

[0096] Furthermore, the receiving unit 201 includes: A file verification subunit, used to receive multiple authorization files and verify the legality of the signature of each authorization file through the authorization center; The quantity extraction subunit is used to extract the authorized quantity in the authorization file if the legality of the signature of the authorization file is verified; The aggregation subunit is used to aggregate the authorization quantities of each extracted authorization file to generate a total authorization quota.

[0097] Furthermore, the binding unit 205 includes: An account generation subunit, used to collect the hardware ID of the device and generate a device account after the device is registered to the enterprise; An account association subunit, used to associate the device account with the currently logged-in enterprise account and bind the hardware ID to the authorization center database; The sending subunit is used to send the function Key in the authorization item to the device account.

[0098] Furthermore, the binding unit 205 includes: The authorization key generation subunit is used to generate a unique authorization key for the authorization item containing the authorization data field and directly bind it to an individual or device; The parameter recording subunit is used to record the authorization quantity, the start time and end time of the validity period, the maximum refresh time and the cooling period parameters for the authorization item containing the distributable authorization field.

[0099] Furthermore, the recording unit 206 includes: The parameter acquisition subunit is used to obtain the recycling cooling period parameters and the current time; an allocation prohibition subunit, used to calculate the cooling end time according to the recycling cooling period parameter and the current time, mark the state of the authorization sub-entry as cooling down, and prohibit its allocation to other objects; The recovery subunit is used to limit the same authorization to only be restored to the original authorized personal account or device account during the cooling-off period; The release subunit is used to reset the state of the authorization sub-entry to an unallocated state and release the authorization quota to the distributable pool when the cooling period ends.

[0100] Furthermore, the recording unit 206 further includes: A real-time monitoring subunit is used to monitor in real time the number of distributed authorizations, the number of authorizations being cooled down, and the number of authorizations waiting to be refreshed; The quota calculation subunit is used to calculate the current available authorization quota according to the total authorization quantity and the cooling excess allowance in the authorization file, as well as the number of distributed authorizations, the number of authorizations in cooling, and the number of authorizations waiting to be refreshed; The distribution rejection subunit is used to reject distribution and generate an alarm notification if the distribution request causes the total amount to exceed the currently available authorized quota.

[0101] Furthermore, it also includes: A parsing unit, used to 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; A nesting unit, used to nest and display the sub-function authorization under the parent node authorization in the authorization center according to the dependency relationship; A trigger unit, used to automatically trigger the cooling-off period process of all sub-function authorizations under the parent node when the authorization of the parent node is revoked; The refresh unit is used to allow the distribution or refresh of the sub-function authorization when the parent node authorization is valid.

[0102] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-mentioned devices and units can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0103] 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 embodiment can be implemented. The storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

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

[0105] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians 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 scope of protection of the claims of the present invention.

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

[0107] Inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of more restrictions, the elements defined by the sentence "including a..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Claims

1. An authorization management method, characterized in that: include: Receive an authorization file, the authorization file comprising at least one authorization item, the authorization item including a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field or a distributable authorization field; Verify the legitimacy of the signature of the authorization document through the authorization center; If the legality of the signature of the authorization document is verified, the authorization target type in the authorization item is extracted, and the authorization target type includes an enterprise, an individual, or a device; If the authorization target type is an enterprise, the authorization item is automatically associated with the enterprise account; If the authorization target type is an individual or a device, an unassigned authorization sub-entry is generated, and the authorization sub-entry is bound to the designated individual or device through a distribution interface provided by the authorization center; The distribution status, validity period and recycling cooling-off period parameters of the authorization sub-item are recorded, and authorization reallocation conditions are restricted according to the recycling cooling-off period parameters.

2. The authorization management method according to claim 1, characterized in that: The receiving authorization document includes: Receiving multiple authorization documents and verifying the legitimacy of the signatures of each authorization document through the authorization center; If the signature legitimacy of the authorization file is verified, extract the authorization quantity in the authorization file; Aggregate the authorization quantities of each extracted authorization file to generate the total authorization quota.

3. The authorization management method according to claim 1, characterized in that: If the authorization target type is a person or a device, generating an unassigned authorization sub-entry, and binding the authorization sub-entry to a specified person or device through a distribution interface provided by the authorization center includes: When a device is registered to an enterprise, the hardware ID of the device is collected and a device account is generated; Associating the device account with the currently logged-in enterprise account and binding the hardware ID to the authorization center database; The function key in the authorization item is sent to the device account.

4. The authorization management method according to claim 1, characterized in that: If the authorization target type is a person or a device, generating an unassigned authorization sub-entry, and binding the authorization sub-entry to a specified person or device through a distribution interface provided by the authorization center further includes: For authorization items that contain authorization data fields, a unique authorization key is generated and directly bound to an individual or device; For authorization items that contain distributable authorization fields, record the authorization quantity, start and end time of the validity period, maximum refresh time, and cooling-off period parameters.

5. The authorization management method according to claim 1, characterized in that: The recording of the distribution status, validity period and recycling cooling-off period parameters of the authorization sub-item and limiting the authorization reallocation conditions according to the recycling cooling-off period parameters include: Get the recycling cooling period parameters and current time; Calculate the cooling end time according to the recycling cooling period parameter and the current time, mark the state of the authorization sub-item as cooling down, and prohibit it from being allocated to other objects; During the cooling-off period, the same authorization is only allowed to be restored to the original authorized personal account or device account; When the cooling-off period ends, the state of the authorization sub-entry is reset to an unallocated state, and the authorization quota is released to the distributable pool.

6. The authorization management method according to claim 1, characterized in that: The recording of the distribution status, validity period and recycling cooling-off period parameters of the authorization sub-item and limiting the authorization reallocation conditions according to the recycling cooling-off period parameters also includes: Real-time monitoring of the number of distributed authorizations, the number of authorizations being cooled down, and the number of authorizations waiting to be refreshed; Calculate the current available authorization quota according to the total authorization quantity and the cooling excess allowance in the authorization file, as well as the number of distributed authorizations, the number of authorizations in cooling, and the number of authorizations waiting to be refreshed; If the distribution request causes the total to exceed the currently available authorized quota, the distribution is rejected and an alarm notification is generated.

7. The authorization management method according to claim 1, characterized in that: Also includes: Parsing the parent node ID in the authorization item, and identifying the dependency relationship between the parent node authorization and the sub-function authorization through the parent node ID; Nesting and displaying the sub-function authorization under the parent node authorization in the authorization center according to the dependency relationship; When the parent node authorization is revoked, the cooling-off period process of all its sub-function authorizations is automatically triggered; When the parent node authorization is valid, the sub-function authorization is allowed to be distributed or refreshed.

8. An authorization management system, characterized in that: include: A receiving unit, configured to receive an authorization file, wherein the authorization file includes at least one authorization item, wherein the authorization item includes a unique ID, a name, a description, an authorization target type, a function key, a parent node ID, a recycling cooling period, an authorization data field, or a distributable authorization field; A verification unit, used to verify the legitimacy of the signature of the authorization document through the authorization center; An extraction unit, configured to extract the authorization target type in the authorization item if the validity of the signature of the authorization document is verified, wherein the authorization target type includes an enterprise, an individual or a device; an associating unit, for automatically associating the authorization item with an enterprise account if the authorization target type is an enterprise; A binding unit, configured to generate an unassigned authorization sub-entry if the authorization target type is an individual or a device, and bind the authorization sub-entry to a designated individual or device through a distribution interface provided by the authorization center; The recording unit is used to record the distribution status, validity period and recycling cooling period parameters of the authorization sub-item, and limit the authorization reallocation conditions according to the recycling cooling period parameters.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the authorization management method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, enables the processor to perform the authorization management method according to any one of claims 1 to 7.

Images