CN120200768A

CN120200768A - Authorization method, device and storage medium

Info

Publication number: CN120200768A
Application number: CN202311785099.6A
Authority: CN
Inventors: 刘恩亮; 李伟男; 郑晓
Original assignee: Hangzhou AliCloud Feitian Information Technology Co Ltd
Current assignee: Hangzhou AliCloud Feitian Information Technology Co Ltd
Priority date: 2023-12-22
Filing date: 2023-12-22
Publication date: 2025-06-24
Also published as: WO2025134027A2; WO2025134027A3

Abstract

The embodiments of the present application provide an authorization method, device, and storage medium. It is proposed to deploy an authorization server in the first cloud network. Based on this, on the one hand, the device driver component in the first cloud network can initiate an authorization request to the authorization server, and the authorization server will authenticate the instance pointed to by the authorization request, and send a verification pass message if the authentication is successful; on the other hand, after receiving the verification pass message, the device driver component will also detect whether the verification pass message is issued by the authorization server for the instance where the device driver component is currently located. In this way, it can be guaranteed based on the authorization server that the authorized instances have passed the identity authentication, and it can also be guaranteed based on the device driver component that the instance it is in is not an thief. These two aspects cooperate with each other to effectively prevent the thief from activating the device driver logic in the device driver component, thereby realizing the security management and control of the device driver component.

Description

Authorization method, device and storage medium

Technical Field

The present application relates to the field of cloud computing technologies, and in particular, to an authorization method, an authorization device, and a storage medium.

Background

In the field of cloud computing, an instance is a virtual computing server on the cloud, in which device drivers may be installed and through which the required hardware device functions are enabled. Wherein a portion of the device driver needs to be authorized for active use.

Currently, license provided by a device manufacturer is usually stored in a License server (LICENSE SERVER), after an instance is started, a device driver installed in the License server needs to initiate a License application to a designated License server, and after the License issued by the License server is acquired, the device driver can be activated to complete device enabling.

Under the License-dependent authorization scheme, the License is often stolen, and a large security risk and loss are brought.

Disclosure of Invention

Aspects of the present application provide an authorization method, apparatus, and storage medium to improve security management of device drivers.

The embodiment of the application provides an authorization method which is suitable for a device driving assembly, and comprises the following steps:

After a target instance where the target instance is located is started, if the target instance is determined to be located in a first cloud network, an authorization request is initiated to an authorization server deployed in the first cloud network, so that the authorization server is triggered to carry out identity verification on the target instance;

detecting, in the event that a verification passing message is received, whether the verification passing message is issued by the authorization server for the instance in which the device driver component is currently located;

If so, the subsequent device driver logic is activated.

The embodiment of the application also provides an authorization method, which is suitable for an authorization server deployed in the first cloud network, and comprises the following steps:

After receiving an authorization request initiated by any loaded device driving component in any target instance in a first cloud network, carrying out identity verification on the target instance;

And if the target instance is confirmed to pass the authentication, returning an authentication passing message to the device driving component so as to trigger the device driving component to activate subsequent device driving logic.

The application also provides an authorization method, which is applicable to the proxy server deployed for any other cloud network in the first cloud network, and comprises the following steps:

After receiving an authorization request initiated by any loaded device driving component in any target instance in a cloud network served by the device, carrying out identity verification on the target instance;

If the target instance is determined to pass the identity verification, forwarding the authorization request to an authorization server deployed in a first cloud network to trigger the authorization server to perform the identity verification on the proxy server and generate a verification passing message for the authorization request after the proxy server is determined to pass the identity verification;

And forwarding the verification passing message sent by the authorization server to the device driving assembly to trigger the device driving assembly to activate subsequent device driving logic.

The application also provides a computing device comprising a memory, a processor, and a communication component;

The memory is used for storing one or more computer instructions;

the processor is coupled with the memory and the communication component for executing the one or more computer instructions for performing any one of the authorization methods previously described.

Embodiments of the present application also provide a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform any one of the foregoing authorization methods.

In the embodiment of the application, a new authorization scheme is provided, and an authorization server is deployed in a first cloud network. On the basis of the method, on one hand, a device driving component in a target instance in a first cloud network can initiate an authorization request to an authorization server, the authorization server performs identity verification on the target instance and sends out a verification passing message under the condition that the identity verification passes, and on the other hand, the device driving component can detect whether the verification passing message is sent out by the authorization server aiming at the current instance of the device driving component after receiving the verification passing message. Therefore, the authorized target examples can be guaranteed to pass the identity verification based on the authorization server, and the equipment driving assembly can be used for guaranteeing that the examples are not theft users, and the two aspects are matched with each other, so that the device driving logic in the equipment driving assembly can be effectively prevented from being activated by the theft users. Accordingly, the conventional license-dependent authorization scheme is abandoned, and the target instance which fails the identity authentication is prevented from activating the device driving assembly by using the authorization server through the multi-ring identity authentication, so that the safety control of the device driving assembly is realized.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

FIG. 1 is a logical schematic diagram of a conventional license-dependent authorization scheme;

FIG. 2a is a schematic diagram of an authorization system according to an exemplary embodiment of the present application;

FIG. 2b is a schematic diagram of an alternative architecture of an authorization system according to an exemplary embodiment of the present application;

fig. 3 is a schematic diagram of authorization scheme logic in a first cloud network according to an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram of another authorization system according to an exemplary embodiment of the present application;

Fig. 5 is a schematic logic diagram of an authorization scheme in a non-first cloud network according to an exemplary embodiment of the present application;

FIG. 6 is a flowchart of an authorization method according to another exemplary embodiment of the present application;

Fig. 7 is a schematic process flow diagram of a device driving assembly in a first cloud network according to another exemplary embodiment of the present application;

FIG. 8 is a schematic diagram of a process flow of a device driver component in another cloud network other than the first cloud network according to another exemplary embodiment of the present application;

FIG. 9 is a flowchart of another authorization method according to another exemplary embodiment of the present application;

FIG. 10 is a flowchart of yet another authorization method according to another exemplary embodiment of the present application;

fig. 11 is a schematic structural diagram of a computing device according to another exemplary embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Before starting to describe the technical solutions provided by the embodiments of the present application in detail, several technical concepts related to the present application are briefly explained as follows.

The physical Host is a physical server in the cloud computing field and can provide necessary hardware resources for the created instance on the physical Host.

The example is a virtual computing server on the cloud, which comprises a vCPU, a memory, an operating system, a network, a disk and other basic components. An operating system (referred to as a Guest operating system, guest OS) may be loaded in the instance and a device driver component may be installed in the operating system of the instance.

The License server is called LICENSE SERVER in English and is used for providing License for the device driver activation process. The license is typically provided by the device vendor and stored in a license server. Different devices of different vendors need to deploy independent license servers, respectively.

The device driver component is a program component for enabling the hardware device functions, and can be installed in an operating system of an instance and used for enabling the required hardware device functions in the instance. The hardware devices refer to various external devices assembled on a physical host.

Fig. 1 is a logical schematic diagram of a conventional license-dependent authorization scheme. Referring to fig. 1, a device driver component in a target instance needs to send a license application to a license server, and the license server verifies whether hardware information provided by the device driver component is adapted to a hardware device managed by the license server, and if so, the license server issues a license to the device driver component. The device driver component may activate the device driver logic upon receipt of the license.

As mentioned in the background, this license-dependent authorization scheme often suffers from license theft. For example, a cloud vendor may apply for a license to a license server from a device driver component in a target instance a provided by a user, but a target instance B provided by the cloud vendor may misappropriate the license applied by the target instance a, and activation may be accomplished without impediment based on the misappropriated device driver component in the target instance B of the license. The inventor finds that the initial purpose of setting the authorization link is usually to secure or economically benefit, so that such theft brings relatively large security risks and losses to equipment manufacturers and cloud manufacturers.

Therefore, in this embodiment, a new authorization scheme is proposed, and the conventional license-dependent authorization manner is abandoned, so as to improve the security management and control of the device driving component.

The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

Fig. 2a is a schematic structural diagram of an authorization system according to an exemplary embodiment of the present application. As shown in fig. 2a, the system includes an authorization server and a number of physical hosts for providing hardware resources for target instances.

The authorization server in this embodiment may be deployed in the first cloud network. In this embodiment, the cloud network may be understood as a cloud computing service system formed by interoperable instances. From the perspective of physical hosts, a cloud network may include a number of physical hosts, on which instances may be created based on hardware resources provided by the physical hosts, and may be interoperable, on which cloud computing services may be implemented based on the instances. Typically, instances of different cloud networks will not interoperate, i.e., different cloud networks are typically isolated from each other. In this embodiment, the attributes of different cloud networks may not be identical, where the attributes may at least include a service mode, and based on diversity of the service mode, the cloud network in this embodiment may be implemented as a public cloud, a private cloud, a proprietary cloud, a hybrid cloud, or an edge cloud, and the type of the cloud network is not limited in this embodiment. Preferably, the first cloud network in this embodiment may be implemented as a public cloud, where the public cloud may be understood as a computing service provided by a cloud manufacturer through the public Internet, and is directed to anyone desiring to use or purchase. It may be sold free or on demand, allowing customers to pay fees based on CPU cycles, memory or bandwidth usage, etc. dimensions. The embodiment does not describe other types of cloud networks too much. It should be emphasized here that the authorization server in this embodiment is affiliated to the cloud manufacturer, and in practical application, different cloud manufacturers should use independent authorization servers.

In addition, the examples in the present embodiment may be elastic computing service (Elastic Compute Service, ECS) examples, bare metal server examples, and the like, and the types of examples are not limited in the present embodiment, and no more examples are given here. The principle of creation of the different types of instances is not described here too much.

In this embodiment, a new server may be added in the first cloud network to serve as the authorization server, and of course, processing logic corresponding to the authorization server may also be added in an existing server in the first cloud network, so as to multiplex the existing server into the authorization server. Preferably, the metadata server (METADATA SERVER) in the first cloud network may be multiplexed as an authorization server in the present embodiment. Wherein the Metadata server is a server for storing instance Metadata (Metadata) in the first cloud network. The instance Metadata (Metadata) includes description information of each target instance in the first cloud network, including, but not limited to, an instance ID, an IP address, an operating system type, an instance running state parameter, an instance identifier, and the like, which are not further illustrated herein. Wherein instance identification can be used to distinguish between different service instances.

In this embodiment, examples created on the physical host may be supported using various hardware resources on the physical host, including but not limited to a CPU, a graphics processor (Graphics Processing Unit, GPU), a data processor (Data Processing Unit, DPU), an Application SPECIFIC INTEGRATED Circuit (ASIC), a network card, etc., which are not intended to be exhaustive. In practical applications, in order to support the related functions that an instance can use hardware resources without impediments, it is also necessary to install a device driver component in the instance for using the related hardware device functions.

Fig. 2b is a schematic diagram of an alternative architecture of an authorization system according to an exemplary embodiment of the present application. Referring to FIG. 2b, a virtualization manager may be deployed in a physical host for creating and managing instances. For example, the virtualization manager may be a virtual machine monitor (Virtual Machine Monitor, VMM), also referred to as Hypervisor, or may also be QEMU, KVM, etc. Among other types of instances created and managed by the virtualization manager may include, but are not limited to, elastic computing services (Elastic Compute Service, ECS), virtual Machines (VM), containers, or the like. The virtualization manager is further configured to virtualize a hardware resource on the physical host as a virtual device and allocate the virtual device as a target instance, where the target instance may use the virtual device as if the hardware device is used, a processing task received by the virtual device is finally transferred to a corresponding hardware device for execution, and an execution result is returned to the target instance through the virtual device.

On this basis, at least two operating systems exist on the physical Host, namely a Host operating system (Host OS) and a Guest operating system (Guest OS), wherein the physical Host operating system and the Guest operating system are relatively speaking, the physical Host operating system is the operating system of the physical Host, and the Guest operating system is the operating system of the instance. In an example, a device driver component may be run in its client operating system for enabling the functionality of the required hardware device. For example, if the target instance needs to use the GPU described above, the GPU driver component may be run in the client operating system of the target instance to perform GPU driving in the target instance, thereby completing the enabling of GPU-related functions in the target instance. It should be appreciated that the relevant functions of the GPU may not be normally used in the target instance until the driver is completed. In addition, in practical applications, multiple device driving components (only one is shown in fig. 2a and 2 b) are usually loaded in the target instance to drive different devices required by the target instance.

The device driving component in this embodiment can be understood as a program component for driving the functions of the device. In this embodiment, the device driving component is modified, and in combination with the authorization server provided in this embodiment, the authorization scheme provided in this embodiment may be implemented by the interaction between the modified device driving component and the authorization server.

It should be noted that, in this embodiment, the modification of the device driver assembly mainly involves an authorization link therein, and the device driver logic that can be activated after the authorization is successful will not be interfered in this embodiment. In addition, the license server required in the conventional license-dependent authorization scheme can be no longer provided for the cloud manufacturer, so that the authorization scheme provided by the embodiment is required to perform the authorization process of the device driving component in the target instance provided by the cloud manufacturer.

On this basis, referring to fig. 2a and 2b, for the device driving component, after the instance where the device driving component is located is started, the device driving component enters the authorization link after being modified in the embodiment. Specific logic of the device driver component in the authorization link will be described below.

In this embodiment, the device driver may determine whether the target instance where the device driver is located is in the first cloud network, and for the first cloud network and other cloud networks, the device driver may use different logic to perform the authorization procedure.

Fig. 3 is a logic schematic diagram of an authorization scheme in a first cloud network according to an exemplary embodiment of the present application. Referring to fig. 2a and fig. 3, if it is determined that the instance where the device driver component is located in the first cloud network, the device driver component may initiate an authorization request to the authorization server provided in the present embodiment. For ease of explanation of the scheme, the instance in which the device driver component initiates the authorization request will be described hereinafter as the target instance. As mentioned above, the authorization server provided in this embodiment is also deployed in the first cloud network, so that an reachable path is provided between the device driver component and the authorization server for communication. It should be understood that, in this embodiment, the authorization request initiated by the device driver component is different from the license application initiated in the conventional scheme, and the authorization request is modified to be in a state agreed between the device driver component and the authorization server in terms of field setting and request format. The authorization request in this embodiment is used to trigger the processing logic on the authorization server side.

After the authorization request reaches the authorization server, the authorization server may be triggered to authenticate the instance in which the device driver component is located. Authentication in this embodiment may be understood as verifying whether an instance has the right to activate device driver logic. In this embodiment, the implementation manner adopted in the authentication process is not limited, only the instance allowed by the cloud manufacturer is guaranteed to pass the authentication, and in the subsequent embodiments, several preferred implementation manners will be provided, which will not be described in detail herein.

It should be appreciated that the authorization server in this embodiment completely discards the conventional license, but proposes to decide whether to authorize or not by means of authentication. In addition, in this embodiment, different servers are not required to be separately configured for different devices to process the authorization, but only a shared authorization server is required to be deployed in the first cloud network, so that the authorization requirements of different device driving components can be met. This can effectively reduce the waste of resources, and reduce the management and maintenance costs. In this regard, in the authorization scheme provided in this embodiment, the cloud manufacturer may be used as an application party to apply for the device driver usage rights to the device manufacturers of various devices, and on this basis, the cloud manufacturer may perform identity verification by mutually matching the authorization server and the device driver component provided in this embodiment, so as to implement security management and control of the device driver usage rights, and further avoid leakage of the device driver usage rights.

In this embodiment, for the authorization server, after receiving the foregoing authorization request, if it is determined that the target instance where the device driver component is located passes the authentication, a verification passing message may be sent as a response to the authorization request. If it is determined that the target instance in which the device driver component is located fails authentication, authorization may be denied. In practical applications, there are a variety of ways to deny authorization. For example, the authorization request may not be responded to, to show a denial. For another example, a rejection message may be issued to indicate rejection. This embodiment is not limited thereto.

Referring to fig. 3, in this embodiment, the device driver component does not directly activate subsequent device driver logic after receiving the authentication pass message. In this embodiment, it is proposed that, after receiving the authentication passing message, the device driver component needs to detect whether the authentication passing message is issued by the authorization server for the instance where the device driver component is currently located. And if the detection result is yes, the device driving component activates the subsequent device driving logic.

Here, the detection of the device driver component involves at least two aspects, namely, whether the authentication pass message is issued by the authorization server in this embodiment, and whether the authentication pass message is issued for the instance where the device driver component is currently located (after receiving the authentication pass message). In the case that the detection results of both aspects are yes, the device driver component activates the subsequent device driver logic. The possibility of use right theft by impersonating the authorized server can be effectively avoided by detecting whether the verification passing message is sent by the authorized server in the embodiment, and the possibility of use right theft by impersonating the instance can be effectively avoided by detecting whether the verification passing message is sent by the target instance where the device driving component is currently located.

For example, the target instance a is a target instance allowed by the cloud vendor 1 to activate the device driver component, and the target instance B is provided by other cloud vendors, and is not allowed by the cloud vendor 1. The device driver component in the target instance a may receive a verification passing message sent by the authorization server of the cloud vendor 1 after initiating the authorization request. If the device driver component is also loaded in target instance B and the authentication pass message received in target instance a is obtained, the device driver component in target instance B may detect that the authentication pass message is not for target instance B and thus not activate subsequent device driver logic.

It should be appreciated that this portion of the detection logic is not tamperable as it is packaged in the device driver assembly. Therefore, the pirate can detect the identity theft problem by running the device driving component provided in the embodiment, and further can not activate the subsequent device driving logic, and the pirate can not activate the subsequent device driving logic due to the fact that the pirate can not perform communication according to agreement with the authorization server in the embodiment and can not recognize the verification passing message in the embodiment through other device driving components. It can be seen that in this embodiment, the problem of theft of the usage right can be effectively avoided.

With the foregoing in mind, for the device driver component, after receiving the authentication pass message, if it is detected that the authentication pass message is not issued by the authorization server or is not for the current instance of the device driver component, then the subsequent device driver logic is not activated. In addition, if the device driver component does not receive the verification passing message after the specified waiting time, the subsequent device driver logic is not activated. The specified waiting time period may be configured as required, and the embodiment is not limited thereto, and may be configured as 100ms,2s,5s, or the like, for example. In addition, the starting point of the timing of the specified waiting time period may be the time when the authorization request is sent, so that after the authorization request is sent, the device driver component can perform timing, and after the timing reaches the specified waiting time period, if the verification passing message is not received, the subsequent device driver logic will not be activated.

As mentioned above, in this embodiment, the device driver component may include program logic for authorization (this embodiment is modified for this part of the program logic) and program logic for enabling the functions of the hardware device. Here, the subsequent device driver logic that the device driver component needs to activate refers to that portion of program logic for using the hardware device functions. It should be understood that, in this embodiment, if the verification passing message is not received after the specified waiting duration or the received verification passing message is not detected, it is indicated that the instance where the device driver component is located is not verified, and accordingly, the "program logic for monkey boxing" in the device driver component will not activate the "program logic for enabling the function of the hardware device", and therefore, the "program logic for enabling the function of the hardware device" will not be executed, and the instance where the device driver component is located will not use the function of the corresponding hardware device. The reason for setting the authorization link is also described in the foregoing, and will not be repeated here. In this way, in this embodiment, it may be ensured that the subsequent device driver logic cannot be activated in the case where the instance where the device driver component is located fails authentication on the side of the authorization server or fails authentication on the side of the instance local.

In summary, in this embodiment, a new authorization scheme is provided, and an authorization server is deployed in a first cloud network. On the basis of the method, on one hand, a device driving component in a target instance in a first cloud network can initiate an authorization request to an authorization server, the authorization server performs identity verification on the target instance and sends out a verification passing message when the identity verification passes, and on the other hand, the device driving component can detect whether the verification passing message is sent out by the authorization server for the current instance of the device driving component after receiving the verification passing message. Therefore, the authorized target examples can be guaranteed to pass the identity verification based on the authorization server, and the equipment driving assembly can be used for guaranteeing that the examples are not theft users, and the two aspects are matched with each other, so that the device driving logic in the equipment driving assembly can be effectively prevented from being activated by the theft users. Accordingly, the conventional license-dependent authorization scheme is abandoned, and the target instance which fails the identity authentication is prevented from activating the device driving assembly by using the authorization server through the multi-ring identity authentication, so that the safety control of the device driving assembly is realized. In addition, in this embodiment, the authorization server may support processing of high-concurrency authorization requests, so as to ensure authorization processing efficiency, which may effectively avoid the phenomenon that in the conventional scheme, the service process on the license server cannot process the requests in time, resulting in overtime of the requests, thereby failing in verification.

In the above or below embodiments, various implementations may be employed to support authentication operations in an authorization server. A preferred implementation is provided below.

In the preferred implementation, with reference to fig. 3, for the device driver component, an instance identifier corresponding to the target instance where the device driver component is located may be obtained, and an authorization request carrying the instance identifier is sent to the authorization server. That is, when the device driver component generates the authorization request, the device driver component can acquire the instance identifier corresponding to the target instance where the device driver component is located in real time, and carry the instance identifier in the authorization request, so that the authorization server can analyze the instance identifier from the authorization request, and the instance identifier can be used as the basis of identity verification.

For the authorization server, after receiving the authorization request, if the instance identifier is queried from the instance metadata of the first cloud network, a verification passing message may be generated as a response to the authorization request. In response to the aforementioned optional deployment manner of the authorization server, if the metadata server in the first cloud network is multiplexed to be the authorization server in this embodiment, the authorization server may query the instance metadata stored in the authorization server itself, while in other deployment manners, the authorization server may communicate with the metadata server in the first cloud network to implement querying of the instance metadata of the first cloud network. In either implementation, the authorization server may determine, based on the instance metadata and the instance identifier of the first cloud network, whether the instance in which the device driver component is located is a target instance already registered in the first cloud network, and if so, may identify that the instance in which the device driver component is located passes the authentication.

In the preferred implementation manner, the registered target instance in the first cloud network provided by the cloud manufacturer can pass the authentication at the authorization server side, while the target instances provided by other cloud manufacturers cannot pass the authentication at the authorization server side, so that the authorization range can be limited to the target instance provided by the cloud manufacturer in the first cloud network scene, and the leakage of the device driving right applied by the cloud manufacturer is avoided.

It should be appreciated that the above-described implementations are merely exemplary, and that other implementations may be employed by the present embodiment to support authentication operations on the authorization server side. For example, since the device driver component is in the target instance, the authorization request sent from the device driver component uses the instance in which the authorization request is located as a communication outlet, and at the network communication level, the authorization server can sense the source address information of the received authorization request, that is, can sense which target instance the authorization request comes from. Based on the identification information, such as the IP address of the target instance where the device driving component is located, can be read from the appointed field of the authorization request by the authorization server as the basis of the identity verification, and whether the corresponding target instance passes the identity verification can be determined by inquiring whether the identification information exists in the instance metadata of the first cloud network. The present embodiment is not limited thereto.

In addition, in the foregoing implementations with instance metadata of the first cloud network as the authentication reference, the scope of authorization may be limited to all instances provided by the cloud vendor in its first cloud network. This is but one alternative, and the scope of authorization in this embodiment may also define part of the instances provided by the cloud vendor in its first cloud network. For example, an authorization list may be configured for a cloud vendor, an authorization server may perform identity verification based on the authorization list, and instances that are within the authorization list will pass the identity verification, while target instances that are not within the authorization list cannot pass the identity verification. The authorization list can be customized as required and supports dynamic updating, so that the authorization range can be flexibly set for cloud manufacturers by configuring the authorization list.

In summary, in this embodiment, various implementation manners for supporting the authentication operation of the authorization server are provided, and through the mutual coordination between the device driver component and the authorization server, it is ensured that the authentication passing message sent by the authorization server can be obtained only when the authorization request sent by the device driver component in the target instance in the authorization range allowed by the cloud manufacturer. Thus, in this embodiment, the authorization server essentially issues a verification passing message for the target instance, which enables the verification passing message to have identity properties, so that security management of the device driver component can be ensured based on the verification passing message.

In the above or below embodiments, various implementations may be employed to support the detection of received authentication pass messages by the device driver component. A preferred implementation is provided below.

Referring to FIG. 3, in the preferred implementation, the authentication-passing message may be generated by encrypting the instance identification of the authenticated target instance with its own private key to the authorization server. In the implementation manner of accepting the authorization request provided in the foregoing embodiment, if the authorization request carries an instance identifier, the authorization server may encrypt the instance identifier carried in the authorization request with its own private key to generate a verification passing message. If the authorization request does not carry the instance identifier, the authorization server can query the instance identifier corresponding to the corresponding target instance based on the information of other identifier types acquired by the authorization server, and then encrypt the queried instance identifier by using the private key of the authorization server to generate the verification passing message. This ensures that the authentication pass message issued by the authorization server has the identity properties mentioned above.

On the basis, after receiving the verification passing message, the device driving component can decrypt the received verification passing message by utilizing a public key corresponding to the authorization server, and if the decryption is successful and the instance identifier decrypted from the verification passing message is matched with the current instance of the device driving component, the device driving component can determine that the verification passing message is sent by the authorization server for the current instance of the device driving component.

In this preferred implementation, source verification of the verification-passed message is supported by asymmetric encryption techniques to avoid the possibility of theft of usage rights by impersonating an authorized server. In practical application, after receiving the verification passing message sent by the authorization server, the device driver component may send the verification passing message and the public key corresponding to the authorization server to the OpenSSL module, so as to verify the identity of the authorization server by using the OpenSSL module, and if the verification result returned by the OpenSSL is successful, it may be determined that the verification passing message is decrypted successfully. Where OpenSSL is a separate secure software library that provides powerful security authentication and the like, it should be understood that in this preferred implementation, other security authentication techniques may also be employed to implement authentication of the authorization server, and is not limited to OpenSSL, and is not further illustrated herein. And the instance identifier of the target instance which passes the identity verification is directly carried in the verification passing message, so that the identity attribute of the verification passing message can be effectively and definitely verified, and the instance identifier in the verification passing message can not be tampered, thereby providing a reliable detection basis for the detection process in the device driving assembly.

Further, in the preferred implementation, the device driver component may obtain an instance identifier of the instance in which the device driver component is currently located if the decrypting is successful, and determine that the instance identifier decrypted from the verifying passing message matches the instance in which the device driver component is currently located if the instance identifier decrypted from the verifying passing message matches the instance identifier of the instance in which the device driver component is currently located.

Thus, in this preferred implementation, the device driver component may complete the verification of the origin of the verification passing message and the re-authentication of the currently located target instance.

It should be appreciated that the above-described implementations are merely exemplary, and that other implementations may be employed in the present embodiment to support detection of received authentication pass messages by the device driver component. For example, the authorization server may carry in the authentication pass message other identification class information such as an IP address, which is capable of characterizing the identity of the corresponding target instance, and accordingly, the device driver component may complete re-authentication of the target instance in which it is located according to the identification class information. No further examples of implementation are presented here.

In summary, in this embodiment, various implementations are provided to support the device driver component to detect the received authentication passing message, so that the device driver component can accurately detect whether the authentication passing message originates from the authorization server provided in this embodiment, and accurately detect whether the current instance in which the device driver component is located has the right to use the authentication passing message, thereby effectively avoiding the problem of theft of the right to use of the device driver.

Fig. 4 is a schematic structural diagram of another authorization system according to an exemplary embodiment of the present application, and referring to fig. 4, a cloud manufacturer may provide a first cloud network, and may also provide various other cloud networks. The embodiment further provides a solution for carrying out safety control on the device driving assembly in other cloud networks. With the foregoing in mind, it is preferable that the first cloud network in this embodiment may be implemented as a public cloud, and the other networks may be implemented as private clouds, proprietary clouds, hybrid clouds, edge clouds, etc., but it should be understood that this is only an example, and the types of the first cloud network and the other cloud networks in this embodiment are not limited thereto.

Referring to fig. 4, based on the system structure shown in fig. 1, this embodiment proposes that, in a first cloud network, proxy servers are deployed for other cloud networks provided by cloud vendors, respectively. The processing logic in the proxy server proposed in the present embodiment is explained below.

If the device driving component determines that the instance is located in the second cloud network outside the first cloud network, the device driving component does not initiate an authorization request to the authorization server, but initiates the authorization request to a proxy server deployed in the non-first cloud network. The second cloud network here may be any one of the other networks than the first cloud network. It should be understood that, in view of security, as mentioned above, the instances of different cloud networks will not generally be interconnected, so that the instances in the cloud networks do not have authority to initiate interaction with the authorization server in the first cloud network, and in this embodiment, without violating the security principle, it is proposed to deploy proxy servers in the first cloud network for other cloud networks respectively, and use the proxy servers to support authentication requests sent in the served cloud networks for authentication, so that authentication of the target instance can be completed inside the other cloud networks. In this embodiment, a network channel for accessing the cloud network served by the proxy server may be configured for the proxy server, so as to ensure that no barrier interaction can be performed between the proxy server and a device driver component in the cloud network served by the proxy server.

Based on this, in this embodiment, for the proxy server, after receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network served by the proxy server, the proxy server may perform identity verification on the target instance.

Fig. 5 is a schematic logic diagram of an authorization scheme in a network other than the first cloud network according to an exemplary embodiment of the present application. Referring to fig. 5, in this embodiment, similar to the authentication logic in the authorization server, the proxy server may store instance metadata or a preset authorization list in the cloud network served by the proxy server to define an authorization scope in the cloud network served by the proxy server, and further may perform an authentication operation on an authorization request occurring in the cloud network served by the proxy server with respect to the authorization scope, so as to guarantee security management and control of the device driver component in the cloud network served by the proxy server, and avoid leakage of the device driver usage right. Authentication logic in the proxy server is not described in further detail herein. It should be noted that the proxy server only needs to be responsible for performing the authentication operation on the authorization request that occurs in the cloud network that it serves.

In addition, in this embodiment, the proxy server may forward the authorization request to the aforementioned authorization server after determining that the target instance to which the authorization request is directed passes the authentication. In this case, the authorization server no longer needs to be responsible for authenticating the target instance, but needs to be responsible for authenticating the proxy server. Therefore, in this embodiment, the authorization server may perform authentication on the proxy server after receiving the authorization request forwarded by the proxy server, and generate an authentication passing message as a response to the authorization request after determining that the proxy server passes the authentication. In the authentication process of the proxy server by the authorization server, referring to fig. 5, the proxy server may be determined to pass the authentication based on the proxy server metadata or a preset proxy server list, etc. as the authorization scope, and when the proxy server is determined to be located in the authorization scope.

The manner in which the authorization server generates the verification passing message may be consistent with the first cloud network case, and will not be repeated here.

The authorization server may send the generated authentication pass message back to the proxy server, which in turn forwards the authentication pass message to the device driver component that issued the authorization request. It should be understood that the authorization server and the proxy server are located in the same cloud network, so that both parties can communicate without any obstacle, and in this embodiment, a network channel for accessing the cloud network served by the proxy server is configured for the proxy server, so that the proxy server and each instance in the cloud network served by the proxy server can communicate without any obstacle, which can ensure that the verification can successfully reach the device driver component in the second cloud network through the message.

That is, for the authorization request that occurs in the second cloud network, the authentication passing message is still sent by the authorization server in this embodiment. Moreover, the authorization server needs to send the authentication passing message after determining that the proxy server passes the authentication, which can ensure that the proxy server approved by the cloud manufacturer, but not other impersonated proxy servers, are processed in the second cloud network, thereby effectively avoiding the possibility of use right embezzlement by impersonating the proxy server.

In addition, in this embodiment, if it is determined that the target instance to which the authorization request is directed does not pass the authentication, the proxy server may reject the authorization. Similarly, for an authorization server, if it is determined that the proxy server fails authentication, authorization may also be denied. Thus, in the second cloud network, authorization requests that occur in target instances outside the scope of authorization configured in the proxy server will be denied at the proxy server level. Since the proxy server does not have the capability of sending the authentication passing message, the proxy server cannot generate the authentication passing message without the authorization server being aware, and the proxy server is refused at the authorization server level for the authorization request which is not forwarded by the proxy server allowed by the cloud manufacturer.

Accordingly, in other cloud networks except the first cloud network, after the device driving component sends out the authorization request, if the target instance where the device driving component is located can pass the identity verification in the proxy server, the proxy server can also pass the identity verification in the authorization server, and then the device driving component can successfully receive the verification passing message. After this, the device driver component may continue to detect whether the verification pass message was issued by the authorization server for the instance in which the device driver component is currently located, and in the event that the detection result is yes, activate subsequent device driver logic. This part of logic is identical to the processing logic in the first cloud network, and will not be repeated here.

Also, in other cloud networks than the first cloud network, if no authentication pass message is received after a specified waiting period or the received authentication pass message is not issued by the authorization server for the instance in which the device driver component is currently located, the device driver component will not activate subsequent device driver logic. This part of logic is also consistent with the processing logic in the first cloud network, and will not be repeated here.

In summary, in this embodiment, proxy servers (equivalent to one layer of authorization) respectively deployed in other cloud networks provided by a cloud vendor in the first cloud network may be managed by an authorization server, and then the proxy servers are responsible for authentication work (equivalent to another layer of authorization) in the served cloud network.

Fig. 6 is a flowchart of an authorization method according to another exemplary embodiment of the present application, which may be applied to a device driver assembly, and referring to fig. 6, the method may include:

step 600, after a target instance where the target instance is located is started, if the target instance is determined to be located in a first cloud network, an authorization request is initiated to an authorization server deployed in the first cloud network, so as to trigger the authorization server to perform identity verification on the target instance;

Step 601, detecting whether the verification passing message is sent by the authorization server for the current instance of the device driving component when the verification passing message is received;

step 602, if yes, activating subsequent device driver logic.

Fig. 7 is a schematic process flow diagram of a device driving assembly in a first cloud network according to another exemplary embodiment of the present application. Referring to fig. 7, in an alternative embodiment, the step of initiating an authorization request to an authorization server deployed in a first cloud network may include:

Acquiring an instance identifier corresponding to the target instance;

And sending an authorization request carrying the instance identifier to the authorization server to trigger the authorization server to generate a verification passing message as a response to the authorization request under the condition that the instance identifier is queried from the instance metadata of the first cloud network.

Referring to fig. 7, in an alternative embodiment, step 601 may include:

Decrypting the received verification passing message by utilizing the public key corresponding to the authorization server;

If decryption is successful and the instance identifier decrypted from the verification passing message is matched with the current instance of the device driving component, determining that the verification passing message is sent by the authorization server for the current instance of the device driving component;

wherein the authorization server encrypts an instance identifier corresponding to the instance that has passed the authentication by using its own private key to generate an authentication passing message.

Referring to fig. 7, in an alternative embodiment, the method may further comprise:

under the condition that decryption is successful, acquiring an instance identifier of the current instance of the equipment driving assembly;

and if the instance identifier decrypted from the verification passing message is consistent with the instance identifier of the current instance of the device driving component, determining that the instance identifier decrypted from the verification passing message is matched with the current instance of the device driving component.

Fig. 8 is a schematic process flow diagram of a device driver component according to another exemplary embodiment of the present application in a cloud network other than the first cloud network. Referring to fig. 8, in an alternative embodiment, proxy servers are respectively deployed in the first cloud network for other cloud networks, and the method further includes:

if the target instance where the proxy server is located is determined to be located in a second cloud network outside the first cloud network, the proxy server corresponding to the second cloud network is initiated with the authorization request, so that the proxy server is triggered to carry out identity verification on the target instance;

And the proxy server forwards the authorization request to the authorization server under the condition that the target instance is confirmed to pass the authentication, so as to trigger the authorization server to carry out the authentication on the proxy server, and returns an authentication passing message to the proxy server after the proxy server is confirmed to pass the authentication, so that the proxy server forwards the authentication passing message to the device driving component.

In an optional embodiment, the proxy server records instance metadata corresponding to the cloud network served by the proxy server, and the proxy server determines that the target instance passes identity verification when the instance identifier is found from the instance metadata recorded by the proxy server.

Referring to fig. 7 and 8, in an alternative embodiment, the method may further include:

If no authentication pass message is received after a specified waiting period or the received authentication pass message is not issued by the authorization server for the current instance in which the device driver component is located, no further subsequent device driver logic is activated.

It should be noted that, for the technical details of the embodiments of the authorization method, reference may be made to the descriptions of the device driving components in the embodiments of the system described above, which are not repeated herein for the sake of brevity, but should not cause a loss of the protection scope of the present application.

Fig. 9 is a flowchart of another authorization method according to another exemplary embodiment of the present application, where the method may be applicable to an authorization server deployed in a first cloud network, and referring to fig. 9, the method may include:

Step 900, after receiving an authorization request initiated by any loaded device driving component in any target instance in a first cloud network, performing identity verification on the target instance;

Step 901, if it is determined that the target instance passes the authentication, an authentication passing message is returned to the device driver component to trigger the device driver component to continue to operate the subsequent device driver logic.

In an alternative embodiment, the step of returning a verification pass message to the device driver component may specifically include:

encrypting an instance identifier carried in the authorization request by using a private key of the self to generate the verification passing message;

the authentication pass message is sent to the device driver component.

In an optional embodiment, proxy servers are deployed in the first cloud network for other cloud networks, and the method may further include:

after receiving an authorization request forwarded by any proxy server, carrying out identity verification on the proxy server;

if the proxy server passes the authentication, generating an authentication passing message aiming at the authorization request;

And sending the verification passing message to the proxy server to trigger the proxy server to forward the verification passing message to a device driving component which initiates the authorization request in a cloud network served by the proxy server.

It should be noted that, for the technical details of the embodiments of the authorization method, reference may be made to the description of the authorization server in the foregoing system embodiments, which is omitted for brevity and not to be repeated herein, but this should not cause a loss of the protection scope of the present application.

Fig. 10 is a flowchart of yet another authorization method according to another exemplary embodiment of the present application, which may be applicable to a proxy server deployed in a first cloud network for any other cloud network, and referring to fig. 10, the method may include:

step 100, after receiving an authorization request initiated by any loaded device driving component in any target instance in a cloud network served by the device, performing identity verification on the target instance;

step 101, if the target instance is determined to pass the identity verification, forwarding the authorization request to an authorization server deployed in a first cloud network, so as to trigger the authorization server to perform the identity verification on the proxy server, and generating a verification passing message for the authorization request after determining that the proxy server passes the identity verification;

Step 102, forwarding the verification passing message sent by the authorization server to the device driving component to trigger the device driving component to activate subsequent device driving logic.

In an alternative embodiment, the method may further comprise:

If the target instance is determined to not pass the authentication, rejecting the authorization request.

It should be noted that, for the technical details of the embodiments of the authorization method, reference may be made to the description of the proxy server in the foregoing system embodiments, which is omitted for brevity and not to be repeated herein, but this should not cause a loss of the protection scope of the present application.

In addition, in some of the above-described methods embodiments and some of the flows depicted in the drawings, a plurality of operations occurring in a particular order are included, but it should be understood that the operations may be performed out of order or performed in parallel, the order of operations being indicated as 601, 602, etc., merely for distinguishing between the various operations, the order of the operations itself not representing any order of execution. In addition, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel.

Fig. 11 is a schematic structural diagram of a computing device according to another exemplary embodiment of the present application. As shown in fig. 11, the computing device includes a memory 110, a processor 111, and a communication component 112. A processor 111 coupled to the memory 110 and the communication component 112 for executing the computer programs in the memory 110.

In some inventive concepts, the computing device shown in fig. 11 may act as a physical host in a first cloud network or other cloud network. In this case, one or more target instances may be built in the computing device, where the required device driver components are loaded according to the hardware device usage requirements. Accordingly, the processor 111 may execute computer programs in the memory 110 to perform the processing logic associated with the device driver components in the system embodiments described above. For the sake of space, the description is omitted.

In other inventive concepts, the computing device shown in fig. 11 may act as an authorization server deployed in a first cloud network. In this case, the processor 111 may execute a computer program in the memory 110 to perform the processing logic associated with the authorization server in the previous system embodiment. For the sake of space, the description is omitted.

In still other inventive concepts, the computing device shown in fig. 11 may also act as a proxy server in the first cloud network deployed for any other cloud network. In this case, the processor 111 may execute a computer program in the memory 110 to perform the processing logic associated with the proxy server in the previous system embodiment. For the sake of space, the description is omitted.

Further, as shown in FIG. 11, the computing device also includes other components, such as a power supply component 113. Only some of the components are schematically shown in fig. 11, which does not mean that the computing device only includes the components shown in fig. 11.

Accordingly, the present application also provides a computer-readable storage medium storing a computer program, which when executed is capable of implementing the steps in the above-described method embodiments.

The memory of FIG. 11 described above is used to store a computer program and may be configured to store various other data to support operations on a computing platform. Examples of such data include instructions for any application or method operating on a computing platform, contact data, phonebook data, messages, pictures, videos, and the like. The memory may be implemented by any type of volatile or nonvolatile memory device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

The communication assembly of fig. 11 is configured to facilitate wired or wireless communication between the device in which the communication assembly is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as a mobile communication network of WiFi,2G, 3G, 4G/LTE, 5G, etc., or a combination thereof. In one exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further comprises a Near Field Communication (NFC) module to facilitate short range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.

The power supply assembly shown in fig. 11 provides power to various components of the device in which the power supply assembly is located. The power components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the devices in which the power components are located.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method of authorization adapted for use with a device driver assembly, the method comprising:

If so, the subsequent device driver logic is activated.

2. The method of claim 1, wherein initiating an authorization request to an authorization server deployed in the first cloud network comprises:

Acquiring an instance identifier corresponding to the target instance;

3. The method of claim 1, wherein detecting whether the authentication pass message is issued by the authorization server for the instance in which the device driver component is currently located comprises:

4. A method according to claim 3, further comprising:

5. The method of claim 1, wherein proxy servers are also deployed in the first cloud network for each of the other cloud networks, the method further comprising:

6. The method according to claim 5, wherein instance metadata corresponding to a cloud network served by the proxy server is recorded in the proxy server, and the proxy server determines that the target instance passes authentication if the instance identifier is found from the instance metadata recorded by the proxy server.

7. The method as recited in claim 1, further comprising:

8. An authorization method, suitable for an authorization server deployed in a first cloud network, comprising:

9. The method of claim 8, wherein returning a verification pass message to the device driver component comprises:

Encrypting an instance identifier corresponding to the target instance by using a private key of the device so as to generate the verification passing message;

the authentication pass message is sent to the device driver component.

10. The method of claim 8, wherein proxy servers are also deployed in the first cloud network for each of the other cloud networks, the method further comprising:

If the proxy server passes the authentication, generating an authentication passing message for the authorization request;

Sending the verification passing message to the proxy server to trigger the proxy server to forward the verification passing message to a device driving component which initiates the authorization request in a cloud network served by the proxy server;

the proxy server forwards the authorization request to the authorization server after determining that the instance to which the authorization request is directed passes identity verification.

11. An authorization method adapted for proxy servers deployed in a first cloud network for any other cloud network, the method comprising:

If the target instance is determined to pass the identity verification, forwarding the authorization request to an authorization server deployed in the first cloud network to trigger the authorization server to perform the identity verification on the proxy server and generate a verification passing message for the authorization request after the proxy server is determined to pass the identity verification;

12. A computing device comprising a memory, a processor, and a communication component;

The memory is used for storing one or more computer instructions;

the processor is coupled to the memory and the communication component for executing the one or more computer instructions for performing the authorization method of any of claims 1-11.

13. A computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the authorization method of any of claims 1-11.