WO2022121461A1 - 一种云平台资源访问控制的令牌构造方法、装置及设备 - Google Patents

一种云平台资源访问控制的令牌构造方法、装置及设备 Download PDF

Info

Publication number
WO2022121461A1
WO2022121461A1 PCT/CN2021/121214 CN2021121214W WO2022121461A1 WO 2022121461 A1 WO2022121461 A1 WO 2022121461A1 CN 2021121214 W CN2021121214 W CN 2021121214W WO 2022121461 A1 WO2022121461 A1 WO 2022121461A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
user
leaf node
information
merkle tree
Prior art date
Application number
PCT/CN2021/121214
Other languages
English (en)
French (fr)
Inventor
麻付强
Original Assignee
苏州浪潮智能科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 苏州浪潮智能科技有限公司 filed Critical 苏州浪潮智能科技有限公司
Priority to US18/246,822 priority Critical patent/US20230370265A1/en
Publication of WO2022121461A1 publication Critical patent/WO2022121461A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present application relates to the technical field of cloud platforms, and in particular, to a token construction method, device and device for cloud platform resource access control.
  • Openstack As an open source cloud computing platform for infrastructure services, Openstack is widely used in various cloud computing fields with its advantages of compatibility, scalability, and flexibility.
  • Keystone is the identity authentication component of Openstack. Keystone provides unified authorization and identity authentication services for Openstack. It is mainly responsible for user information management and authentication services for each service. Other core components need to register their services in Keystone. When users interact with services, they need to use Keystone for identity authentication. The security of this component mainly lies in the credibility of authentication, authorization token management and secure communication.
  • a token Token
  • the Token in Keystone is a string, each Token has a specific access permission scope, and the Token can determine the resources that the user can access. If the user uses the username/password to access the OpenStack API (Application Program Interface) every time, it is easy to leak user information and bring security risks. Therefore, OpenStack requires users to obtain a Token before accessing its API, and then the Token is used as the User credentials to access again.
  • OpenStack Application Program Interface
  • UUID Token In the prior art, there are four types of Tokens used by Keystone: UUID Token, PKI Token, PKIz Token and Fernet Token. Among them, UUID Token is simple and easy to use, but does not carry other information. After receiving the Token, the OpenStack API needs to interact with Keystone to verify whether the Token is valid.
  • Performance problems are prone to occur under high concurrency; although PKI Token supports other service components in the Local authentication, but requires CA (Certification Authority) to issue a certificate, the Token is too large to cause the request to fail; although PKIZ Token compresses the Token, it also has the disadvantage that the Token is too large; Fernet Token is a lightweight security message format, Although it avoids the problem of too large PKI Token, the symmetric encryption key used to encrypt the Token needs to be distributed, rotated and periodically replaced, and the Fernet Token must be verified by Keystone, which is prone to performance problems under high concurrency.
  • the purpose of this application is to provide a token construction method, device and equipment for cloud platform resource access control, so as to realize the local authentication of cloud platform API and improve the scalability of identity authentication service on the basis of ensuring the security of identity authentication .
  • the present application provides a token construction method for cloud platform resource access control, including:
  • an authorization metadata token corresponding to the authentication user is generated; wherein, the authorization metadata token includes a leaf node of Merkle tree data corresponding to the authentication user, and the leaf node Including the corresponding hash value of each access resource authorization information;
  • the user token is encrypted using the user public key, an encrypted user token is generated, and the encrypted user token and the digital certificate are sent to the client of the authenticated user, so that the client A challenge response for resource access using the authorization metadata token.
  • the leaf node includes: each endpoint information in the cloud platform, the user information, the item information, the role information, and the hash value corresponding to the authorization time information.
  • each of the endpoint information, the user information, the item information, the role information, and the authorization time information includes respective random numbers.
  • the Merkle tree data is a complete binary tree structure with an even number of leaf nodes.
  • the token application request includes a user name and a password
  • generating an authorization metadata token corresponding to the authenticated user according to the token application request including:
  • the user corresponding to the token application request is determined as the authentication user, and an authorization metadata token corresponding to the authentication user is generated.
  • the digitally signing the metadata token with a digital certificate to generate a user token includes:
  • the authorization metadata token includes target data in the Merkle tree data; the target data only includes the leaf node, and the target data is less than or equal to 1KB.
  • the method further includes:
  • the Merkle tree data generate Merkle tree port data corresponding to each target exposed port; wherein, the target exposed port is an exposed port in the cloud platform that the authenticated user is authorized to access;
  • the Merkle tree port data is sent to the respective corresponding target exposed ports for storage.
  • the Merkle tree port data includes metadata corresponding to the target leaf node and non-target leaf nodes, the non-target leaf node.
  • the leaf node and the target leaf node form all the leaf nodes of the Merkle tree data, and the non-target leaf node corresponds to the port information other than the corresponding target exposed port in the Merkle tree data.
  • the metadata is the data before hash encryption of the target leaf node in the Merkle tree data.
  • the method further includes:
  • the access exposed port is an exposed port that receives the service request
  • the authenticated user If the authenticated user is valid, generate and send challenge information to the client according to the stored target Merkle tree port data; wherein, the target Merkle tree port data is all the data stored in the access exposed port. Merkle tree port data corresponding to the authentication user;
  • the verifying whether the user is valid according to the service request includes:
  • the step of generating and sending challenge information to the client according to the stored target Merkle tree port data is performed.
  • generating and sending challenge information to the client according to the stored target Merkle tree port data including:
  • the target Merkle tree port data randomly select a challenge leaf node, generate challenge information corresponding to the challenge leaf node, and send the challenge information to the client; wherein, the challenge leaf node is all Describe any leaf node of Merkle tree data.
  • the token response information returned by the client according to the target Merkle tree port data Validate including:
  • the response leaf node is any leaf node of the Merkle tree data
  • the response leaf node Corresponding to the challenge leaf node
  • the bypass hash value is the hash value used to calculate the Merkle tree data of the root node corresponding to the response leaf node
  • the bypass hash value is The hash value includes the hash value of the leaf node that is not the Merkle tree data
  • the step of providing a service to the client is performed.
  • the method before calculating the response root node according to the response leaf node and the bypass hash value in the token response information, the method further includes:
  • the client searches for the response leaf node from the authorization metadata token according to the received challenge information
  • the token response information is generated and sent to the access exposure port according to the response leaf node and the bypass hash value.
  • the present application also provides a token construction device for cloud platform resource access control, including:
  • an acquisition module configured to acquire a token application request of an authenticated user; wherein the authenticated user is a user whose identity authentication is successful, and the token application request includes the user's public key;
  • a generating module configured to generate an authorization metadata token corresponding to the authentication user according to the token application request; wherein the authorization metadata token includes a leaf node of the Merkle tree data corresponding to the authentication user , the leaf node includes the corresponding hash value of each access resource authorization information;
  • a signature module for digitally signing the authorization metadata token with a digital certificate to generate a user token
  • an encryption sending module configured to encrypt the user token by using the user public key, generate an encrypted user token, and send the encrypted user token and the digital certificate to the client of the authenticated user, A challenge response to enable the client to use the authorization metadata token for resource access.
  • the application also provides a token construction device for cloud platform resource access control, including:
  • the processor is configured to implement the steps of the token construction method for the above-mentioned cloud platform resource access control when executing the computer program.
  • a token construction method for cloud platform resource access control includes: obtaining a token application request of an authenticated user; wherein, the authenticated user is a user whose identity authentication is successful, and the token application request includes the user's public key; Token application request, generate an authorization metadata token corresponding to the authentication user; wherein, the authorization metadata token includes the leaf nodes of the Merkle tree data corresponding to the authentication user, and the leaf nodes include the respective hashes corresponding to each access resource authorization information value; digitally sign the authorization metadata token with a digital certificate to generate a user token; encrypt the user token with the user's public key to generate an encrypted user token, and send the encrypted user token and digital certificate to the authenticated user the client to enable the client to use the authorization metadata token for resource access challenge responses;
  • the encrypted user token sent to the user who has successfully authenticated only needs to contain the access resource authorization information required by the service request, and the information of the token is guaranteed to be complete enough.
  • greatly reducing the length of the token metadata so that the cloud platform API can use the content corresponding to the stored token for local authentication; and by encrypting the user token with the user's public key to generate an encrypted user token, ensuring that Security of token transfers.
  • the present application also provides a token construction device and device for cloud platform resource access control, which also have the above beneficial effects.
  • FIG. 1 is a flowchart of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 2 is a schematic storage diagram of a Merkle tree token of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 3 is a schematic storage diagram of an authorization metadata token of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 4 is a schematic diagram of storing Merkle tree port data of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 5 is a flowchart of a service request process of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 6 is a schematic diagram of an identity authentication process of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 7 is a schematic flowchart of an identity authentication process of a token construction method for cloud platform resource access control provided by an embodiment of the present application
  • FIG. 8 is a schematic diagram of token response information of a token construction method for cloud platform resource access control provided by an embodiment of the present application.
  • FIG. 9 is a structural block diagram of a token construction device for cloud platform resource access control provided by an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of a token construction device for cloud platform resource access control provided by an embodiment of the present application.
  • FIG. 1 is a flowchart of a token construction method for cloud platform resource access control provided by an embodiment of the present application.
  • the method can include:
  • Step 101 Obtain a token application request of an authenticated user; wherein the authenticated user is a user whose identity authentication is successful, and the token application request includes the user's public key.
  • the token application request in this step can be a request sent by a user (User) who has successfully authenticated through the client to apply for a user token (ie, User Merkel Tree Token); for example, User can use the client Openstack cloud service
  • the system sends the user name, password and the public key information generated by itself (that is, the user public key), and applies for a user token, that is, the token application request in this step may include the user name, password and user public key of the user whose identity authentication is successful. key.
  • the processor may perform identity authentication on the user corresponding to the token application request according to the user name and password in the received token application request; if the identity verification is successful, determine the user corresponding to the token application request.
  • To authenticate the user go to step 102 to generate an authorization metadata token corresponding to the authenticated user; if the authentication fails, the process can be ended directly or the authentication failure information can be returned to the client.
  • the specific content of the token application request in this step can be set by the designer according to practical scenarios and user needs, as long as the processor can determine the identity authentication that needs to apply for the user token according to the obtained token application request. For a successful user (ie, an authenticated user), this embodiment does not impose any restrictions on this.
  • the specific content of the public key (ie the user's public key) sent by the authenticated user through the client in the token application request in this step can be set by the designer or the user, as long as the processor can use the user's public key
  • the user token corresponding to the authorization metadata token applied by the authentication user is encrypted, and the authentication user can use the corresponding private key to decrypt, which is not limited in this embodiment.
  • this embodiment may further include the step of the client generating the user public key and the corresponding private key in the token application request, for example, the client may generate the public key information randomly and automatically after obtaining the user name and password input by the user. (user public key) and corresponding private key information to improve user experience.
  • the processor in the device (such as the server) running the identity authentication service (such as Keystone) in the cloud platform (such as Openstack) can obtain the user (User) who has successfully authenticated the identity authentication through the client.
  • Token request request the user (User) who has successfully authenticated the identity authentication through the client.
  • Step 102 Generate an authorization metadata token corresponding to the authentication user according to the token application request; wherein, the authorization metadata token includes the leaf nodes of the Merkle tree data corresponding to the authentication user, and the leaf nodes include the respective access resource authorization information. corresponding hash value.
  • this step can be to use the leaf nodes of the Merkle tree data to store in the cloud platform through the setting of the leaf nodes of the Merkle tree data (Merkle Tree) corresponding to the authentication user in the authorization metadata token.
  • Authenticate the information of each resource that the user is authorized to access that is, access resource authorization information
  • the necessary information required to authenticate the user's service request such as each endpoint information, user information, project information, role information and authorization time information, etc.
  • cloud platform APIs such as Openstack APIs
  • the Merkle tree data can be a tree that stores hash values (hash values), the leaf nodes of the Merkle tree data are the hash values of the data blocks, and the non-leaf nodes are their corresponding child nodes The hash value of the concatenated string.
  • the endpoint information in the access resource authorization information in this step can be the information of the endpoint (Endpoint, that is, the exposed port), that is, the accessible address on the network, which is described by the URL; each service exposes its own API through the Endpoint, and the client can use the Endpoint. Initiate a service request to the Openstack API, and the identity authentication service of the cloud platform (such as Keystone) is responsible for managing and maintaining the Endpoint of each service.
  • the user information in the access resource authorization information in this step can be the information of the authenticated user, that is, the digital representation of the individual, system or service of the Openstack cloud service; the authenticated user is assigned to a specific project (Project), granted roles and related information , such as ordinary users, administrators, third-party auditors, visitors.
  • the project information in the access resource authorization information can be the information of the project (Project) corresponding to the authenticated user.
  • the project groups and isolates the resource and the authenticated user.
  • the authenticated user must specify it to send a request to the service.
  • the role information in the access resource authorization information in this step may be the information of the role (Role) corresponding to the authenticated user, and the role includes a set of privileges for performing specific operations that can be assigned to specific users.
  • the authorization time information in the access resource authorization information may be the information of the authorization time (Expires_at) corresponding to the authentication user, that is, the information of the usable time of the authorization metadata token.
  • this embodiment does not limit the specific content and quantity of the leaf nodes of the Merkle tree data in the authorization metadata token.
  • the leaf nodes of the Merkle tree data may include the corresponding hash values of each endpoint information, The hash value corresponding to the user information, the hash value corresponding to the item information and the hash value corresponding to the authorization time information, the hash value corresponding to each item of information is stored in a corresponding leaf node; the leaves of the Merkle tree data
  • the node may also include a hash value corresponding to the creation time information (Issued_at).
  • a random number (such as a random number of one byte) can be added to each item of endpoint information, user information, project information, role information, authorization time information and creation time information to
  • the leaf nodes of the Merkle tree data can include the hash values corresponding to the above items of information added with random numbers.
  • the leaf nodes of the Merkle tree data in the authorization metadata token may be disordered, that is, each time the authorization metadata token is generated, the above information is in the leaf nodes of the Merkle tree data.
  • the location of the endpoint information, user information, project information, role information, authorization time information and creation time information can be different, that is, there is no fixed order for the information of each endpoint information, user information, project information, role information, and creation time information.
  • the corresponding hash values of the information, authorization time information and creation time information are randomly used as the leaf nodes of the Merkle tree to generate Merkle tree data.
  • the order of the leaf nodes of the Merkle tree data in the new authorization metadata token is the same as that of the old authorization token.
  • the data token is not the same, ie the new authorization metadata token cannot be inferred from the old authorization metadata token.
  • this embodiment does not limit the specific length of the leaf node of the Merkle tree data, that is, the specific length of the hash value.
  • the length of the hash value of the leaf node of the Merkle tree data in this step may be 32 bytes, or less bytes, by reducing the byte length of the hash value to reduce the amount of data, but the corresponding degree of security will be reduced accordingly.
  • the Merkle tree (ie Merkle tree data) corresponding to the leaf node in the authorization metadata token in this step can be calculated from the leaf node layer by layer from bottom to top to the root node (Merkle tree data). root, as shown in Hash00 in Figure 2).
  • the Merkle tree data in this step can be a complete binary tree structure with an even number of leaf nodes, that is, when the endpoint information, user information, project information, role information, authorization time information and creation time information are required for these service requests.
  • the processor can regenerate a corresponding number of leaf nodes to ensure that the Merkle tree data is a complete binary tree structure with an even number of leaf nodes. For example, the processor can randomly copy a leaf node data and fill it to the tail.
  • the specific content of the authorization metadata token in this step can be set by the designer.
  • the authorization metadata token may only include the leaf nodes of Merkle tree data; the authorization metadata token may also include User ID (User_ID in FIG. 3 ) and leaf nodes (Hash30-Hash37) of Merkle tree data; the metadata token may also include other information of the user, which is not limited in this embodiment.
  • this step may also include the step of the processor storing the Merkel tree token (such as the Keystone Merkel Tree Token) corresponding to the user authentication service; wherein, the authorization metadata token includes the user ID and the Merkel tree token.
  • the Merkle tree token can include the user ID and the metadata corresponding to each leaf node in the Merkle tree data, that is, the user ID and the data before hash encryption of each leaf node, as shown in Figure 2
  • the User, Role, Project, Expires_at, Issued_at and endpoint information (Endpoint 1-Endpoint 3) of their corresponding random numbers are added; the Merkle tree token can also include the root node in the Merkle tree data (as shown in the figure). 2 in Hash00).
  • Step 103 Digitally sign the authorization metadata token by using the digital certificate to generate a user token.
  • this step may be that the processor digitally signs the authorization metadata token by using the digital certificate, and encrypts the authorization metadata token by using the digital signature, so as to ensure the transmission security of the authorization metadata token.
  • the processor can use the digital certificate to digitally sign the user ID and the leaf node (hash value) respectively, and combine the two parts.
  • the combination forms the User Merkel Tree Token.
  • the Merkel tree data is a complete binary tree structure with an even number of leaf nodes
  • the json (a lightweight data exchange format) representation of the metadata of the User Merkel Tree Token The way can be:
  • Step 104 Encrypt the user token with the user's public key, generate an encrypted user token, and send the encrypted user token and the digital certificate to the client that authenticates the user, so that the client can use the authorized metadata token to access resources challenge response.
  • the processor encrypts the user token by using the user public key sent by the user through the client to further ensure the security of the transmission of the user token; and in this step, the processor sends the encrypted user token and the digital certificate To the client, the user can use the digital certificate and the private key corresponding to the user's public key to decrypt the encrypted user token correspondingly to obtain the authorization metadata token, so that the decrypted authorization metadata can be used when making service requests. Token for resource access challenge response.
  • this step it may also include that the client decrypts the encrypted user token by using the private key corresponding to the user's public key to obtain the user token; uses the digital certificate to verify the digital signature in the user's public key, and obtains the authorization metadata token. card steps.
  • this embodiment is shown by taking the process of a user applying for a token (that is, a user token) to a device (such as a server) running an identity authentication service (such as Keystone) in the cloud platform through a client as an example.
  • a token that is, a user token
  • a device such as a server
  • an identity authentication service such as Keystone
  • the process of other users applying for tokens to the device through other clients may be implemented in the same or similar manner as the method provided in this embodiment, which is not limited in this embodiment.
  • this embodiment may further include the step of the processor storing the corresponding Merkle tree port data of the cloud platform API (such as Openstack API) corresponding to the exposed port (that is, the target exposed port) of the authenticated user in the cloud platform, so that When the client sends a service request for resource access to the cloud platform API of the target exposed port, the cloud platform API can use the stored Merkle tree port data to challenge the authenticated user. That is to say, the cloud platform API of each exposed port (that is, the target exposed port) in the cloud platform to which the authenticated user is authorized to access can use the respective stored Merkle tree port data to determine the access rights of the authenticated user, and the authenticated user does not have access rights.
  • the cloud platform API such as Openstack API
  • the method provided in this embodiment may further include: the processor generates Merkle tree port data corresponding to each target exposed port according to the Merkle tree data corresponding to the authenticated user; Send to the corresponding target exposed port for storage; wherein, the target exposed port is the exposed port in the cloud platform that the authenticated user is authorized to access.
  • the stored Merkle tree port data corresponding to the exposed port (ie, the cloud platform API) that the authenticated user is authorized to access in the cloud platform may include the metadata corresponding to the target leaf node and the non-target leaf node; as shown in Figure 4 , when the leaf nodes in the Merkle tree data corresponding to the authenticated user include the respective hash values of each endpoint information in the cloud platform, the non-target leaf nodes are the corresponding target exposed ports in the Merkle tree data (as shown in Figure 4
  • the leaf nodes corresponding to each port information other than Endpoint 2 in the above such as Hash35 and Hash37 in Figure 4
  • the metadata corresponding to the target leaf node can be each leaf other than the non-target leaf node in the Merkle tree data
  • the node that is, the target leaf node
  • hashes the data before encryption as shown in Figure 4, adds User, Role, Project, Expires_at, Issued_at and Endpoint 2 with their corresponding random numbers.
  • this embodiment solves the problem that the length of the existing PKI Token message is too large.
  • the PKI Token can easily reach 8kB, which makes it difficult for the Token to fit the HTTP message header.
  • the corresponding The data is hashed to reduce the length of the token message, and to ensure sufficient and valid verification data; the client only needs to store the user token or authorization metadata token of 256k-1kB bytes, that is, the authorization metadata token can include default data.
  • the target data in the Kerr tree data the target data can only include all the leaf nodes of the Merkle tree data, and the target data can be less than or equal to 1KB; the server only needs to store about 2kB corresponding to the cloud platform API of each target exposed port. Merkle tree port data in bytes.
  • the encrypted user token sent to the user whose identity authentication is successful only needs to contain the access resource authorization information required by the service request. If it is complete enough, the length of the token metadata is greatly reduced, so that the cloud platform API can use the content corresponding to the stored token for local authentication; and by using the user public key to encrypt the user token, generate an encrypted user Token, which ensures the security of token transmission.
  • this embodiment discloses a process of using the constructed token (ie, encrypted user token) for resource access control of the cloud platform.
  • the constructed token ie, encrypted user token
  • FIG. 5 is a flowchart of a service request process of a token construction method for cloud platform resource access control provided by an embodiment of the present application. The method can include:
  • Step 201 Acquire a service request sent by the client to authenticate the user to access the exposed port; wherein, the access exposed port is an exposed port that receives the service request.
  • the client initiates a service request process to the cloud platform API (eg, Openstack API) that exposes the port.
  • the server that provides the cloud platform API in the cloud platform uses the stored Merkel tree port data (such as Openstack API Merkel Tree Token) for local authentication, and does not need to communicate online with the components of the identity authentication service (such as Keystone), Reduce communication overhead.
  • the access exposed port in this step may be the exposed port of the cloud platform accessed by the authenticated user through the client, such as any target exposed port in the above embodiment, that is, after the user obtains the encrypted user instruction, it can be exposed to the access through the client
  • the port sends a service request, so that the processor accessing the server corresponding to the exposed port can run the cloud platform API accessing the exposed port, and obtain the service request sent by the client to authenticate the user to access the exposed port.
  • the service request in this step can include the user ID, such as the user ID of the digital signature in the user token, that is, the user can use the User_Id signed by Keystone to initiate a service request to the Openstack API accessing the exposed port (as shown in Figure 6 with User_Id signed service request).
  • the user ID such as the user ID of the digital signature in the user token
  • the user can use the User_Id signed by Keystone to initiate a service request to the Openstack API accessing the exposed port (as shown in Figure 6 with User_Id signed service request).
  • Step 202 According to the service request, verify whether the authenticated user is valid; if the authenticated user is valid, go to step 203.
  • the Openstack API can periodically pull the revocation list from Keystone.
  • the server running the Openstack API in this step can verify whether the user is valid according to the obtained revocation list and the authorization time information in the metadata; if If the user is valid, go to step 203; if the user is invalid, corresponding failure information may be sent to the client.
  • the Openstack API can first verify the signed User_Id; then use the revocation list to check whether the user of User_Id is valid; then store the Merkle tree port data corresponding to the authenticated user (such as the cache) from the local storage (ie the target Merkle tree port data, For example, the authorization time (Expires_at) information in the Merkle tree port data with the same User_Id), verify the validity period of the user; if all verifications pass, go to step 203, if the verification fails, send corresponding failure information to the client.
  • Step 203 Generate and send challenge information to the client according to the stored target Merkle tree port data; wherein, the target Merkle tree port data is the Merkle tree port data corresponding to the authenticated user stored in the access exposed port.
  • this step can be to run the server that accesses the Openstack API that exposes the port, and use the Merkle tree port data (that is, the target Merkle tree port data) corresponding to the authenticated user stored in the Openstack API to generate authentication.
  • the challenge information corresponding to the user to verify the identity of the authenticated user.
  • the target Merkel tree port data (Openstack API Merkel Tree Token) in this step can be stored locally in the exposed ports (that is, the target exposed ports) to which the authenticated user is authorized to access the exposed ports.
  • Authenticated Merkle tree port data When the leaf nodes in the Merkle tree data corresponding to the authenticated user include the respective hash values of each endpoint information in the cloud platform, the Merkle tree port data may include the access exposed ports in the Merkle tree data corresponding to the authenticated user.
  • the leaf nodes (that is, the non-target leaf nodes) corresponding to the port information other than that and the data of the leaf nodes (that is, the target leaf nodes) other than the non-target leaf nodes in the Merkle tree data before hash encryption (such as each endpoint) information, user information, project information, role information and authorization time information); as shown in Figure 4, when the exposed port is Endpoint 2, the Merkle tree port data corresponding to the exposed port can include non-target leaf nodes (Hash35 and Hash37 ) and the metadata corresponding to the target leaf node (User, Role, Project, Expires_at, Issued_at, and Endpoint2).
  • the target Merkle tree port data stored by accessing the exposed port may also include the root node (Hash 00) of the Merkle tree corresponding to the leaf node in the metadata token.
  • Hash 00 the root node of the Merkle tree corresponding to the leaf node in the metadata token.
  • the specific content of the challenge information generated according to the stored target Merkle tree port data in this step can be set by the designer.
  • the challenge information can be the token response information required to be returned by the client, including: Information about leaf nodes in all metadata tokens.
  • the target Merkle tree port data includes the root node of the Merkle tree data corresponding to the authenticated user
  • the challenge information may be generated according to any leaf node (ie, the challenge leaf node) of the Merkle tree data that is randomly selected.
  • Challenge information such as challenge information can be a random bypass node that requires the client to return User_Id, challenge leaf nodes (as shown in Hash34 in Figure 8) and the root node (as shown in Hash00 in Figure 8) that can generate the Merkle tree data (that is, the bypass hash value, such as Hash35, Hash23 and Hash10 in Figure 8); as shown in Figure 7, the challenge information can also be a request for the client to return the response leaf node corresponding to the challenge leaf node and its side path.
  • Hash value information so that the attacker can only intercept part of the hash value, and cannot completely restore the entire authorization metadata token, which ensures the security of the authorization metadata token; among them, the hash value on the path next to the leaf node can be used for Calculate a hash value of the node on the upper layer of the Merkle tree data with the response leaf node.
  • Hash30 in Figure 8 is the response leaf node
  • the hash value on the path next to Hash30 can be Hash31 used to calculate Hash20 with Hash30. This embodiment does not impose any limitation on this.
  • this step may include that the processor randomly selects challenge leaf nodes according to the target Merkle tree port data, generates challenge information corresponding to the challenge leaf nodes, and sends the challenge information to the client, so that the client returns a response containing The token response information corresponding to the response leaf node and the bypass hash value corresponding to the challenge leaf node; wherein the challenge leaf node is any leaf node of the Merkle tree data.
  • the target Merkle tree port data stored by accessing the exposed port may include the metadata corresponding to the target leaf node and the non-target leaf node, so as to avoid the situation that the metadata of the non-target leaf node is leaked;
  • the Ertree port data may also directly store all the leaf nodes in the Merkle tree data corresponding to the authenticated user or the data of all the leaf nodes before hash encryption, which is not limited in this embodiment.
  • Step 204 Verify the token response information returned by the client according to the target Merkle tree port data.
  • the purpose of this embodiment may be to run a server that accesses the Openstack API that exposes the port, and use the Merkle tree port data (that is, the target Merkle tree port data) corresponding to the authenticated user stored in the Openstack API, to the client
  • the response information ie, the token response information
  • the returned challenge information is verified to determine the identity and authorization of the authenticated user.
  • the client accepts the Openstack API challenge for accessing the exposed port, and generates and sends the token response information according to the authorization metadata token.
  • the client can generate the response leaf node and bypass hash value corresponding to the challenge leaf node according to the authorization metadata token.
  • the token response information of the desired value, and the response leaf nodes and bypass hash values in the token response information are sorted according to the order in which the Openstack API service node calculates the Merkel root, and the token response information is sent to the Openstack API.
  • the client can search the corresponding leaf node for the challenge leaf node from the authorization metadata token according to the challenge information sent by the received access exposed port; Calculate and determine the bypass hash value of the leaf node; generate and send token response information to the exposed port according to the response leaf node and bypass hash value.
  • the server running the Openstack API accessing the exposed port in this step to verify the token response information returned by the client according to the target Merkle tree port data can be set by the designer, such as:
  • the server may calculate the response root node according to the response leaf node and bypass hash value in the token response information; wherein, the response leaf node is the default value.
  • Any leaf node of the Kerr tree data, that is, the response leaf node corresponds to the challenge leaf node. If the challenge is successful, the response leaf node is the same as the challenge leaf node; the bypass hash value corresponds to the response leaf node and is used to calculate the root node.
  • the hash value in the Merkle tree data, the bypass hash value includes the hash value of the leaf nodes that are not Merkle tree data (Hash23 and Hash10 in Figure 8); Whether the root nodes in the Kerr tree port data are the same; if they are the same, go to step 205; if they are not the same, it is determined that the client's challenge has failed, and the client can be refused to provide services, as shown in Figure 7, the service request is rejected this time And send the request error message to the client.
  • Step 205 If the verification is successful, provide the service to the client.
  • this step is to process the client's service request and provide the corresponding service after the server running the Openstack API accessing the exposed port successfully passes the verification token response information, that is, after the client's challenge succeeds.
  • the embodiment of this application can reduce the amount of data that the client needs to send to the cloud platform API and reduce the cloud platform
  • the online communication between the API and the components of the identity authentication service reduces the communication overhead and realizes the local authentication of the cloud platform API.
  • FIG. 9 is a structural block diagram of a token construction apparatus for cloud platform resource access control provided by an embodiment of the present application.
  • the apparatus may include:
  • the obtaining module 10 is used to obtain a token application request of an authenticated user; wherein, the authenticated user is a user whose identity authentication is successful, and the token application request includes the user's public key;
  • the generating module 20 is used for generating the authorization metadata token corresponding to the authentication user according to the token application request; wherein, the authorization metadata token includes the leaf nodes of the Merkle tree data corresponding to the authentication user, and the leaf nodes include each access resource The corresponding hash value of the authorization information;
  • a signature module 30 configured to digitally sign the authorization metadata token by using a digital certificate to generate a user token
  • the encryption sending module 40 is used to encrypt the user token by using the user's public key, generate an encrypted user token, and send the encrypted user token and the digital certificate to the client that authenticates the user, so that the client can use the authorization metadata token. Cards for resource access challenge responses.
  • the leaf node includes: each endpoint information in the cloud platform, user information, project information, role information and hash values corresponding to authorization time information.
  • each endpoint information, user information, project information, role information, and authorization time information include respective random numbers.
  • the Merkle tree data is a complete binary tree structure with an even number of leaf nodes.
  • the generating module 20 may include:
  • the authentication sub-module is used to authenticate the user corresponding to the token application request according to the user name and password;
  • the generating submodule is used to determine the user corresponding to the token application request as the authentication user if the authentication is successful, and generate the authorization metadata token corresponding to the authentication user.
  • the signature module 30 may be specifically configured to use a digital certificate to digitally sign the user ID and the leaf node respectively, and combine them to obtain the user token.
  • the authorization metadata token includes target data in the Merkle tree data; the target data only includes leaf nodes, and the target data is less than or equal to 1KB.
  • the device may also include:
  • the port data generation module is used to generate Merkle tree port data corresponding to each target exposed port according to the Merkle tree data; wherein, the target exposed port is the exposed port in the cloud platform that the authenticated user is authorized to access;
  • the port data storage module is used to send the Merkle tree port data to the corresponding target exposed ports for storage.
  • the Merkle tree port data includes the metadata corresponding to the target leaf node and the non-target leaf node, the non-target leaf node and the target leaf node. All leaf nodes that make up the Merkle tree data, non-target leaf nodes are the leaf nodes corresponding to each port information other than the corresponding target exposed port in the Merkle tree data, and the metadata is the target leaf node in the Merkle tree data. Data before hash encryption.
  • the device may also include:
  • the service acquisition module is used to acquire the service request sent by the client for the authenticated user to access the exposed port; wherein, the access exposed port is the exposed port for receiving the service request;
  • the verification module is used to verify whether the authenticated user is valid according to the service request
  • the challenge module is used to generate and send challenge information to the client according to the stored target Merkle tree port data if it is valid; wherein, the target Merkle tree port data is the Merkle corresponding to the authenticated user accessing the exposed port storage Ershu port data;
  • the challenge verification module is used to verify the token response information returned by the client according to the target Merkle tree port data
  • the service module is used to provide services to the client by accessing the exposed port if the authentication is successful.
  • the verification module may include:
  • the ID obtaining sub-module is used to obtain the user ID according to the digital signature of the user ID in the service request;
  • the verification sub-module is used to verify whether the user is valid according to the obtained revocation list and the authorization time information in the metadata; if the user is valid, send a start signal to the challenge module.
  • the challenge module can be specifically used to randomly select challenge leaf nodes according to the target Merkle tree port data, generate challenge information corresponding to the challenge leaf nodes, and send the challenge information to the client; wherein, the challenge leaf node is the default node. Any leaf node of Kerr tree data
  • the challenge verification module may include:
  • the calculation sub-module is used to calculate the response root node according to the response leaf node and the bypass hash value in the token response information; wherein, the response leaf node is any leaf node of the Merkle tree data, and the response leaf node and challenge Corresponding to the leaf node, the bypass hash value is the hash value in the Merkle tree data corresponding to the response leaf node and used to calculate the root node, and the bypass hash value includes the leaf node that is not the Merkle tree data. hash value;
  • the root node judgment sub-module is used to judge whether the response root node is the same as the root node; if the response root node is the same as the root node, a start signal is sent to the service module.
  • the encrypted user token sent to the user whose identity authentication is successful only needs to contain the access resource authorization information required by the service request. If it is complete enough, the length of the token metadata is greatly reduced, so that the cloud platform API can use the content corresponding to the stored token for local authentication; and by encrypting the user token with the user's public key, an encrypted user Token, which ensures the security of token transmission.
  • FIG. 10 is a schematic structural diagram of a token construction device for cloud platform resource access control provided by an embodiment of the present application.
  • the device 1 may include:
  • the memory 11 is used to store a computer program; the processor 12 is used to implement the steps of the token construction method for cloud platform resource access control provided by the above embodiments when the computer program is executed.
  • Device 1 may include memory 11 , processor 12 and bus 13 .
  • the memory 11 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (eg, SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, and the like.
  • the memory 11 may be an internal storage unit of the device 1 in some embodiments.
  • the memory 11 can also be an external storage device of the device 1, such as a plug-in hard disk equipped on the server, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, flash memory Card (Flash Card), etc.
  • the memory 11 may also include both an internal storage unit of the device 1 and an external storage device.
  • the memory 11 can not only be used to store the application software and various data installed in the device 1, such as: the code of the program executing the token construction method of cloud platform resource access control, etc., but also can be used to temporarily store the output or to be output. The data.
  • the processor 12 may be a central processing unit (Central Processing Unit, CPU), controller, microcontroller, microprocessor or other data processing chip in some embodiments, for running the program code or processing stored in the memory 11 Data, such as the code of the program that executes the token construction method of cloud platform resource access control, etc.
  • CPU Central Processing Unit
  • controller microcontroller
  • microprocessor or other data processing chip in some embodiments, for running the program code or processing stored in the memory 11 Data, such as the code of the program that executes the token construction method of cloud platform resource access control, etc.
  • the bus 13 may be a peripheral component interconnect (PCI for short) bus or an extended industry standard architecture (EISA for short) bus or the like.
  • PCI peripheral component interconnect
  • EISA extended industry standard architecture
  • the bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is used in FIG. 10, but it does not mean that there is only one bus or one type of bus.
  • the device may also include a network interface 14, and the network interface 14 may optionally include a wired interface and/or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is usually used between the device 1 and other electronic devices. establish a communication connection.
  • a network interface 14 may optionally include a wired interface and/or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is usually used between the device 1 and other electronic devices. establish a communication connection.
  • the device 1 may further include a user interface 15, the user interface 15 may include a display, an input unit such as a button, and the optional user interface 15 may also include a standard wired interface and a wireless interface.
  • the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode, organic light-emitting diode) touch device, and the like.
  • the display may also be appropriately referred to as a display screen or a display unit, for displaying information processed in the device 1 and for displaying a visual user interface.
  • FIG. 10 only shows the device 1 with components 11-15. Those skilled in the art can understand that the structure shown in FIG. 10 does not constitute a limitation on the device 1, and may include fewer or more components than those shown in the drawings. components, or a combination of certain components, or a different arrangement of components.
  • an embodiment of the present application also discloses a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the cloud platform resource access control provided by the above-mentioned embodiment is implemented.
  • the steps of the token constructor are described in detail below.
  • the storage medium may include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other various storage media that can store program codes medium.
  • U disk mobile hard disk
  • read-only memory Read-Only Memory
  • RAM random access memory
  • magnetic disk or optical disk and other various storage media that can store program codes medium.

Abstract

本申请公开了一种云平台资源访问控制的令牌构造方法、装置及设备，该方法包括：获取认证用户的令牌申请请求；根据令牌申请请求，生成认证用户对应的授权元数据令牌；利用数字证书对授权元数据令牌进行数字签名，生成用户令牌；利用用户公钥对用户令牌进行加密，生成加密用户令牌，并将加密用户令牌和数字证书发送到认证用户的客户端，以使客户端利用授权元数据令牌进行资源访问的挑战响应；本申请通过授权元数据令牌的设置，使发送给身份认证成功的用户的加密用户令牌只需含有服务请求所需的访问资源授权信息，从而使云平台API能够利用存储的令牌对应的内容进行本地认证；并且利用用户公钥对用户令牌进行加密，保证了令牌传输的安全性。

Description

一种云平台资源访问控制的令牌构造方法、装置及设备
本申请要求在2020年12月10日提交中国专利局、申请号为202011434899.X、发明名称为“一种云平台资源访问控制的令牌构造方法、装置及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及云平台技术领域，特别涉及一种云平台资源访问控制的令牌构造方法、装置及设备。
背景技术
随着现代社会科技的发展，云计算平台(即云平台)的应用越来越广泛。Openstack作为一个开源的基础设施服务的云计算平台，其以兼容性、可扩展性、灵活性等优势被广泛应用于各种云计算领域。其中，Keystone是Openstack的身份认证组件。Keystone为Openstack提供统一的授权和身份认证服务，主要负责用户信息管理和各个服务的认证服务，其他核心组件都需要在Keystone注册其服务，用户与服务交互时，需要利用Keystone进行身份认证。该组件的安全主要在于认证的可信性、授权令牌管理和安全通信。一般用户在登录Openstack系统时，通过Keystone进行身份认证，并获取访问其他服务的令牌(Token)。其核心是用户获得一个高效安全的服务访问令牌。
Keystone中的令牌(Token)是一个字符串，每个Token都拥有一个具体的访问权限范围，Token可以确定用户能访问的资源。如果用户每次都采用用户名/密码访问OpenStack API(Application Program Interface，应用程序接口)，容易泄露用户信息，带来安全隐患，所以OpenStack要求用户访问其API前，必须先获取Token，然后Token作为用户凭据再进行访问。
现有技术中，Keystone采用的Token有4种：UUID Token、PKI Token、PKIz Token和Fernet Token。其中，UUID Token简单易用，但不携带其它信息，OpenStack API收到该Token后需要与Keystone进行交互，验证该Token是否有效，在高并发下容易出现性能问题；PKI Token虽然支持其余服务组件在本地认证，但需要CA(Certification Authority)颁发证书，Token过大会造成请求失败；PKIZ Token虽然对Token进行了压缩，但是也存在Token过大的缺点；Fernet Token是一种轻量级安全消息格式，它虽然避免了PKI Token过大的问题，但其用于加密Token的对称加密密钥需要分发、旋转和周期性的更换，且Fernet Token必须由Keystone验证，在高并发下容易出现性能问题。
因此，如何提供一种新的云平台资源访问控制的身份认证令牌构造方法，在确保身份认证的安全性的基础上，实现云平台API的本地认证，提高身份认证服务的扩展性，是现今急需解决的问题。
发明内容
本申请的目的是提供一种云平台资源访问控制的令牌构造方法、装置及设备，以在确保身份认证的安全性的基础上，实现云平台API的本地认证，提高身份认证服务的扩展性。
为解决上述技术问题，本申请提供一种云平台资源访问控制的令牌构造方法，包括：
获取认证用户的令牌申请请求；其中，所述认证用户为身份认证成功的用户，所述令牌申请请求包括用户公钥；
根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌；其中，所述授权元数据令牌包括所述认证用户对应的默克尔树数据的叶子节点，所述叶子节点包括各访问资源授权信息各自对应的哈希值；
利用数字证书对所述授权元数据令牌进行数字签名，生成用户令牌；
利用所述用户公钥对所述用户令牌进行加密，生成加密用户令牌，并将所述加密用户令牌和所述数字证书发送到所述认证用户的客户端，以使所述客户端利用所述授权元数据令牌进行资源访问的挑战响应。
可选的，所述叶子节点包括：云平台中的各端点信息、所述用户信息、所述项目信息、所述角色信息和所述授权时间信息对应的哈希值。
可选的，各所述端点信息、所述用户信息、所述项目信息、所述角色信息和所述授权时间信息中均包括各自对应的随机数。
可选的，默克尔树数据具体为叶子节点数量为偶数的完全二叉树结构。
可选的，所述令牌申请请求包括用户名和密码时，所述根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌，包括：
根据所述用户名和所述密码，对所述令牌申请请求对应的用户进行身份认证；
若身份验证成功，则将所述令牌申请请求对应的用户确定为所述认证用户，并生成所述认证用户对应的授权元数据令牌。
可选的，所述授权元数据令牌包括用户ID和所述叶子节点时，所述利用数字证书对所述元数据令牌进行数字签名，生成用户令牌，包括：
利用所述数字证书对所述用户ID和所述叶子节点分别进行数字签名，组合得到所述用户令牌。
可选的，所述授权元数据令牌包括所述默克尔树数据中的目标数据；所述目标数据只包括所述叶子节点，所述目标数据小于或等于1KB。
可选的，该方法还包括：
根据所述默克尔树数据，生成每个目标暴露端口各自对应的默克尔树端口数据；其中，所述目标暴露端口为云平台中所述认证用户被授权访问的暴露端口；
将所述默克尔树端口数据发送到各自对应的目标暴露端口中存储。
可选的，所述叶子节点包括云平台中的各端点信息各自对应的哈希值时，所述默克尔树端口数据包括目标叶子节点对应的元数据和非目标叶子节点，所述非目标叶子节点与所述目标叶子节点组成所述默克尔树数据的全部叶子节点，所述非目标叶子节点为所述默克尔树数据中对应的目标暴露端口之外的各所述端口信息对应的叶子节点，所述元数据为所述默克尔树数据中所述目标叶子节点哈希加密前的数据。
可选的，该方法还包括：
获取所述客户端发送的所述认证用户对访问暴露端口的服务请求；其中，所述访问暴露端口为接收所述服务请求的暴露端口；
根据所述服务请求，验证所述认证用户是否有效；
若所述认证用户有效，则根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息；其中，所述目标默克尔树端口数据为所述访问暴露端口存储的所述认证用户对应的默克尔树端口数据；
根据所述目标默克尔树端口数据，对所述客户端返回的令牌响应信息进行验证；
若验证成功，则通过所述访问暴露端口向所述客户端提供服务。
可选的，所述元数据令牌包括用户ID时，所述根据服务请求，验证所述用户是否有效，包括：
根据所述服务请求中所述用户ID的数字签名，获取所述用户ID；
根据获取的吊销列表和所述元数据中的所述授权时间信息，验证所述用户是否有效；
若所述认证用户有效，则执行所述根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息的步骤。
可选的，所述根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息，包括：
根据所述目标默克尔树端口数据，随机选择挑战叶子节点，生成所述挑战叶子节点对应的挑战信息，并将所述挑战信息发送到所述客户端；其中，所述挑战叶子节点为所述默克尔树数据的任一叶子节点。
可选的，所述目标默克尔树端口数据包括所述默克尔树数据的根节点时，所述根据所述目标默克尔树端口数据，对所述客户端返回的令牌响应信息进行验证，包括：
根据所述令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点；其中，所述响应叶子节点为所述默克尔树数据的任一叶子节点，所述响应叶子节点与所述挑战叶子节点相对应，所述旁路哈希值为所述响应叶子节点对应的用于计算所述根节点的所述默克尔树数据中的哈希值，所述旁路哈希值包括不为所述默克尔树数据的叶子节点的哈希值；
判断所述响应根节点与所述根节点是否相同；
若所述响应根节点与所述根节点相同，则执行所述向所述客户端提供服务的步骤。
可选的，所述根据所述令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点之前，还包括：
所述客户端根据接收的所述挑战信息，从所述授权元数据令牌中查找所述响应叶子节点；
根据所述响应叶子节点，利用所述授权元数据令牌中的所述叶子节点，计算确定所述旁路哈希值；
根据所述响应叶子节点和所述旁路哈希值，生成并向所述访问暴露端口发送所述令牌响应信息。
本申请还提供了一种云平台资源访问控制的令牌构造装置，包括：
获取模块，用于获取认证用户的令牌申请请求；其中，所述认证用户为身份认证成功的用户，所述令牌申请请求包括用户公钥；
生成模块，用于根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌；其中，所述授权元数据令牌包括所述认证用户对应的默克尔树数据的叶子节点，所述叶子节点包括各访问资源授权信息各自对应的哈希值；
签名模块，用于利用数字证书对所述授权元数据令牌进行数字签名，生成用户令牌；
加密发送模块，用于利用所述用户公钥对所述用户令牌进行加密，生成加密用户令牌，并将所述加密用户令牌和所述数字证书发送到所述认证用户的客户端，以使所述客户端利用所述授权元数据令牌进行资源访问的挑战响应。
本申请还提供了一种云平台资源访问控制的令牌构造设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如上述所述的云平台资源访问控制的令牌构造方法的步 骤。
本申请所提供的一种云平台资源访问控制的令牌构造方法，包括：获取认证用户的令牌申请请求；其中，认证用户为身份认证成功的用户，令牌申请请求包括用户公钥；根据令牌申请请求，生成认证用户对应的授权元数据令牌；其中，授权元数据令牌包括认证用户对应的默克尔树数据的叶子节点，叶子节点包括各访问资源授权信息各自对应的哈希值；利用数字证书对授权元数据令牌进行数字签名，生成用户令牌；利用用户公钥对用户令牌进行加密，生成加密用户令牌，并将加密用户令牌和数字证书发送到认证用户的客户端，以使客户端利用授权元数据令牌进行资源访问的挑战响应；
可见，本申请通过授权元数据令牌的设置，使发送给身份认证成功的用户的加密用户令牌只需含有服务请求所需的访问资源授权信息，在保证令牌的信息足够完全的情况下，大大降低了令牌元数据的长度，从而使云平台API能够利用存储的令牌对应的内容进行本地认证；并且通过利用用户公钥对用户令牌进行加密，生成加密用户令牌，保证了令牌传输的安全性。此外，本申请还提供了一种云平台资源访问控制的令牌构造装置及设备，同样具有上述有益效果。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的流程图；
图2为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的默克尔树令牌的存储示意图；
图3为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的授权元数据令牌的存储示意图；
图4为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的默克尔树端口数据的存储示意图；
图5为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的服务请求过程的流程图；
图6为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的身份认证过程的示意图；
图7为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的身份认证过程的流程示意图；
图8为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的令牌响应信息的示意图；
图9为本申请实施例所提供的一种云平台资源访问控制的令牌构造装置的结构框图；
图10为本申请实施例所提供的一种云平台资源访问控制的令牌构造设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参考图1，图1为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的流程图。该方法可以包括：
步骤101：获取认证用户的令牌申请请求；其中，认证用户为身份认证成功的用户，令牌申请请求包括用户公钥。
其中，本步骤中的令牌申请请求可以为身份认证成功的用户(User)通过客户端发送的用于申请用户令牌(即User Merkel Tree Token)的请求；如User可以通过客户端Openstack云服务系统，发送用户名、密码以及自身生成的公钥信息(即用户公钥)，申请用户令牌，即本步骤中的令牌申请请求可以包括身份认证成功的用户的用户名、密码和用户公钥。相应的，本步骤中处理器可以根据接收的令牌申请请求中的用户名和密码，对该令牌申请请求对应的用户进行身份认证；若身份验证成功，则将令牌申请请求对应的用户确定为认证用户，并进入步骤102，以生成认证用户对应的授权元数据令牌；若身份验证失败，可以直接结束本流程或向客户端返回身份认证失败信息。
对应的，对于本步骤中的令牌申请请求的具体内容，可以由设计人员根据实用场景和用户需求自行设置，只要处理器可以根据获取的令牌申请请求，确定需要申请用户令牌的身份认证成功的用户(即认证用户)，本实施例对此不做任何限制。同样的，对于本步骤中的令牌申请请求中认证用户通过客户端发送的公钥(即用户公钥)的具体内容，可以由设计人员或用户自行设置，只要保证处理器可以利用用户公钥对认证用户申请的授权元数据令牌对应的用户令牌进行加密，且认证用户能够利用相应的私钥进行解密，本实施例对此不做任何限制。
进一步的，本实施例还可以包括客户端生成令牌申请请求中的用户公钥和对应的私钥的步骤，如客户端可以在获取用户输入的用户名和密码后，自动随机生成的公钥信息(用户公钥)和相应的私钥信息，以提高用户体验。
具体的，本步骤中云平台(如Openstack)中运行有身份认证服务(如Keystone)的设备(如服务器)中的处理器能够获取身份认证成功的用户(User)通过客户端发送的认证用户的令牌申请请求。
步骤102：根据令牌申请请求，生成认证用户对应的授权元数据令牌；其中，授权元数据令牌包括认证用户对应的默克尔树数据的叶子节点，叶子节点包括各访问资源授权信息各自对应的哈希值。
可以理解的是，本步骤的目的可以为通过授权元数据令牌中认证用户对应的默克尔树数据(Merkle Tree)的叶子节点的设置，利用默克尔树数据的叶子节点存储云平台中认证用户所被授权访问的各个资源的信息(即访问资源授权信息)，也就是认证用户的服务请求所需的必要信息，如各端点信息、用户信息、项目信息、角色信息和授权时间信息等，以降低令牌元数据的长度，从而使云平台API(如Openstack API)能够利用存储的令牌对应的内容进行本地认证。
具体的，如图3，默克尔树数据可以为存储hash值(哈希值)的一棵树，默克尔树数据的叶子节点是数据块的hash值，非叶子节点是其对应子节点串联字符串的hash值。本步骤中访问资源授权信息中的端点信息可以为端点(Endpoint，即暴露端口)的信息，即网络上可访问的地址，由URL描述；各个服务通过Endpoint暴露自己的API，客户端可以利用Endpoint向Openstack API发起服务请求，云平台的身份认证服务(如Keystone)负责管理和维护每个服务的Endpoint。本步骤中访问资源授权信息中的用户信息可以为认证用户的信息，即Openstack云服务的个人、系统或服务的数字表示；认证用户被分配给特定的项目(Project)，被授予角色和相关信息，如普通用户、管理员、第三方审计、访客。访问资源授权信息中的项目信息可以为认证用户对应的项目(Project)的信息，项目对资源和认证用户进行分组和隔离的容器，认证用户必须指定它才能向服务发出请求。本步骤中访问资源授权信息中的角 色信息可以为认证用户对应的角色(Role)的信息，角色包括一组特权，用于执行可分配给特定用户的特定操作。访问资源授权信息中的授权时间信息可以为认证用户对应的授权时间(Expires_at)的信息，即授权元数据令牌可使用时间的信息。
对应的，本实施例并不限定授权元数据令牌中默克尔树数据的叶子节点的具体内容和数量，如默克尔树数据的叶子节点可以包括各端点信息各自对应的哈希值、用户信息对应的哈希值、项目信息对应的哈希值和授权时间信息对应的哈希值，每一项信息对应的哈希值存储在各自对应的一个叶子节点；默克尔树数据的叶子节点还可以包括创建时间信息(Issued_at)对应的哈希值。
进一步的，为了提高安全性，各端点信息、用户信息、项目信息、角色信息、授权时间信息和创建时间信息中的每一项信息中可以添加随机数(如一个字节的随机数)，以抵御穷举攻击，默克尔树数据的叶子节点可以包括上述各项添加了随机数的信息各自对应的哈希值。
对应的，本步骤中授权元数据令牌中默克尔树数据的叶子节点可以为无序的，即每次生成授权元数据令牌时，上述各项信息在默克尔树数据中叶子节点的位置可以不一样，即各端点信息、用户信息、项目信息、角色信息、授权时间信息和创建时间信息这些信息没有固定的排列顺序，处理器能够利用各端点信息、用户信息、项目信息、角色信息、授权时间信息和创建时间信息各自对应的哈希值随机作为默克尔树的叶子节点，生成默克尔树数据。也就是说，如果需要为同一用户再次生成新的授权元数据令牌，即使和上一个访问权限没有变，新授权元数据令牌中默克尔树数据的叶子节点的顺序也和旧授权元数据令牌不一样，即不能由旧授权元数据令牌推测新的授权元数据令牌。
具体的，本实施例并不限定默克尔树数据的叶子节点的具体长度，即哈希值的具体长度，如本步骤中的默克尔树数据的叶子节点的哈希值的长度可以为32字节，也可以为更少的字节数，通过减少哈希值的字节长度，来降低数据量，但是相应的安全程度会随之降低。
需要说明的是，本步骤中的授权元数据令牌中的叶子节点对应的默克尔树(即默克尔树数据)，可以由叶子节点从下往上逐层计算hash直至根节点(Merkle根，如图2中的Hash00)得到。相应的，本步骤中的默克尔树数据可以为叶子节点为偶数的完全二叉树结构，即当端点信息、用户信息、项目信息、角色信息、授权时间信息和创建时间信息这些服务请求所需的必要信息为奇数时，处理器可以再生成相应数量的叶子节点，以保证默克尔树数据为叶子节点为偶数的完全二叉树结构，如处理器可以随机复制一个叶子节点数据填充到尾部。
具体的，对于本步骤中的授权元数据令牌的具体内容，可以由设计人员自行设置，如授权元数据令牌可以仅包括默克尔树数据的叶子节点；授权元数据令牌也可以包括用户ID(如图3中的User_ID)和默克尔树数据的叶子节点(Hash30-Hash37)；元数据令牌还可以包括用户的其他信息，本实施例对此不做任何限制。
对应的，如图2，本步骤还可以包括处理器存储用户认证服务对应的默克尔树令牌(如Keystone Merkel Tree Token)的步骤；其中，授权元数据令牌包括用户ID和默克尔树数据的叶子节点时，默克尔树令牌可以包括用户ID和默克尔树数据中各叶子节点对应的元数据，即用户ID和各叶子节点哈希加密前的数据，如图2中加入了各自对应的随机数的User、Role、Project、Expires_at、Issued_at和各端点信息(Endpoint 1-Endpoint 3)；默克尔树令牌还可以包括默克尔树数据中的根节点(如图2中的Hash00)。
步骤103：利用数字证书对授权元数据令牌进行数字签名，生成用户令牌。
可以理解的是，本步骤的目的可以为处理器通过利用数字证书对授权元数据令牌进行数字签名，利用数字签名对授权元数据令牌进行加密，保证授权元数据令牌的传输安全性。
对应的，授权元数据令牌包括用户ID和默克尔树数据的叶子节点时，本步骤中处理器可以利用数字证书对用户ID和叶子节点(哈希值)分别进行数字签名，将两部分组合形成用户令牌(User Merkel Tree Token)。
具体的，如图3所示，默克尔树数据为叶子节点为偶数的完全二叉树结构时，用户令牌(User Merkel Tree Token)元数据的json(一种轻量级的数据交换格式)表示方式可以为：
“User_Id”:3ec3164f750146be97f21559ee4d9c51，“Hash00”:Merkel root，[{[{[{[“Hash30”:User]}，{[“Hash31”:Role]}]}，{[{[“Hash32”:Project]}，{[“Hash33”:Expires-at]}]}]}，{[{[{[“Hash43”:Issued-at]}，{[“Hash35”:Endpoint1]}]}，{[，{[“Hash36”:Endpoint2]}，{[“Hash37”:Endpoint3]}]}]}]}
步骤104：利用用户公钥对用户令牌进行加密，生成加密用户令牌，并将加密用户令牌和数字证书发送到认证用户的客户端，以使客户端利用授权元数据令牌进行资源访问的挑战响应。
其中，本步骤中处理器利用用户通过客户端发送的用户公钥，对用户令牌进行加密，进一步保证用户令牌传输的安全性；并且本步骤中处理器将加密用户令牌和数字证书发送到客户端，使得用户可以利用数字证书和自身的用户公钥对应的私钥对加密用户令牌进行相应的解密得到授权元数据令牌，从而在进行服务请求时能够利用解密得到的授权元数据令牌进行资源访问的挑战响应。
对应的，本步骤之后还可以包括客户端利用用户公钥对应的私钥对加密用户令牌进行解密，得到用户令牌；利用数字证书验证用户公钥中的数字签名，并获取授权元数据令牌的步骤。
需要说明的是，本实施例是以一个用户通过客户端向云平台中运行有身份认证服务(如Keystone)的设备(如服务器)申请令牌(即用户令牌)的过程为例进行的展示，对应的，对于其它用户通过其他客户端向该设备申请令牌的过程可以采用与本实施例所提供的方法相同或相似的方式实现，本实施例对此不做任何限制。
对应的，本实施例还可以包括处理器存储云平台中认证用户对应的暴露端口(即目标暴露端口)的云平台API(如Openstack API)各自对应的默克尔树端口数据的步骤，以使客户端向目标暴露端口的云平台API发送资源访问的服务请求时，云平台API可以利用存储的默克尔树端口数据对认证用户进行挑战。也就是说，云平台中认证用户被授权访问的每个暴露端口(即目标暴露端口)的云平台API可以利用各自存储的默克尔树端口数据确定认证用户的访问权限，而该认证用户未被授权访问的暴露端口(即非目标暴露端口)未存储有该认证用户对应的默克尔树端口数据，可以直接确定该认证用户不具备访问非目标暴露端口的权限。相应的，本实施例所提供的方法还可以包括：处理器根据认证用户对应的默克尔树数据，生成每个目标暴露端口各自对应的默克尔树端口数据；将默克尔树端口数据发送到各自对应的目标暴露端口中存储；其中，目标暴露端口为云平台中认证用户被授权访问的暴露端口。
具体的，存储的云平台中认证用户被授权访问的暴露端口(即云平台API)对应的默克尔树端口数据可以包括目标叶子节点对应的元数据和非目标叶子节点；如图4所示，认证用户对应的默克尔树数据中的叶子节点包括云平台中的各端点信息各自对应的哈希值时，非目标叶子节点为默克尔树数据中对应的目标暴露端口(如图4中的Endpoint 2)之外的各端口信息对应的叶子节点(如图4中的Hash35和Hash37)，目标叶子节点对应的元数据可以为默克尔树数据中非目标叶子节点之外的各叶子节点(即目标叶子节点)哈希加密前的数据，如图4中加入了各自对应的随机数的User、Role、Project、Expires_at、Issued_at和Endpoint 2。
具体的，本实施例中解决了现有PKI Token消息长度过大问题，PKI Token很容易达到8kB，使得该Token很难适合HTTP消息头，而本实施例通过构造授权元数据令牌，对相应数据进行hash操作，降低令牌消息长度，且保证足够且有效的验证数据；客户端仅需存储256k—1kB字节的用户令牌或授权元数据令牌，即授权元数据令牌可以包括默克尔树数据中的目标数据，目标数据可以只包括默克尔树数据的全部叶子节点，目标数据可以小于或等于1KB；服务器仅需存储各目标暴露端口的云平台API各自对应的2kB左右的字节的默克尔树端口数据。
本实施例中，本申请实施例通过授权元数据令牌的设置，使发送给身份认证成功的用户的加密用户令牌只需含有服务请求所需的访问资源授权信息，在保证令牌的信息足够完全的情况下，大大降低了令牌元数据的长度，从而使云平台API能够利用存储的令牌对应的内容进行本地认证；并且通过利用用户公钥对用户令牌进行加密，生成加密用户令牌，保证了令牌传输的安全性。
基于上一实施例，本实施例公开了构造的云平台资源访问控制的令牌(即加密用户令牌)的使用过程。具体的，请参考图5，图5为本申请实施例所提供的一种云平台资源访问控制的令牌构造方法的服务请求过程的流程图。该方法可以包括：
步骤201：获取客户端发送认证用户对访问暴露端口的服务请求；其中，访问暴露端口为接收服务请求的暴露端口。
具体的，本实施例可以为用户通过客户端获取加密用户指令后，通过客户端向暴露端口的云平台API(如Openstack API)发起服务请求过程。本实施例中云平台中的提供云平台API的服务器利用存储的默克尔树端口数据(如Openstack API Merkel Tree Token)进行本地认证，无需与身份认证服务(如Keystone)的组件进行在线沟通，降低通信开销。
其中，本步骤中的访问暴露端口可以为认证用户通过客户端访问的云平台的暴露端口，如上述实施例中的任一目标暴露端口，即用户获取加密用户指令后可以通过客户端向访问暴露端口发送服务请求，使访问暴露端口对应的服务器的处理器可以运行该访问暴露端口的云平台API，获取客户端发送认证用户对访问暴露端口的服务请求。本步骤中的服务请求可以包含用户ID，如用户令牌中数字签名的用户ID，即用户可以通过客户端利用Keystone签名的User_Id向访问暴露端口的Openstack API发起服务请求(如图6中带User_Id签名的服务请求)。
步骤202：根据服务请求，验证认证用户是否有效；若认证用户有效，则进入步骤203。
具体的，本实施例中Openstack API可以定时向Keystone拉取吊销列表，对应的，本步骤中运行Openstack API的服务器可以根据获取的吊销列表和元数据中的授权时间信息，验证用户是否有效；若用户有效，则进入步骤203；若用户无效，则可以向客户端发送相应的失败信息。例如Openstack API可以先验证签名的User_Id；再利用吊销列表，User_Id的用户是否有效；之后从本地存储(如缓存)的认证用户对应的默克尔树端口数据(即目标默克尔树端口数据，如User_Id相同的默克尔树端口数据)中的授权时间(Expires_at)信息，验证用户的有效期；若均验证通过，则进入步骤203，若验证未通过，则向客户端发送相应的失败信息。
步骤203：根据存储的目标默克尔树端口数据，生成并向客户端发送挑战信息；其中，目标默克尔树端口数据为访问暴露端口存储的认证用户对应的默克尔树端口数据。
可以理解的是，本步骤的目的可以为运行访问暴露端口的Openstack API的服务器，利用该Openstack API存储的认证用户对应的默克尔树端口数据(即目标默克尔树端口数据)，生成认证用户对应的挑战信息，以验证认证用户的身份。
具体的，本步骤中的目标默克尔树端口数据(Openstack API Merkel Tree Token)可以为认证用户被授权访问的暴露端口(即目标暴露端口)中访问暴露端口的Openstack API对应存储的用于本地认证的默克尔树端口数据。认证用户对应的默克尔树数据中的叶子节点包括云平台中的各端点信息各自对应的哈希值时，默克尔树端口数据可以包括认证用户对应的默克尔树数据中访问暴露端口之外的各端口信息对应的叶子节点(即非目标叶子节点)和该默克尔树数据中非目标叶子节点之外叶子节点(即目标叶子节点)在哈希加密前的数据(如各端点信息、用户信息、项目信息、角色信息和授权时间信息)；如图4所示，暴露端口为Endpoint 2时，暴露端口对应的默克尔树端口数据可以包括非目标叶子节点(Hash35和Hash 37)和目标叶子节点对应的元数据(User、Role、Project、Expires_at、Issued_at和Endpoint2)。
对应的，如图4所示，访问暴露端口存储的目标默克尔树端口数据还可以包括元数据令牌中的叶子节点对应的默克尔树的根节点(Hash 00)。本实施例对此不做任何限制。
需要说明的是，对于本步骤中根据存储的目标默克尔树端口数据，生成的挑战信息的具体内容，可以由设计人员自行设置，如挑战信息可以为要求客户端返回的令牌响应信息包括全部元数据令牌中的叶子节点的信息。目标默克尔树端口数据包括认证用户对应的默克尔树数据的根节点时，挑战信息可以为根据随机选取的该默克尔树数据的中任一叶子节点(即挑战叶子节点)生成的挑战信息，如挑战信息可以是要求客户端返回User_Id、挑战叶子节点(如图8中的Hash34)以及能够生成该默克尔树数据的根节点(如图8中的Hash00)的随机旁路节点(即旁路哈希值，如图8中的Hash35、Hash23和Hash10)的信息；如图7所示，挑战信息也可以是要求客户端返回挑战叶子节点对应的响应叶子节点和其旁路径上hash值的信息，以使攻击者只能截获部分hash值，无法完全还原整个授权元数据令牌，保证了授权元数据令牌的安全性；其中，响应叶子节点旁路径上hash值可以为用于与响应叶子节点计算该默克尔树数据上一层节点的一个hash值，例如图8中Hash30为响应叶子节点时，Hash30旁路径上hash值可以为用于与Hash30计算Hash20的Hash31。本实施例对此不做任何限制。
也就是说，本步骤可以包括处理器根据目标默克尔树端口数据，随机选择挑战叶子节点，生成挑战叶子节点对应的挑战信息，并将挑战信息发送到客户端，以使客户端返回包含有挑战叶子节点对应的响应叶子节点和旁路哈希值的令牌响应信息；其中，挑战叶子节点为默克尔树数据的任一叶子节点。
对应的，本实施例中访问暴露端口存储的目标默克尔树端口数据可以包括目标叶子节点对应的元数据和非目标叶子节点，以避免非目标叶子节点的元数据泄露的情况；目标默克尔树端口数据也可以直接存储认证用户对应的默克尔树数据中的全部叶子节点或全部叶子节点在哈希加密前的数据，本实施例对此不做任何限制。
步骤204：根据目标默克尔树端口数据，对客户端返回的令牌响应信息进行验证。
具体的，本实施例的目的可以为运行访问暴露端口的Openstack API的服务器，利用该Openstack API存储的认证用户对应的默克尔树端口数据(即目标默克尔树端口数据)，对客户端返回的挑战信息对应的响应信息(即令牌响应信息)进行验证，以确定认证用户的身份和授权。
对应的，本步骤之前还可以包括客户端接受访问暴露端口的Openstack API挑战，根据授权元数据令牌生成并发送令牌响应信息的步骤。例如，挑战信息为要求客户端返回挑战叶子节点对应的响应叶子 节点和旁路哈希值的信息时，客户端可以根据授权元数据令牌生成包括挑战叶子节点对应的响应叶子节点和旁路哈希值的令牌响应信息，并对令牌响应信息中的响应叶子节点和旁路哈希值按照Openstack API服务节点计算Merkel根的顺序排序，并发送令牌响应信息到Openstack API。
也就是说，本步骤之前客户端可以根据接收的访问暴露端口发送的挑战信息，从授权元数据令牌中查找挑战叶子节点对应的响应叶子节点；根据响应叶子节点，利用授权元数据令牌中的叶子节点，计算确定旁路哈希值；根据响应叶子节点和旁路哈希值，生成并向访问暴露端口发送令牌响应信息。
可以理解的是，对于本步骤中运行访问暴露端口的Openstack API的服务器根据目标默克尔树端口数据，对客户端返回的令牌响应信息进行验证的具体方式，可以由设计人员自行设置，如令牌响应信息包括响应叶子节点和旁路哈希值时，本步骤中服务器可以根据令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点；其中，响应叶子节点为默克尔树数据的任一叶子节点，即响应叶子节点与挑战叶子节点相对应，如挑战成功时响应叶子节点与挑战叶子节点相同；旁路哈希值为响应叶子节点对应的用于计算根节点的默克尔树数据中的哈希值，旁路哈希值包括不为默克尔树数据的叶子节点的哈希值(如图8中的Hash23和Hash10)；判断响应根节点与目标默克尔树端口数据中的根节点是否相同；若相同，则进入步骤205；若不相同，则确定客户端的挑战失败，可以拒绝向客户端提供服务，如图7所示，拒绝本次服务请求并向客户端发送请求错误信息。
步骤205：若验证成功，则向客户端提供服务。
可以理解的是，本步骤的目的可以为运行访问暴露端口的Openstack API的服务器在验证令牌响应信息成功通过，即客户端挑战成功后，处理客户端的服务请求，提供相应的服务。
本实施例中，本申请实施例通过在客户端向访问暴露端口的云平台API请求服务过程中采用挑战响应式的方案，能够减少客户端需要向云平台API发送的数据量，并且减少云平台API与身份认证服务的组件进行在线沟通的情况，降低通信开销，实现了云平台API的本地认证。
请参考图9，图9为本申请实施例所提供的一种云平台资源访问控制的令牌构造装置的结构框图。该装置可以包括：
获取模块10，用于获取认证用户的令牌申请请求；其中，认证用户为身份认证成功的用户，令牌申请请求包括用户公钥；
生成模块20，用于根据令牌申请请求，生成认证用户对应的授权元数据令牌；其中，授权元数据令牌包括认证用户对应的默克尔树数据的叶子节点，叶子节点包括各访问资源授权信息各自对应的哈希值；
签名模块30，用于利用数字证书对授权元数据令牌进行数字签名，生成用户令牌；
加密发送模块40，用于利用用户公钥对用户令牌进行加密，生成加密用户令牌，并将加密用户令牌和数字证书发送到认证用户的客户端，以使客户端利用授权元数据令牌进行资源访问的挑战响应。
可选的，叶子节点包括：云平台中的各端点信息、用户信息、项目信息、角色信息和授权时间信息对应的哈希值。
可选的，各端点信息、用户信息、项目信息、角色信息和授权时间信息中均包括各自对应的随机数。
可选的，默克尔树数据具体为叶子节点数量为偶数的完全二叉树结构。
可选的，令牌申请请求包括用户的用户名和密码时，生成模块20可以包括：
认证子模块，用于根据用户名和密码，对令牌申请请求对应的用户进行身份认证；
生成子模块，用于若身份验证成功，则将令牌申请请求对应的用户确定为认证用户，并生成认证用户对应的授权元数据令牌。
可选的，元数据令牌包括用户ID和叶子节点时，签名模块30可以具体用于利用数字证书对用户ID和叶子节点分别进行数字签名，组合得到用户令牌。
可选的，授权元数据令牌包括默克尔树数据中的目标数据；目标数据只包括叶子节点，目标数据小于或等于1KB。
可选的，该装置还可以包括：
端口数据生成模块，用于根据默克尔树数据，生成每个目标暴露端口各自对应的默克尔树端口数据；其中，目标暴露端口为云平台中认证用户被授权访问的暴露端口；
端口数据存储模块，用于将默克尔树端口数据发送到各自对应的目标暴露端口中存储。
可选的，叶子节点包括云平台中的各端点信息各自对应的哈希值时，默克尔树端口数据包括目标叶子节点对应的元数据和非目标叶子节点，非目标叶子节点与目标叶子节点组成默克尔树数据的全部叶子节点，非目标叶子节点为默克尔树数据中对应的目标暴露端口之外的各端口信息对应的叶子节点，元数据为默克尔树数据中目标叶子节点哈希加密前的数据。
可选的，该装置还可以包括：
服务获取模块，用于获取客户端发送的认证用户对访问暴露端口的服务请求；其中，访问暴露端口为接收服务请求的暴露端口；
验证模块，用于根据服务请求，验证认证用户是否有效；
挑战模块，用于若有效，则根据存储的目标默克尔树端口数据，生成并向客户端发送挑战信息；其中，目标默克尔树端口数据为访问暴露端口存储的认证用户对应的默克尔树端口数据；
挑战验证模块，用于根据目标默克尔树端口数据，对客户端返回的令牌响应信息进行验证；
服务模块，用于若验证成功，则通过访问暴露端口向客户端提供服务。
可选的，元数据令牌包括用户ID时，验证模块可以包括：
ID获取子模块，用于根据服务请求中用户ID的数字签名，获取用户ID；
验证子模块，用于根据获取的吊销列表和元数据中的授权时间信息，验证用户是否有效；若用户有效，则向挑战模块发送启动信号。
可选的，挑战模块可以具体用于根据目标默克尔树端口数据，随机选择挑战叶子节点，生成挑战叶子节点对应的挑战信息，并将挑战信息发送到客户端；其中，挑战叶子节点为默克尔树数据的任一叶子节点
可选的，目标默克尔树端口数据包括默克尔树的根节点时，挑战验证模块可以包括：
计算子模块，用于根据令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点；其中，响应叶子节点为默克尔树数据的任一叶子节点，响应叶子节点与挑战叶子节点相对应，旁路哈希值为响应叶子节点对应的用于计算根节点的默克尔树数据中的哈希值，旁路哈希值包括不为默克尔树数据的叶子节点的哈希值；
根节点判断子模块，用于判断响应根节点与根节点是否相同；若响应根节点与根节点相同，则向服务模块发送启动信号。
本实施例中，本申请实施例通过授权元数据令牌的设置，使发送给身份认证成功的用户的加密用户令牌只需含有服务请求所需的访问资源授权信息，在保证令牌的信息足够完全的情况下，大大降低了令 牌元数据的长度，从而使云平台API能够利用存储的令牌对应的内容进行本地认证；并且通过利用用户公钥对用户令牌进行加密，生成加密用户令牌，保证了令牌传输的安全性。
请参考图10，图10为本申请实施例所提供的一种云平台资源访问控制的令牌构造设备的结构示意图。该设备1可以包括：
存储器11，用于存储计算机程序；处理器12，用于执行该计算机程序时实现如上述实施例所提供的云平台资源访问控制的令牌构造方法的步骤。
设备1可以包括存储器11、处理器12和总线13。
其中，存储器11至少包括一种类型的可读存储介质，该可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器11在一些实施例中可以是设备1的内部存储单元。存储器11在另一些实施例中也可以是设备1的外部存储设备，例如服务器上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器11还可以既包括设备1的内部存储单元也包括外部存储设备。存储器11不仅可以用于存储安装于设备1的应用软件及各类数据，例如：执行云平台资源访问控制的令牌构造方法的程序的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
处理器12在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器11中存储的程序代码或处理数据，例如执行云平台资源访问控制的令牌构造方法的程序的代码等。
该总线13可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
进一步地，设备还可以包括网络接口14，网络接口14可选的可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等)，通常用于在该设备1与其他电子设备之间建立通信连接。
可选地，该设备1还可以包括用户接口15，用户接口15可以包括显示器(Display)、输入单元比如按键，可选的用户接口15还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在设备1中处理的信息以及用于显示可视化的用户界面。
图10仅示出了具有组件11-15的设备1，本领域技术人员可以理解的是，图10示出的结构并不构成对设备1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
此外，本申请实施例还公开了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现如上述实施例所提供的云平台资源访问控制的令牌构造方法的步骤。
其中，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、设备及计算机可读存储介质而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
以上对本申请所提供的一种云平台资源访问控制的令牌构造方法、装置、设备及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

Claims (16)

  1. 一种云平台资源访问控制的令牌构造方法，其特征在于，包括：
    获取认证用户的令牌申请请求；其中，所述认证用户为身份认证成功的用户，所述令牌申请请求包括用户公钥；
    根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌；其中，所述授权元数据令牌包括所述认证用户对应的默克尔树数据的叶子节点，所述叶子节点包括各访问资源授权信息各自对应的哈希值；
    利用数字证书对所述授权元数据令牌进行数字签名，生成用户令牌；
    利用所述用户公钥对所述用户令牌进行加密，生成加密用户令牌，并将所述加密用户令牌和所述数字证书发送到所述认证用户的客户端，以使所述客户端利用所述授权元数据令牌进行资源访问的挑战响应。
  2. 根据权利要求1所述的云平台资源访问控制的令牌构造方法，其特征在于，所述叶子节点包括：云平台中的各端点信息、所述用户信息、所述项目信息、所述角色信息和所述授权时间信息对应的哈希值。
  3. 根据权利要求2所述的云平台资源访问控制的令牌构造方法，其特征在于，各所述端点信息、所述用户信息、所述项目信息、所述角色信息和所述授权时间信息中均包括各自对应的随机数。
  4. 根据权利要求1所述的云平台资源访问控制的令牌构造方法，其特征在于，默克尔树数据具体为叶子节点数量为偶数的完全二叉树结构。
  5. 根据权利要求1所述的云平台资源访问控制的令牌构造方法，其特征在于，所述令牌申请请求包括用户名和密码时，所述根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌，包括：
    根据所述用户名和所述密码，对所述令牌申请请求对应的用户进行身份认证；
    若身份验证成功，则将所述令牌申请请求对应的用户确定为所述认证用户，并生成所述认证用户对应的授权元数据令牌。
  6. 根据权利要求1所述的云平台资源访问控制的令牌构造方法，其特征在于，所述授权元数据令牌包括用户ID和所述叶子节点时，所述利用数字证书对所述元数据令牌进行数字签名，生成用户令牌，包括：
    利用所述数字证书对所述用户ID和所述叶子节点分别进行数字签名，组合得到所述用户令牌。
  7. 根据权利要求1所述的云平台资源访问控制的令牌构造方法，其特征在于，所述授权元数据令牌包括所述默克尔树数据中的目标数据；所述目标数据只包括所述叶子节点，所述目标数据小于或等于1KB。
  8. 根据权利要求1至7任一项所述的云平台资源访问控制的令牌构造方法，其特征在于，还包括：
    根据所述默克尔树数据，生成每个目标暴露端口各自对应的默克尔树端口数据；其中，所述目标暴露端口为云平台中所述认证用户被授权访问的暴露端口；
    将所述默克尔树端口数据发送到各自对应的目标暴露端口中存储。
  9. 根据权利要求8所述的云平台资源访问控制的令牌构造方法，其特征在于，所述叶子节点包括云平台中的各端点信息各自对应的哈希值时，所述默克尔树端口数据包括目标叶子节点对应的元数据和非目标叶子节点，所述非目标叶子节点与所述目标叶子节点组成所述默克尔树数据的全部叶子节点，所述非目标叶子节点为所述默克尔树数据中对应的目标暴露端口之外的各所述端口信息对应的叶子节点，所述元数据为所述默克尔树数据中所述目标叶子节点哈希加密前的数据。
  10. 根据权利要求8所述的云平台资源访问控制的令牌构造方法，其特征在于，还包括：
    获取所述客户端发送的所述认证用户对访问暴露端口的服务请求；其中，所述访问暴露端口为接收所述服务请求的暴露端口；
    根据所述服务请求，验证所述认证用户是否有效；
    若所述认证用户有效，则根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息；其中，所述目标默克尔树端口数据为所述访问暴露端口存储的所述认证用户对应的默克尔树端口数据；
    根据所述目标默克尔树端口数据，对所述客户端返回的令牌响应信息进行验证；
    若验证成功，则通过所述访问暴露端口向所述客户端提供服务。
  11. 根据权利要求10所述的云平台资源访问控制的令牌构造方法，其特征在于，所述元数据令牌包括用户ID时，所述根据服务请求，验证所述用户是否有效，包括：
    根据所述服务请求中所述用户ID的数字签名，获取所述用户ID；
    根据获取的吊销列表和所述元数据中的所述授权时间信息，验证所述用户是否有效；
    若所述用户有效，则执行所述根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息的步骤。
  12. 根据权利要求10所述的云平台资源访问控制的令牌构造方法，其特征在于，所述根据存储的目标默克尔树端口数据，生成并向所述客户端发送挑战信息，包括：
    根据所述目标默克尔树端口数据，随机选择挑战叶子节点，生成所述挑战叶子节点对应的挑战信息，并将所述挑战信息发送到所述客户端；其中，所述挑战叶子节点为所述默克尔树数据的任一叶子节点。
  13. 根据权利要求12所述的云平台资源访问控制的令牌构造方法，其特征在于，所述目标默克尔树端口数据包括所述默克尔树数据的根节点时，所述根据所述目标默克尔树端口数据，对所述客户端返回的令牌响应信息进行验证，包括：
    根据所述令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点；其中，所述响应叶子节点为所述默克尔树数据的任一叶子节点，所述响应叶子节点与所述挑战叶子节点相对应，所述旁路哈希值为所述响应叶子节点对应的用于计算所述根节点的所述默克尔树数据中的哈希值，所述旁路哈希值包括不为所述默克尔树数据的叶子节点的哈希值；
    判断所述响应根节点与所述根节点是否相同；
    若所述响应根节点与所述根节点相同，则执行所述向所述客户端提供服务的步骤。
  14. 根据权利要求13所述的云平台资源访问控制的令牌构造方法，其特征在于，所述根据所述令牌响应信息中的响应叶子节点和旁路哈希值，计算响应根节点之前，还包括：
    所述客户端根据接收的所述挑战信息，从所述授权元数据令牌中查找所述响应叶子节点；
    根据所述响应叶子节点，利用所述授权元数据令牌中的所述叶子节点，计算确定所述旁路哈希值；
    根据所述响应叶子节点和所述旁路哈希值，生成并向所述访问暴露端口发送所述令牌响应信息。
  15. 一种云平台资源访问控制的令牌构造装置，其特征在于，包括：
    获取模块，用于获取认证用户的令牌申请请求；其中，所述认证用户为身份认证成功的用户，所述令牌申请请求包括用户公钥；
    生成模块，用于根据所述令牌申请请求，生成所述认证用户对应的授权元数据令牌；其中，所述授权元数据令牌包括所述认证用户对应的默克尔树数据的叶子节点，所述叶子节点包括各访问资源授权信息各自对应的哈希值；
    签名模块，用于利用数字证书对所述授权元数据令牌进行数字签名，生成用户令牌；
    加密发送模块，用于利用所述用户公钥对所述用户令牌进行加密，生成加密用户令牌，并将所述加密用户令牌和所述数字证书发送到所述认证用户的客户端，以使所述客户端利用所述授权元数据令牌进行资源访问的挑战响应。
  16. 一种云平台资源访问控制的令牌构造设备，其特征在于，包括：
    存储器，用于存储计算机程序；
    处理器，用于执行所述计算机程序时实现如权利要求1至13任一项所述的云平台资源访问控制的令牌构造方法的步骤。
PCT/CN2021/121214 2020-12-10 2021-09-28 一种云平台资源访问控制的令牌构造方法、装置及设备 WO2022121461A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/246,822 US20230370265A1 (en) 2020-12-10 2021-09-28 Method, Apparatus and Device for Constructing Token for Cloud Platform Resource Access Control

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011434899.X 2020-12-10
CN202011434899.XA CN112671720B (zh) 2020-12-10 2020-12-10 一种云平台资源访问控制的令牌构造方法、装置及设备

Publications (1)

Publication Number Publication Date
WO2022121461A1 true WO2022121461A1 (zh) 2022-06-16

Family

ID=75401778

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/121214 WO2022121461A1 (zh) 2020-12-10 2021-09-28 一种云平台资源访问控制的令牌构造方法、装置及设备

Country Status (3)

Country Link
US (1) US20230370265A1 (zh)
CN (1) CN112671720B (zh)
WO (1) WO2022121461A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115118437A (zh) * 2022-08-25 2022-09-27 人民法院信息技术服务中心 基于一致性哈希和路径证明的多签验证方法、装置及设备
CN116192447A (zh) * 2022-12-20 2023-05-30 江苏云涌电子科技股份有限公司 一种多因子身份认证方法
WO2024050087A1 (en) * 2022-09-02 2024-03-07 Cisco Technology, Inc. Authentication (authn) and authorization (authz) binding for secure network access

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112671720B (zh) * 2020-12-10 2022-05-13 苏州浪潮智能科技有限公司 一种云平台资源访问控制的令牌构造方法、装置及设备
CN113572759B (zh) * 2021-07-21 2023-05-23 华控清交信息科技(北京)有限公司 一种数据管理方法、装置、电子设备及存储介质
CN113810367A (zh) * 2021-08-02 2021-12-17 浪潮软件股份有限公司 一种基于动态令牌方式的混合数据验证访问控制方法
CN116127418B (zh) * 2023-04-14 2023-06-27 深圳竹云科技股份有限公司 容器应用授权方法、装置及计算机设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103475666A (zh) * 2013-09-23 2013-12-25 中国科学院声学研究所 一种物联网资源的数字签名认证方法
CN106534175A (zh) * 2016-12-07 2017-03-22 西安电子科技大学 基于OAuth协议的开放平台授权认证系统及方法
US20170139985A1 (en) * 2015-11-12 2017-05-18 Sap Se Poly-Logarithmic Range Queries on Encrypted Data
CN108599936A (zh) * 2018-04-20 2018-09-28 西安电子科技大学 一种OpenStack开源云用户的安全认证方法
CN110445615A (zh) * 2019-07-12 2019-11-12 平安普惠企业管理有限公司 网络请求安全性验证方法、装置、介质及电子设备
CN112019343A (zh) * 2020-07-28 2020-12-01 苏州浪潮智能科技有限公司 一种OpenStack令牌优化方法及系统
CN112671720A (zh) * 2020-12-10 2021-04-16 苏州浪潮智能科技有限公司 一种云平台资源访问控制的令牌构造方法、装置及设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103607284B (zh) * 2013-12-05 2017-04-19 李笑来 身份认证方法及设备、服务器
CN104935606A (zh) * 2015-07-07 2015-09-23 成都睿峰科技有限公司 一种云计算网络中的终端登录方法
KR101862861B1 (ko) * 2017-01-11 2018-07-04 주식회사 코인플러그 Utxo 기반 프로토콜을 사용하여 페이먼트 게이트웨이 서비스를 제공하는 방법 및 이를 이용한 서버
CN112491972A (zh) * 2018-06-11 2021-03-12 华为技术有限公司 资源获取、分发、下载方法、装置、设备及存储介质
CN111756753B (zh) * 2020-06-28 2022-09-23 中国平安财产保险股份有限公司 一种权限验证方法及系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103475666A (zh) * 2013-09-23 2013-12-25 中国科学院声学研究所 一种物联网资源的数字签名认证方法
US20170139985A1 (en) * 2015-11-12 2017-05-18 Sap Se Poly-Logarithmic Range Queries on Encrypted Data
CN106534175A (zh) * 2016-12-07 2017-03-22 西安电子科技大学 基于OAuth协议的开放平台授权认证系统及方法
CN108599936A (zh) * 2018-04-20 2018-09-28 西安电子科技大学 一种OpenStack开源云用户的安全认证方法
CN110445615A (zh) * 2019-07-12 2019-11-12 平安普惠企业管理有限公司 网络请求安全性验证方法、装置、介质及电子设备
CN112019343A (zh) * 2020-07-28 2020-12-01 苏州浪潮智能科技有限公司 一种OpenStack令牌优化方法及系统
CN112671720A (zh) * 2020-12-10 2021-04-16 苏州浪潮智能科技有限公司 一种云平台资源访问控制的令牌构造方法、装置及设备

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115118437A (zh) * 2022-08-25 2022-09-27 人民法院信息技术服务中心 基于一致性哈希和路径证明的多签验证方法、装置及设备
CN115118437B (zh) * 2022-08-25 2022-10-28 人民法院信息技术服务中心 基于一致性哈希和路径证明的多签验证方法、装置及设备
WO2024050087A1 (en) * 2022-09-02 2024-03-07 Cisco Technology, Inc. Authentication (authn) and authorization (authz) binding for secure network access
CN116192447A (zh) * 2022-12-20 2023-05-30 江苏云涌电子科技股份有限公司 一种多因子身份认证方法
CN116192447B (zh) * 2022-12-20 2024-01-30 江苏云涌电子科技股份有限公司 一种多因子身份认证方法

Also Published As

Publication number Publication date
US20230370265A1 (en) 2023-11-16
CN112671720A (zh) 2021-04-16
CN112671720B (zh) 2022-05-13

Similar Documents

Publication Publication Date Title
WO2022121461A1 (zh) 一种云平台资源访问控制的令牌构造方法、装置及设备
US11606352B2 (en) Time-based one time password (TOTP) for network authentication
TWI725655B (zh) 用於在可信執行環境中執行子邏輯代碼的程式執行和資料證明的方法、設備和系統
US10027670B2 (en) Distributed authentication
WO2018219056A1 (zh) 鉴权方法、装置、系统和存储介质
US10164963B2 (en) Enforcing server authentication based on a hardware token
US8296828B2 (en) Transforming claim based identities to credential based identities
CN103475666B (zh) 一种物联网资源的数字签名认证方法
WO2019127278A1 (zh) 安全访问区块链的方法、装置、系统、存储介质及电子设备
US20160050193A1 (en) System and methods for secure communication in mobile devices
US9584615B2 (en) Redirecting access requests to an authorized server system for a cloud service
US20140108810A1 (en) Performing client authentication using certificate store on mobile device
US11184336B2 (en) Public key pinning for private networks
JP2010531516A (ja) 安全でないネットワークを介する装置のプロビジョニング及びドメイン加入エミュレーション
KR20170106515A (ko) 다중 팩터 인증 기관
US11757640B2 (en) Non-fungible token authentication
EP2608477A1 (en) Trusted certificate authority to create certificates based on capabilities of processes
US11757877B1 (en) Decentralized application authentication
CN111241492A (zh) 一种产品多租户安全授信方法、系统及电子设备
US20220070002A1 (en) Multi-service scep-certificate based authentication
CN115622812A (zh) 基于区块链智能合约的数字身份验证方法及系统
TWI694346B (zh) 多元身分認證憑據之系統與方法
WO2024011863A9 (zh) 通信方法、装置、sim卡、电子设备和终端设备
JOJAPPA et al. Public Verifying for Mutual Data with Dynamic User Revocation in the Cloud
CA3217688A1 (en) Multi-factor authentication using blockchain

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21902169

Country of ref document: EP

Kind code of ref document: A1