Service authorization methods and related devices

Abstract

This application provides a service authorization method and related apparatus. The service authorization method includes: in response to an authorization request for a first service, determining the machine code of the first service and the service type of the first service; encrypting the machine code of the first service using a first private key set in an encryption program corresponding to the service type to obtain an authorization file; determining the validity period of the authorization file and updating the authorization file based on the validity period to obtain an updated authorization file; and authorizing the first service based on the updated authorization file. This application improves the efficiency of service authorization while ensuring the security of the authorization process.

Description

Technical Field

[0001] This application relates to information and communication technology, and more particularly to a service authorization method and related apparatus. Background Technology

[0002] Containerized deployment is gaining increasing attention due to its unique advantages. An application system typically requires the collaboration of several to dozens of applications (services). These applications are deployed on different servers using containerization, and each application requires authorization before it can be used. Summary of the Invention

[0003] This application provides a service authorization method and related apparatus that can improve the efficiency of service authorization by avoiding multiple encryptions of services based on different private keys while ensuring the security of authorization.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a service authorization method, the method comprising:

[0006] In response to an authorization request for the first service, determine the machine code of the first service and the service type of the first service;

[0007] The machine code of the first service is encrypted using the first private key set in the encryption program that corresponds to the service type, to obtain the authorization file.

[0008] Determine the validity period of the license document, and update the license document based on the validity period to obtain the updated license document;

[0009] The first service is authorized based on the updated authorization document.

[0010] This application provides a service authorization device, including:

[0011] The data acquisition module is used to respond to an authorization request for the first service, determine the machine code of the first service, and the service type of the first service;

[0012] The encryption module is used to encrypt the machine code of the first service using a first private key set in the encryption program that corresponds to the service type, in order to obtain an authorization file.

[0013] The authorization module is used to determine the validity period of the authorization file, update the authorization file based on the validity period of the authorization file to obtain an updated authorization file, and authorize the first service based on the updated authorization file.

[0014] This application provides an electronic device, including:

[0015] Memory is used to store executable instructions for a computer;

[0016] The processor, when executing computer-executable instructions stored in the memory, implements the service authorization method provided in the embodiments of this application.

[0017] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the service authorization method provided in this application when executed by a processor.

[0018] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the service authorization method provided in this application.

[0019] The embodiments of this application have the following beneficial effects:

[0020] The machine code and service type of the first service are determined. Using the first private key corresponding to the service type set in the encryption program, the machine code of the first service is encrypted to obtain the authorization file. This avoids encrypting the machine codes of different service types using only a unique private key, which increases the risk of simultaneous cracking of different service types. By determining the corresponding private key based on the service type, the security of service authorization is improved without multiple encryptions, thus increasing authorization efficiency. Furthermore, encryption using the first private key in the encryption program further enhances the security of service authorization. In addition, the validity period of the authorization file is determined and updated based on the validity period to obtain the updated authorization file. This maintains the timeliness of the authorization file and avoids potential risks from expired authorization files, further improving the security of service authorization. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the architecture of the service authorization system provided in the embodiments of this application;

[0022] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0023] Figure 3A This is a first flowchart illustrating the service authorization method provided in this application embodiment;

[0024] Figure 3BThis is a second flowchart illustrating the service authorization method provided in the embodiments of this application;

[0025] Figure 3C This is a third flowchart illustrating the service authorization method provided in this application embodiment;

[0026] Figure 3D This is a schematic diagram of the fourth process of the service authorization method provided in the embodiments of this application;

[0027] Figure 4 This is a schematic diagram of the license server network architecture provided in the embodiments of this application;

[0028] Figure 5 This is a schematic diagram of the license client network architecture provided in the embodiments of this application;

[0029] Figure 6 This is a flowchart of the document authorization process provided in an embodiment of this application.

[0030] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0033] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0034] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0035] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0036] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0037] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0038] 1) Service: The service in this application example is a service that has not yet been authorized. Only after the service is authorized can it be executed on the device where the service is located.

[0039] 2) Service type is used to identify the common attributes of different services. Each common attribute represents a category of service. Service type can be the service object (such as text or image), the difficulty level of the service (such as "difficult" or "easy"), the resource usage level (such as "high resource usage" or "low resource usage"), etc.

[0040] 3) Private key, used to encrypt the machine code of the service to ensure the integrity of the machine code and the authenticity of its source. The private key must be stored securely to prevent leakage.

[0041] 4) The authorization file is the encrypted machine code of the service, used to authorize the service so that users or systems can perform specific tasks based on the authorized service.

[0042] In related technologies, since authorized applications may belong to different products and business lines, encrypting them with only one private key reduces the security of authorization. Cracking the unique private key poses a security risk to different products and business lines. To improve the security of authorization, multiple private keys are needed to encrypt the application multiple times, which reduces the efficiency of authorization. To address the above problems, embodiments of this application provide a service authorization method, apparatus, electronic device, computer-readable storage medium, and computer program product that, while ensuring the security of authorization, avoids encrypting the service multiple times based on different private keys, thereby improving the efficiency of service authorization.

[0043] The service authorization method described in this application can be applied to various fields, such as data processing authorization, hardware boot authorization, and other related fields. In other words, the service authorization method in this application is not limited to a certain field.

[0044] The following describes exemplary applications of the electronic device provided in the embodiments of this application. The device provided in the embodiments of this application can be implemented as a terminal or as a server. The following will describe exemplary applications when the device is implemented as a server.

[0045] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the service authorization system 100 provided in the embodiments of this application. In order to support a service authorization application, the terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0046] Terminal 400 sends the machine code and service type of the service to server 200 via network 300. Server 200 determines the private key corresponding to the service type. Based on the private key, the machine code of the service is encrypted to obtain an authorization file. The authorization file is returned to terminal 400. Terminal 400 displays the authorization file through graphical interface 410 and authorizes the service based on the authorization file.

[0047] The following is an example of service authorization performed by terminal 400.

[0048] In some embodiments, the terminal 400 can independently complete the service authorization task, such as determining the machine code of the service and the service type; determining the private key corresponding to the service type; encrypting the machine code of the service based on the private key to obtain an authorization file; the terminal 400 uses the authorization file to display the authorization file through the graphical interface 410 and authorize the service based on the authorization file.

[0049] In one implementation scenario, a server or terminal can authorize a data processing program in data processing by determining the machine code and program type of the data processing program; determining the private key corresponding to the program type; encrypting the machine code of the data processing program based on the private key to obtain an authorization file; determining the validity period of the authorization file; updating the authorization file based on the validity period to obtain an updated authorization file; and authorizing the data processing program based on the updated authorization file.

[0050] In one implementation scenario, a server or terminal can authorize services for hardware during hardware startup, determine the hardware's machine code and hardware type, determine the private key corresponding to the hardware type, encrypt the hardware's machine code based on the private key to obtain an authorization file, determine the validity period of the authorization file, update the authorization file based on the validity period to obtain an updated authorization file, and authorize the hardware based on the updated authorization file.

[0051] In some embodiments, server 200 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0052] Terminal 400 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, smart voice interaction device, smart home appliance, vehicle terminal, aircraft, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0053] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Figure 2 The electronic device 500 shown can be Figure 1 The terminal 400 or server 200, and the electronic device 500 include: at least one processor 510, memory 550, and at least one network interface 520. The various components in server 200 are coupled together via a bus system 540. It is understood that the bus system 540 is used to implement communication between these components. In addition to a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 2 The general labeled all buses as Bus System 540.

[0054] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0055] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls;

[0056] In some embodiments, when the service authorization task is completed independently by the terminal 400, the server 200 provided in this application embodiment does not include the user interface 530.

[0057] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0058] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0059] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0060] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0061] The network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0062] Presentation module 553 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, a speaker, etc.) associated with user interface 530;

[0063] In some embodiments, when the service authorization task is completed independently by the terminal 400, the server 200 provided in this application embodiment may not include the presentation module 553.

[0064] The input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532; in some embodiments, when the service authorization task is performed independently by the terminal 400, the server 200 provided in this application embodiment may not include the presentation module 553.

[0065] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A service authorization device 555 stored in memory 550 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a data acquisition module 5551, an encryption module 5552, and an authorization module 5553. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0066] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the service authorization method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0067] It should be noted that, based on the understanding of the following examples of service authorization, those skilled in the art can apply the service authorization method provided in the embodiments of this application to service authorization.

[0068] See Figure 3A , Figure 3A This is a first flowchart illustrating the service authorization method provided in this application embodiment, which will be combined with... Figure 3A The steps shown will be explained below. The service authorization method provided in this application embodiment can be implemented by the server or the terminal alone, or by the server and the terminal working together. The following will be an example of the server and the terminal working together.

[0069] In step 101, in response to the authorization request for the first service, the machine code of the first service and the service type of the first service are determined.

[0070] Here, the authorization request for the first service is used to request authorization from the server for the first service. When the first service needs to perform an operation beyond its current permissions, it must request additional authorization to perform the corresponding operation. The first service is a service that has not yet been authorized. After being authorized, the first service is applied to the device to perform the service. The machine code of the first service can be the device serial number of the device applying the first service, used to identify the device of the first service. Each machine code corresponds to one device, and the device contains the environment for executing the first service so that the first service can perform the service. This application embodiment does not limit the device, and the device can be a server, terminal, etc. This application embodiment does not limit the service type of the first service. This application embodiment can classify the service based on the service object (such as text or image), the difficulty of the service (such as "difficult" or "easy"), the resource usage (such as "high resource usage" or "low resource usage"), etc., to determine the service type of the service. For example, when the service object of the service is text, the service type of the service is text processing type.

[0071] It should be noted that the service type of the first service can be obtained in the following way: cluster multiple first services to obtain the service type of each first service.

[0072] For example, based on the K-nearest neighbor clustering method, multiple first services (such as first service A and first service B) are clustered to obtain the category of each first service, and the category of each first service is determined as the service type of each first service (such as the service type of first service A being text processing type and first service B being image processing type).

[0073] In some embodiments, see Figure 3B , Figure 3B This is a second flowchart illustrating the service authorization method provided in this application embodiment. Figure 3A Before determining the machine code of the first service and the service type of the first service in step 101 shown, the following steps are performed: Figure 3B Steps 201 to 202 are then performed to determine the first service. These are explained in detail below.

[0074] In step 201, the amount of available resources is determined.

[0075] Here, the available resources are the resources that can be allocated, that is, the difference between the total resources and the allocated resources. This application embodiment does not limit the form of resources, which can be threads, computing power, memory space, etc.

[0076] For example, the difference between total resources (e.g., 1GB of space) and allocated resources (e.g., 0.2GB of space) (e.g., 0.8GB of space) is determined as the amount of available resources.

[0077] In some embodiments, Figure 3B Step 201 shown can be implemented through steps 2011 to 2013, as explained in detail below.

[0078] In step 2011, the total amount of resources is obtained, and the resource request amount corresponding to each of the multiple historical authorized services is determined.

[0079] Here, total resources refer to the sum of all resources used for a service or application; historical authorized services are services that have already been authorized, and the resource request quantity corresponding to each historical authorized service is the number of resources allocated to the historical authorized service.

[0080] For example, taking a total resource of 100G storage space as an example, the resource request amount corresponding to historical authorized service A is 5G storage space, and the resource request amount corresponding to historical authorized service B is 20G storage space.

[0081] In some embodiments, determining the resource request amount corresponding to each of the multiple historical authorized services in step 2011 can be achieved by performing the following process for each historical authorized service: receiving heartbeat information sent by the historical authorized service; determining the difference between the sending time of the heartbeat information and the sending time of the previous heartbeat information; and determining the preset resource amount as the resource request amount of the historical authorized service if the difference is greater than a time threshold.

[0082] Here, the heartbeat information sent by the historical authorization service is used to verify the online status of the historical authorization service, maintain connection, update status, etc., and a timestamp indicating the sending time is used to determine the time the message was sent. The heartbeat information sent by the historical authorization service may include the identification information of the device sending the heartbeat (such as service name, IP address, machine code), target information (i.e., the target of sending the heartbeat information, such as a server), status information (i.e., the status of the device sending the heartbeat, such as "good"), additional information (such as updated resource request volume), or token or credential updates for authentication and authorization. The historical authorization service sends heartbeat messages periodically to ensure that they are still operating normally and providing continuous service to users.

[0083] It should be noted that after sending a heartbeat message, the historical authorization service will wait for a period of time before sending the heartbeat message again; the preset resource amount (such as 0G storage space) is the amount of resources that the historical authorization service saves when the difference between the sending time of the heartbeat message sent by the historical authorization service and the sending time of the previous heartbeat message is greater than the time threshold.

[0084] In some embodiments, the following processing is performed for each historical authorization service: receiving heartbeat information sent by the historical authorization service; determining the difference between the sending time of the heartbeat information (e.g., "20140506") and the sending time of the previous heartbeat information (e.g., "20140501") (e.g., "000005", meaning the interval between the two heartbeat information is 5 days); and if the difference is greater than a time threshold (e.g., 4 days), determining a preset resource amount (e.g., 0G storage space) as the resource request amount of the historical authorization service.

[0085] In this application embodiment, when the difference between the sending time of the heartbeat information and the sending time of the previous heartbeat information is greater than a time threshold, a preset resource amount (such as 0G storage space) is determined as the resource request amount of the historical authorized service, that is, the resources of the historical authorized service are reclaimed to avoid resource loss and improve resource utilization.

[0086] In some embodiments, heartbeat information sent by a historical authorization service is received, wherein the heartbeat information carries a resource update request, which is used to update the resource request quantity based on the new resource request quantity; and if the new resource request quantity of the historical authorization service is different from the resource request quantity of the historical authorization service, the historical authorization service is reauthorized.

[0087] In step 2012, the resource request quantities corresponding to multiple historical authorized services are processed to obtain the amount of resources used.

[0088] Here, the amount of resources used is the amount of resources allocated to multiple historical authorized services. The allocated resources are used by the historical authorized services so that they can provide services based on the allocated resources and cannot be allocated to other services.

[0089] In some embodiments, step 2012 can be implemented by weighted summing of the resource request amounts corresponding to multiple historical authorized services to obtain the amount of resources used.

[0090] For example, the resource request amount corresponding to historical authorized service A is 5G of storage space, and the resource request amount corresponding to historical authorized service B is 20G of storage space. The resource request amounts corresponding to multiple historical authorized services are weighted and summed to obtain the amount of used resources (e.g., 25G of storage space).

[0091] In step 2013, the difference between the total amount of resources and the amount of resources used is determined as the amount of available resources.

[0092] Here, the available resources are the number of resources that have not yet been allocated, which can be allocated to the first service so that the first service can provide services based on the resources.

[0093] For example, the difference between the total amount of resources (e.g., 100G of storage space) and the amount of resources used (e.g., 25G of storage space) (e.g., 75G of storage space) is determined as the amount of available resources.

[0094] Through the embodiments of this application, the first service is determined based on the resource usage, avoiding resource deadlock during resource allocation due to authorization of multiple first services, thereby improving the security of service authorization and resource allocation.

[0095] In step 202, a first service is determined from multiple services based on the amount of available resources.

[0096] Here, these multiple services are candidate services, and each service can be authorized.

[0097] It should be noted that step 202 can be implemented in the following way: based on the amount of available resources, select the first service from multiple services, wherein the sum of the resource requests of the first service is less than the amount of available resources.

[0098] Through the embodiments of this application, a first service is selected from multiple services based on the amount of available resources, and the available resources are allocated to different first services to realize the resource allocation of services.

[0099] In some embodiments, see Figure 3C , Figure 3C This is a third flowchart illustrating the service authorization method provided in this application embodiment, specifically for... Figure 3B Step 202 shown can be achieved through Figure 3C Steps 2021 to 2023 will be implemented, and will be explained in detail below.

[0100] In step 2021, the service parameters corresponding to each service are determined.

[0101] The service parameters include the amount of resources requested or the time when the authorization request was sent.

[0102] Here, the resource request quantity for each service is the number of resources requested by each service, and the sending time of the authorization request is the time when the service sends the authorization request.

[0103] For example, the resource request quantity for service A is 0.85, and the resource request quantity for service B is 0.8.

[0104] Before step 2021, in response to the sending operation of the authorization request corresponding to each service, the sending time of the authorization request is recorded. In this embodiment of the application, there is no restriction on the recording location of the authorization request sending time. The recording location can be a database or a log file, so as to obtain the sending time of the authorization request for each service from the database or log file in response to the sending time query operation.

[0105] In some embodiments, when the service parameter is the sending time of the authorization request, step 2021 can be implemented in the following way: in response to the sending time query operation, a target storage space is determined, and the sending time of the authorization request corresponding to multiple services is determined from the target storage space, wherein the target storage space may be a database or log file storing the sending time of the authorization request.

[0106] For example, in response to a send time query operation, the database or log file is queried to determine the send time of the authorization request for each service.

[0107] In step 2022, multiple services are sorted based on service parameters to obtain the sorting result.

[0108] It should be noted that the embodiments of this application do not limit the method of obtaining the sorting results. The sorting results can be obtained by ascending order, descending order, etc.

[0109] For example, taking resource request quantity as the service parameter, service A corresponds to a resource request quantity (e.g., 0.85), and service B corresponds to a resource request quantity (e.g., 0.8). If the first sorting result is obtained in ascending order, the services are sorted in ascending order based on the resource request quantity (e.g., 0.85 and 0.8) to obtain the ascending sorting result (i.e., the first sorting result is [B, A]). Alternatively, if the first sorting result is obtained in descending order, the services are sorted in descending order based on the resource request quantity (e.g., 0.85 and 0.8) to obtain the descending sorting result (i.e., the first sorting result is [A, B]).

[0110] Optionally, each service can be sorted according to the sending time of the authorization request in the service parameters. For example, services can be sorted in order of sending time from oldest to newest, or in order of sending time from newest to oldest.

[0111] In step 2023, the first preset number of services in the sorting results are determined as the first service.

[0112] Among them, the sum of the resource requests of the first preset number of services is less than or equal to the available resource quantity.

[0113] For example, when the first preset quantity is 1 and the first sorting result is obtained by ascending sorting, the last 1 service (such as A) in the first sorting result (i.e., the ascending sorting result such as [B, A]) is determined as the first service; or when the first sorting result is obtained by descending sorting, the first 1 service (such as A) in the first sorting result (i.e., the descending sorting result such as [A, B]) is determined as the first service.

[0114] In some embodiments, step 2023 may be implemented as follows: when the first sorting result is obtained by ascending sorting the services based on the resource application amount, the following processing is performed on the i-th service in the first sorting result. When the sum of the resource application amounts of the first i services in the first sorting result is less than or equal to the available resource amount and the sum of the resource application amounts of the first i + 1 services in the first sorting result is greater than the available resource amount, the first i services in the first sorting result are determined as the first service, where i is a positive integer that increases sequentially, 1 ≤ i < I, and I is the number of services in the first sorting result; when the sum of the resource application amounts of the first I services in the first sorting result is less than or equal to the available resource amount, the first I services in the first sorting result are determined as the first service.

[0115] For example, given that the first sorting result is "[Service A, Service B, Service C]", where the resource application amount of Service A is 5G of storage space, the resource application amount of Service B is 25G of storage space, the resource application amount of Service C is 35G of storage space, and the available resource amount is 32G of storage space. Since the sum of the resource application amounts of the first 2 services (such as 30G of storage space) is less than or equal to the available resource amount and the sum of the resource application amounts of the first 3 services in the first sorting result (such as 65G of storage space) is greater than the available resource amount, the first 2 services (such as Service A and Service B) are determined as the first service.

[0116] In some embodiments, step 2023 may also be implemented as follows: when the first sorting result is obtained by descending sorting the services based on the resource application amount, the following processing is performed on the i-th service in the first sorting result. When the sum of the resource application amounts of the last I - i + 1 services in the first sorting result is less than or equal to the available resource amount and the sum of the resource application amounts of the last I - i services in the first sorting result is greater than the available resource amount, the last I - i + 1 services in the first sorting result are determined as the first service, where i is a positive integer that increases sequentially, 1 ≤ i < I, and I is the number of services in the first sorting result; when the sum of the resource application amounts of the first I services in the first sorting result is less than or equal to the available resource amount, the first I services in the first sorting result are determined as the first service.

[0117] For example, given the first sorting result as "[Service A, Service B, Service C]", where Service A requests 35G of storage space, Service B requests 25G of storage space, Service C requests 5G of storage space, and the available resources are 32G of storage space, since the sum of the resource requests of the latter two services (e.g., 30G of storage space) is less than or equal to the available resources, and the sum of the resource requests of the latter three services in the first sorting result (e.g., 65G of storage space) is greater than the available resources, the latter two services (e.g., Service A and Service B) are determined as the first service.

[0118] In some embodiments, after step 202, resources of services different from the first service are reclaimed.

[0119] For services that differ from the first service, their resources will be recycled.

[0120] Here, resources refer to the hardware and software resources on the server available for use by applications and users to operate the server and provide services. This application does not limit the types of resources; resources can include a central processing unit (CPU), memory, storage resources, network resources, etc. The CPU is the brain of the server, used to execute program instructions and process data; memory is a place for temporary data storage, used to speed up data access and program execution; storage resources are used for data storage, such as hard disk drives for long-term data storage and solid-state drives for faster data read and write speeds; network resources are used for data transmission, such as ports for data transmission channels for specific services. Resource reclamation refers to the process of releasing or reusing allocated resources on the server, thereby improving resource utilization efficiency and performance, and ensuring that resources are utilized to the maximum extent.

[0121] In this application embodiment, when the service parameter is the resource request quantity, a first service is selected based on the resource request quantity, and resources are allocated to services with high resource usage, thereby improving resource utilization. When the service parameter is the sending time of the authorization request, a first service is selected based on the sending time of the authorization request, and resources are allocated to services that request resources first, avoiding the use of services with low resources to wait for authorization for a long time, which would cause the service to fail to execute and thus affect the normal operation of other services, thereby improving the security of resource allocation.

[0122] In some embodiments, after the step of "determining the machine code of the first service" in step 101, the following processing is performed: if the operating system is accessed by an authorized account, an access permission table set for the operating system is determined, wherein the authorized account is the account that authorizes the first service; if the access permission table includes an authorized account, an operation is determined to encrypt the machine code of the first service using a first private key set in the encryption program that corresponds to the service type.

[0123] Here, the operating system includes hardware resources, software services, and user interface, which are used to manage computer hardware resources, provide user interface, and provide necessary support for application operation.

[0124] The operating system accessed by an authorized account is a restricted operating system. Restricted operating systems use various security mechanisms and policies to limit the access permissions of users or applications in order to protect system resources and data security.

[0125] Encryption programs are software or hardware systems used to encrypt and decrypt data, protecting data security and privacy and ensuring that only authorized users can access it. Access permission lists are lists used to define and control user or user group access permissions to specific resources; an access permission list includes at least one candidate authorized account.

[0126] In some embodiments, the above-mentioned "when the access permission table includes an authorized account, determine to perform the operation of encrypting the machine code of the first service using the first private key set in the encryption program corresponding to the service type" can be processed in the following way: query the authorized account in the access permission table, and when the similarity between any candidate authorized account in the access permission table and the authorized account is greater than the similarity threshold, determine to perform the operation of encrypting the machine code of the first service using the first private key set in the encryption program corresponding to the service type.

[0127] In step 102, the machine code of the first service is encrypted using the first private key set in the encryption program that corresponds to the service type, to obtain the authorization file.

[0128] Here, the encryption program runs on a restricted operating system. It uses a first private key set in the encryption program that corresponds to the service type to encrypt the machine code of the first service, thereby ensuring the integrity and authenticity of the machine code of the first service.

[0129] The first private key must be securely stored to prevent leakage. The authorization file is the encrypted machine code of the first service, used to authorize the first service so that users or systems can perform specific tasks based on the authorized service. This application does not limit the form of the authorization file; it can be a string, a file, etc. Furthermore, the authorization file can be used in multiple application areas such as software licensing, network access, and cloud service access.

[0130] It should be noted that each service type corresponds to a first private key. The steps to obtain the first private key corresponding to the service type can be implemented in the following way: determine the first private key corresponding to the service type from the correspondence between candidate service types and candidate first private keys.

[0131] For example, from the correspondence between candidate service types and candidate first private keys (such as candidate first private key A for candidate service type A and candidate first private key B for candidate service type B), determine the first private key (such as candidate first private key A) corresponding to the service type (such as candidate service type A).

[0132] In some embodiments, see Figure 3D , Figure 3D This is a schematic diagram of the fourth process of the service authorization method provided in the embodiments of this application. Figure 3A Before step 102 shown, execute Figure 3D Steps 301 to 303 are explained in detail below.

[0133] In step 301, the approval object information of the first service is determined according to the service type of the first service, and the first private key identifier of the first service is determined according to the approval object information.

[0134] Here, the approval object information for the first service can be determined based on the service type of the first service. This approval object is used to approve services of that service type. This embodiment of the application does not limit the approval object; it can be a robot with approval functionality. Approval refers to the process of reviewing and approving a service in service authorization.

[0135] Furthermore, the approval object information can be used to identify the approval object and also to determine the first private key identifier of the first service. It should be noted that each approval object holds its own first private key identifier. The first private key identifier typically refers to information used to uniquely identify the first private key in a public-key cryptosystem. This application embodiment does not limit the information used to uniquely identify the first private key; such information may include the digital signature of the private key, the encryption algorithm identifier, the user identifier, etc.

[0136] In some embodiments, determining the first private key identifier of the first service based on the approval object information can be achieved by: obtaining the object identifier from the approval object information, and fusing the object identifier of the approval object with the type identifier of the service type of the first service to obtain the first private key identifier of the first service.

[0137] For example, by concatenating the object identifier of the approval object (e.g., 10001) with the type identifier of the service type of the first service (e.g., 10001), the first private key identifier of the first service (e.g., 1000110001) is obtained.

[0138] Steps 302 to 303 are executed through the encryption procedure.

[0139] In step 302, the first private key library of the encryption program is queried based on the first private key identifier.

[0140] The first private key store includes the correspondence between different private key identifiers and different private keys.

[0141] Here, this application embodiment does not limit the correspondence between different private key identifiers and different private keys. The correspondence can be multiple private key identifiers corresponding to one private key, or each private key identifier corresponding to its own private key.

[0142] It should be noted that the first private key store is a data structure used to store the correspondence between private key identifiers and private keys. This application embodiment does not limit the first private key store; it can be a data structure implemented as a hash table, an array, etc., used for quickly searching, inserting, and deleting the correspondence between private key identifiers and private keys. The hash table uses a hash function to calculate an index value, mapping the input first private key identifier to its position in the hash table to access the private key. If a private key identifier matching the first private key identifier is found, the corresponding private key is retrieved.

[0143] In some embodiments, after step 302, if no private key identifier matching the first private key identifier is found, a first encrypted private key matching the first private key identifier is determined, and the password corresponding to the first encrypted private key is determined.

[0144] Here, each first encryption private key corresponds to a unique password. This application embodiment does not restrict the form of the password, which can be a fingerprint, string, etc.

[0145] It should be noted that each first private key identifier corresponds to a first encrypted private key. The above "determining the first encrypted private key corresponding to the first private key identifier" can be achieved in the following way: determine the first encrypted private key corresponding to the first private key identifier from the correspondence between candidate private key identifiers and candidate encrypted private keys.

[0146] For example, from the correspondence between candidate private key identifiers and candidate encrypted private keys (such as candidate encrypted private key A for candidate private key identifier A, and candidate encrypted private key B for candidate private key identifier B), the first encrypted private key (such as candidate encrypted private key A) corresponding to the first private key identifier (such as candidate private key identifier A) is determined.

[0147] In some embodiments, Figure 3D After step 302 shown, the following processing is performed: if no private key identifier matching the first private key identifier is found in the first private key database, then the second private key database is queried according to the first private key identifier, wherein the second private key database includes the correspondence between private key identifiers and encrypted private keys; if a private key identifier matching the first private key identifier is found in the second private key database, then the encrypted private key corresponding to the matching private key identifier in the second private key database is determined as the first encrypted private key; the first encrypted private key is decrypted to obtain the first private key.

[0148] Here, this application embodiment does not limit the correspondence between different private key identifiers and different encrypted private keys. The correspondence can be multiple private key identifiers corresponding to one encrypted private key, or each private key identifier can correspond to its own encrypted private key.

[0149] It should be noted that the second private key store includes multiple correspondences between private key identifiers and encrypted private keys. When the similarity between any private key identifier in the second private key store and the first private key identifier is greater than the similarity threshold, the arbitrary private key identifier is determined as the private key identifier corresponding to the first private key identifier. In the case of a private key identifier corresponding to the first private key identifier found, the encrypted private key corresponding to the private key identifier that matches the first private key identifier is determined as the first encrypted private key.

[0150] In some embodiments, the above-mentioned "decrypting the first encrypted private key based on the password of the first encrypted private key to obtain the first private key" can be implemented in the following way: obtaining the encryption method corresponding to the first encrypted private key, decrypting the first encrypted private key based on the encryption method and the password to obtain the first private key, wherein the encryption method is used to perform the step of encrypting the first private key based on the password to obtain the first encrypted private key.

[0151] It should be noted that the embodiments of this application do not limit the encryption method. The encryption method can be Advanced Encryption Standard (AES), Data Encryption Standard (DES), etc.

[0152] For example, the first encryption private key (e.g., "DE") is decrypted based on the encryption method (e.g., Advanced Encryption Standard) and the password (e.g., "Q1") to obtain the first private key (e.g., "SA") corresponding to the service type.

[0153] In this embodiment of the application, the security of authorization is reduced because the same first private key is used for encryption. By matching the service type with the corresponding first encryption private key, the security of authorization is ensured while avoiding multiple encryptions of the first service based on different first private keys, thus improving the efficiency of service authorization. In addition, the security of service authorization is improved by encrypting the first private key.

[0154] In step 303, if a private key identifier matching the first private key identifier is found in the first private key database, the private key corresponding to the matching private key identifier is determined as the first private key.

[0155] For example, determine the private key A of private key identifier A, determine the private key B of private key identifier B, and determine the private key (e.g., private key A) corresponding to the private key identifier that matches the first private key identifier (e.g., private key identifier A) as the private key corresponding to the first private key identifier.

[0156] In some embodiments, before "if a private key identifier matching the first private key identifier is found in the first private key library" in step 303, the following process is performed: for each private key identifier in the first private key library, if the similarity between the first private key identifier and the private key identifier in the first private key library is greater than a threshold, the private key identifier is determined to be the private key identifier matching the first private key identifier.

[0157] For example, if the similarity (e.g., 0.95) between a first private key identifier (e.g., 1000110001 used to characterize bird image processing type) and a private key identifier (e.g., 1000110002 used to characterize eagle image processing type) is greater than a similarity threshold (e.g., 0.85), the private key identifier is determined to be the private key identifier that matches the first private key identifier found in the query.

[0158] In some embodiments, Figure 3A Step 102 shown can be implemented through steps 1021 to 1023, as explained in detail below.

[0159] In step 1021, the machine code of the first service is processed to divide it into plaintext, resulting in multiple plaintexts.

[0160] Here, the plaintext partitioning of the machine code of the first service can be done by uniform plaintext partitioning, non-uniform plaintext partitioning, etc., and the machine code can be divided into different plaintexts by different plaintext partitioning methods.

[0161] It should be noted that plaintext refers to the original, unencrypted information (i.e., the machine code of the first service after plaintext division and processing), which is in a user-readable form. In the encryption process, plaintext is the input, the information that is to be protected.

[0162] For example, the machine code of the first service (e.g., a 128-byte machine code) is divided into plaintext segments of 64 bytes each, resulting in the first plaintext segment with index bytes 0 to 63 and the second plaintext segment with index bytes 64 to 127. Alternatively, the machine code of the first service (e.g., a 128-byte machine code) can be divided into plaintext segments of unequal size, resulting in the first plaintext segment with index bytes 0 to 31, the second plaintext segment with index bytes 32 to 63, and the third plaintext segment with index bytes 64 to 127.

[0163] In step 1022, each plaintext is encrypted based on the first private key to obtain ciphertext.

[0164] It's important to note that ciphertext is the result of plaintext being processed by an encryption algorithm. It's a disguised form that cannot be understood by unauthorized users. Ciphertext is the encrypted output used to securely transmit information over untrusted networks or storage media.

[0165] In some embodiments, the encryption process described in this application is not limited. The encryption process may be a weighted sum of the first private key and each plaintext, or a concatenation of the first private key and each plaintext.

[0166] In some embodiments, step 1022 can be implemented as follows: for each plaintext, perform data processing on the first private key and the plaintext to obtain an initial ciphertext; perform byte substitution processing on the initial ciphertext to obtain a substituted ciphertext; perform shift processing on the substituted ciphertext to obtain a shifted ciphertext; and perform data processing on the first private key and the shifted ciphertext to obtain the ciphertext.

[0167] In some embodiments, the data processing method for processing the first private key and plaintext is not limited in this application; the data processing may be XOR processing, weighted summation processing, etc.

[0168] Following the above embodiments, the byte substitution process of the initial ciphertext can be performed to obtain the substituted ciphertext in the following way: Perform the following processing on each ciphertext in the initial ciphertext to determine the corresponding replacement ciphertext; combine each replacement ciphertext to obtain the substituted ciphertext.

[0169] For example, determine the replacement ciphertext (e.g., "SL" for "QA"; "S5" for "Q1") for each ciphertext in the initial ciphertext (e.g., "QA Q1"); combine each replacement ciphertext (e.g., "SL" and "S5") to obtain the substitute ciphertext (e.g., "SLS5").

[0170] Following the above embodiments, the substitution ciphertext is shifted to obtain the shifted ciphertext, which can be achieved in the following way: obtain the shift sequence (e.g., "120"), where the characters in the shift sequence are the index subscripts of the substitution ciphertext block; perform the following processing for each character in the shift sequence: determine the ciphertext (e.g., "A") corresponding to the character (e.g., 1) in the substitution ciphertext (e.g., "QAW") as the shifted ciphertext; combine each shifted ciphertext to obtain the shifted ciphertext (e.g., "AWQ").

[0171] Following the above embodiments, the steps for processing the first private key and the shifted ciphertext to obtain ciphertext are similar to the steps for processing the first private key and the plaintext to obtain ciphertext, and will not be described in detail here.

[0172] In step 1023, multiple ciphertexts are combined to obtain the authorization file.

[0173] For example, multiple ciphertexts (such as "SL" and "S5") are combined to obtain an authorized file (such as "SLS5").

[0174] Through the embodiments of this application, plaintext is encrypted based on a first private key, thereby improving the security of service authorization.

[0175] In step 103, the validity period of the license document is determined, and the license document is updated based on the validity period to obtain the updated license document.

[0176] Here, the validity period of the license document refers to the continuous period during which the license is valid. The length of the validity period depends on the type of license document, the related agreement, and the policy. The validity period of the license document is for the purpose of managing and controlling the use of licenses or permissions, ensuring that users legally use the service or software within the specified time frame; the validity period of the license document is a preset time period (e.g., 30 days) starting from the time the license document was generated.

[0177] It should be noted that authorization of the first service can be granted through the authorization document within its validity period. However, authorization of the first service cannot be granted outside the validity period of the authorization document. Taking a validity period of 30 days after the generation of the authorization document as an example, authorization of the first service can be granted through the authorization document within 30 days after the generation time corresponding to the generation time of the authorization document (e.g., "20140505", where "20140506" is used to indicate the time when the authorization application request was received as May 5, 2014).

[0178] In some embodiments, Figure 3A Step 103 shown can be implemented through steps 1031 to 1033, as explained in detail below.

[0179] In step 1031, the time point at which the authorization request for the first service is received is determined.

[0180] In some embodiments, the time point at which the authorization request of the first service is received can be determined by: in response to the authorization request of the first service, determining the time point at which the authorization request is received as the receiving time point.

[0181] For example, in response to an authorization request from the first service, the time point at which the authorization request was received (e.g., "20140506", where "20140506" represents the time point at which the authorization request was received as May 6, 2014) is determined as the receipt time point.

[0182] In step 1032, if the time of receipt is not within the validity period of the authorization file, the authorization file is updated to obtain the updated authorization file.

[0183] It should be noted that if the time of receipt is not within the validity period of the authorization file, that is, the authorization file has expired, the first service cannot be authorized based on the authorization file. It is necessary to obtain the authorization file again based on the first private key and the machine code of the first service, that is, to update the authorization file and obtain the updated authorization file.

[0184] In some embodiments, updating the authorization file to obtain the updated authorization file can be achieved in the following way: in response to the authorization file update request, the machine code of the first service is encrypted based on the first private key to obtain the updated authorization file, wherein the validity period of the updated authorization file is a preset time period (e.g., 30 days) starting from the generation time point (e.g., "20140506") corresponding to the generation time point of the generated authorization file after the authorization file update request time point (e.g., "20140506").

[0185] See also Figure 3A In step 104, the first service is authorized based on the updated authorization file.

[0186] In some embodiments, step 104 can be implemented by: in response to an update operation of the authorization file, authorizing the first service based on the updated authorization file.

[0187] In some embodiments, prior to step 104, the following process is performed: if the first service meets the authorization conditions, it is determined to perform a process of authorizing the first service based on the updated authorization document; wherein the service includes the first service and the second service, and the authorization conditions include one of the following: the second service includes an authorization document; the authorization document of the second service is valid.

[0188] It should be noted that the first service and the second service are sub-services of the service. Services typically refer to those services that have not yet been authorized in permission management and access control. The first service and the second service are more specific service items or functional modules within the service. If the authorization file for the second service is not determined, authorization of the first service based on the updated authorization file will not be performed to avoid the unverified second service affecting the operation of the first service. If the authorization file for the second service is determined, even if the authorization file for the second service is not valid, the second service is a verified functional module, and authorization of the second service will not be performed. Instead, authorization of the first service based on the updated authorization file can be performed.

[0189] According to the embodiments of this application, the license file will be automatically reloaded when an update to the license file is detected.

[0190] In some embodiments, after step 105, the resource request quantity of the first service is obtained; the resources corresponding to the resource request quantity are sent to the first service so that the first service provides services based on the resources.

[0191] It should be noted that the resource request quantity refers to the number of resources requested. These resources are used to support the normal operation and functionality of the service. This application embodiment does not limit the type of resources. Resources can be computing resources (such as CPU, memory, network resources (such as specific network bandwidth and Internet Protocol (IP) addresses), storage resources (such as disk space), etc.

[0192] For example, taking the first service as an image processing service, the resource request amount (e.g., 1G computing power) of the first service (e.g., image processing service) is obtained; the resources corresponding to the resource request amount are sent to the first service so that the first service can provide services (e.g., image processing) based on the resources.

[0193] The following will describe an exemplary application of the service authorization method provided in this application embodiment in a real-world application scenario.

[0194] In related technologies, since authorized applications belong to different products and business lines, encrypting them with only one private key reduces the security of authorization. By cracking the unique private key, security risks can be posed to different products and business lines at the same time. In order to improve the security of authorization, multiple private keys are needed to encrypt the application multiple times, which reduces the authorization efficiency.

[0195] To address the aforementioned issues, this application proposes a service authorization method that improves authorization efficiency while ensuring authorization security.

[0196] For example, regarding service licensing, see Figure 4 , Figure 4 This is a schematic diagram of the network architecture of the license server 401 provided in this application embodiment. Figure 4 middle, Figure 4 This application includes multiple modules for service authorization, such as the machine code collection module 402 and the license server storage module 403. The following explains the multiple modules for service authorization provided in this application embodiment.

[0197] The machine code collection module 402 is used to obtain the machine code of the service. The process of obtaining the machine code of the service provided in the embodiments of this application will be explained below.

[0198] The system serial number / Central Processing Unit Identity Document (CPUID) of the license server host machine is used as the machine code. The system serial number / CPUID can be obtained through commands or by reading system files. To increase confidentiality and prevent users from deducing the composition of the machine code, the obtained machine code is encrypted with a private key to obtain the authorization file.

[0199] The license server storage module 403 is used to store information on the license server, such as public keys, private keys, machine codes, and license files.

[0200] The process of the service authorization method provided in the embodiments of this application will be explained below in conjunction with the above modules.

[0201] In step 1, submit an authorization request to the authorization platform.

[0202] Here, authorization application 404 includes a service name (e.g., service A), service type (e.g., v1.1), concurrency (e.g., 100), authorization validity period (e.g., permanently valid), and machine code obtained from machine code collection module 402 (e.g., device serial number 1). Authorization application 405 includes a service name (e.g., service D), service type (e.g., v1.1), concurrency (e.g., 100), authorization validity period (e.g., permanently valid), and machine code obtained from machine code collection module 402 (e.g., device serial number 2).

[0203] The authorization request 404 sends the obtained machine code to the authorization website to request authorization. When requesting authorization, the corresponding approval object is specified according to the service type required by the service (i.e., the service type corresponding to the service version number). The approval object can be a machine object that approves the service. When the authorization request (i.e., authorization request) for the service is received, the approval process is performed on the service.

[0204] In step 2, the license file is generated.

[0205] Here, in response to a request for authorization of a service, based on each approval object (e.g. Figure 4 The private keys (private_keys) of Approval Object 1 and Approval Object 2 (i.e., service objects of the approval service type) are respectively (e.g. Figure 4 The private key 1 and private key 2 (i.e., the first private key) are used to generate an authorization file for the corresponding service type (such as authorization file 1 in authorization file 406 and authorization file 2 in authorization file 407). The private key of the approval object is encrypted offline using a password (such as Advanced Encryption Standard). The resulting encrypted private key (such as...) Figure 4 The encrypted private key 1 and encrypted private key 2 (i.e., the first encrypted private key) are stored on the authorization website. In response to a service authorization request, an approval process is performed. During the approval process, the password corresponding to the approval object is obtained, and the encrypted private key of the approval object is automatically decrypted based on the password. The machine code is then encrypted using the decrypted private key to generate an authorization file. This ensures the security of the private key and simplifies the approval process for each object. Furthermore, each approved object generates an independent authorization file, which can be loaded separately, initiating service deployment and debugging.

[0206] In step 3, download the license files (such as license file 1 and license file 2) from the license platform.

[0207] Here, the license file is downloaded from the authorization platform to the license server 401.

[0208] After step 3, the license server 401 identifies changes to files in the license directory. The license directory stores indexes of licensed files on the license server, and the license server stores the licensed files themselves. Once the second approval is granted, a second licensed file is generated. After generating the second licensed file, it is uploaded to the license server. When multiple licensed files exist, each file is loaded sequentially based on its corresponding public key (public_key). The loading process involves decrypting the licensed file using the public key.

[0209] After the service updates the license file, it uploads the updated license file to the license server. The license server detects the update and automatically reloads the updated license file (without restarting the service). This loading process involves decrypting the license file to obtain the decrypted machine code and the corresponding license type. This information is used to verify the services to be authorized based on the decoded machine code and the corresponding license type. Since different license files use different public keys, and each public key corresponds to a unique private key, the impact of key leakage is greatly reduced. The private key for each approval object is encrypted and stored on the authorization website, while the public key is encrypted and stored on the license server. To ensure security, the encrypted files (i.e., the encrypted public and private keys) can be periodically updated. Furthermore, since the public and private keys have corresponding expiration dates, they can be periodically replaced.

[0210] To avoid issues such as container drift, the centralized authorization service is deployed on a separate physical machine (or the service is bound to a physical machine), see [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of the license client network architecture provided in the embodiments of this application, such as... Figure 5 As shown, the license client network architecture includes a main license server 501, an auxiliary license server 502, and license clients 503 to 505.

[0211] In this system, the primary license server (License Server Master) is a key component of the license management system, responsible for managing and distributing license files to license clients 503 to 505. The secondary license server (License Server Slave) is another component that assists the primary license server in managing and distributing license files to license clients 503 to 505. In this master-slave architecture, the secondary server takes over the license service when the primary server fails, ensuring service continuity. License clients 503 to 505 are computers or devices with software (i.e., services) installed that require access to license files to legally run the software. License clients 503 to 505 run the services hosted on them based on the license files distributed by the primary license server 501 or the secondary license server 502.

[0212] After placing the license file for each service to be licensed onto the license server, see [link to relevant documentation]. Figure 6 , Figure 6 This is a flowchart of the file authorization process provided in this application embodiment. The file authorization process will be described in detail below.

[0213] In step 601, authorization is granted for the service based on the total amount of resources.

[0214] Here, all services in the system send authorization requests to the license server. The license server is responsible for controlling the total amount of resources and authorizing each service based on resource usage. For example, if the Automatic Speech Recognition (ASR) service in the authorization file supports a total of 100 concurrent requests, and each of the four ASR services sends an authorization request to the license server, specifying 30 concurrent requests for each ASR service, then the first three requests will be authorized successfully, while the fourth request will fail due to insufficient resources.

[0215] In step 602, resource recovery takes place.

[0216] Here, each application (i.e., the first service) periodically sends heartbeats (i.e., heartbeat information) to the license server. If three heartbeats are lost, the license server will reclaim the resources requested by that node (i.e., the successfully authorized application). Therefore, after container drift, it only needs to wait for three heartbeats to re-request resources. This solution solves the problem of authorization invalidation after container drift. Container drift, in cloud computing and containerization technology, refers to the gradual changes in container configuration and state. These changes may not be monitored or recorded, causing the container's behavior to differ from the expected configuration. When container drift occurs, the license servers of each application domain lose connection, resulting in the inability to reclaim resources. This drift can be caused by various reasons, such as manual changes, incorrect updates to configuration files, differences between environments, and incorrect execution of automated scripts.

[0217] In step 603, resources are dynamically allocated.

[0218] Here, because the performance of the servers hosting different applications may vary, the processing capacity of different nodes for the same service will differ. It would be unreasonable for each application to request a fixed amount of resources (i.e., resource request quantity) based on configuration files or other methods. Requesting an average amount of resources for nodes with weaker processing capabilities would lead to resource waste, while requesting an average amount of resources for nodes with higher processing capabilities would result in idle processing capacity. When each application periodically sends a heartbeat to the license server, the requested resources can be adjusted by including the requested resource quantity. The specific adjustment method can be calculated based on the current usage (i.e., the amount of resources used), such as requesting 1.2 times the current usage; or requesting resource expansion when usage reaches 80% of the currently requested resources, and requesting resource contraction when usage reaches 60% of the currently requested resources. The license server records the resource request status of each node and dynamically reallocates resources based on the resource requests carried in the heartbeat.

[0219] In summary, this application embodiment specifies the corresponding approval object according to the required service type when applying for authorization. Each approval object uses its own private key to generate an authorization file for the corresponding service type. Each authorization file can be loaded independently. In this way, the deployment and debugging of the service can begin after one approval object is approved, without waiting for all approval objects to be approved. Each approval object has its own independent private key and public key, and the private key and public key of the approval object can be updated periodically, which greatly reduces the impact of key leakage. When the license server detects an update to the authorization file, it will automatically reload the authorization file (without restarting the service). It supports dynamic adjustment of the number of authorized resources for each node. When each application periodically sends a heartbeat to the license server, it can adjust the requested resources by carrying the requested resource number. By recording the resource request status of each node, the resources can be dynamically reallocated according to the resource requests carried in the heartbeat.

[0220] The following description continues to illustrate the exemplary structure of the service authorization device 555 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the service authorization device 555 of the memory 550 may include:

[0221] The data acquisition module 5551 is used to determine the machine code of the first service and the service type of the first service in response to an authorization request for the first service.

[0222] The encryption module 5552 is used to encrypt the machine code of the first service using the first private key set in the encryption program that corresponds to the service type, so as to obtain the authorization file.

[0223] The authorization module 5553 is used to determine the validity period of the authorization file, update the authorization file based on the validity period, and obtain the updated authorization file; based on the updated authorization file, the first service is authorized.

[0224] This application provides a computer program product, which includes computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the service authorization method described in this application.

[0225] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the service authorization method provided in this application, for example... Figures 3A to 3D The service authorization method is shown.

[0226] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0227] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0228] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0229] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0230] In summary, the embodiments of this application can determine the machine code and service type of the first service. By using a first private key corresponding to the service type set in the encryption program, the machine code of the first service is encrypted to obtain the authorization file. This avoids encrypting the machine codes of different service types using only a unique private key, which increases the risk of simultaneous cracking of services of different types. While ensuring the security of service authorization, using a method that determines the corresponding private key based on the service type eliminates the need for multiple encryptions to improve service authorization security, thereby improving authorization efficiency. Furthermore, encryption using the first private key in the encryption program further enhances the security of service authorization. In addition, determining the validity period of the authorization file and updating it based on that period to obtain an updated authorization file maintains the timeliness of the authorization file, avoiding potential risks caused by expired authorization files and improving the security of service authorization.

[0231] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A service authorization method characterized by, The method comprises: determining, in response to an authorization request for a first service, machine code of the first service and a service type of the first service; encrypting the machine code of the first service by a first private key corresponding to the service type set in an encryption program to obtain an authorization file; wherein the first private key is determined from a first private key library containing a private key and a private key identifier corresponding relationship according to a first private key identifier of the first service; the first private key identifier is determined according to the approval object information of the first service; and the approval object information is determined according to the service type of the first service; determining the validity period of the authorization file, and updating the authorization file based on the validity period of the authorization file to obtain an updated authorization file; authorizing the first service based on the updated authorization file.

2. The method of claim 1, wherein, Before the first private key corresponding to the service type set in the encryption program is used to encrypt the machine code of the first service to obtain the authorization file, the method further comprises: determining the approval object information of the first service according to the service type of the first service, and determining the first private key identifier of the first service according to the approval object information; the encryption program performs the following processing: querying the first private key library of the encryption program according to the first private key identifier, wherein the first private key library includes the corresponding relationship between the private key identifier and the private key; if a private key identifier matching the first private key identifier is queried in the first private key library, the private key corresponding to the matching private key identifier is determined as the first private key.

3. The method of claim 2, wherein, After querying the first private key library of the encryption program according to the first private key identifier, the method further comprises: if a private key identifier matching the first private key identifier is not queried in the first private key library, query the second private key library according to the first private key identifier, wherein the second private key library includes the corresponding relationship between the private key identifier and the encryption private key; if a private key identifier matching the first private key identifier is queried in the second private key library, the encryption private key corresponding to the matching private key identifier in the second private key library is determined as the first encryption private key; decrypting the first encryption private key to obtain the first private key.

4. The method of claim 2, wherein, Before the first private key identifier matching the first private key identifier is queried in the first private key library, the method further comprises: for each private key identifier in the first private key library, if the similarity between the first private key identifier and the private key identifier of the first private key library is greater than a threshold, the private key identifier is determined as the private key identifier matching the first private key identifier.

5. The method of claim 1, wherein, The service includes the first service and a second service, and before the first service is authorized based on the updated authorization file, the method further comprises: if the first service meets the authorization condition, determining to execute the process of authorizing the first service based on the updated authorization file; wherein the authorization condition includes one of the following: the second service includes an authorization file; and the authorization file of the second service is within the validity period.

6. The method of claim 1, wherein, The first service is determined by: determining an available resource amount; determining the first service from a plurality of services based on the available resource amount.

7. The method of claim 6, wherein, The determining the first service from a plurality of services based on the available resource amount comprises: determining a service parameter corresponding to each service, wherein the service parameter comprises a resource application amount or a sending time of the authorization request; sorting the plurality of services based on the service parameter to obtain a sorting result; determining a first preset number of services in the sorting result as the first service, wherein a sum of resource application amounts of the first preset number of services is less than or equal to the available resource amount. After the determining the first service from a plurality of services based on the available resource amount, the method further comprises: recovering resources of services different from the first service.

8. The method of claim 1, wherein, The encryption program runs in an operating system with restricted access; After the determining the machine code of the first service, the method further comprises: in a case where the operating system is accessed by an authorized account, determining an access permission table set for the operating system, wherein the authorized account is an account that authorizes the first service; in a case where the access permission table includes the authorized account, determining to perform an operation of encrypting the machine code of the first service by using a first private key corresponding to the service type and set in the encryption program.

9. An electronic device, comprising: The electronic device comprises: a memory for storing computer executable instructions; a processor for executing the computer executable instructions or computer programs stored in the memory to implement the service authorization method of any one of claims 1 to 8.

10. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, The computer executable instructions or computer programs are executed by the processor to implement the service authorization method of any one of claims 1 to 8.

Images