Cloud Access Token Construction for Local Authentication at Scale
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing token systems in cloud platforms like OPENSTACK face performance issues under high concurrency and security vulnerabilities due to the limitations of UUID, PKI, PKIZ, and Fernet tokens, which affect authentication efficiency and security.
Innovation Solution
A method involving a Merkle tree-based authorization metadata token generation, digital signature, and encryption using a user's public key to create an encrypted user token, reducing token length and ensuring security during transmission.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If UUID Token is used, then the token is simple and easy to use, but the OPENSTACK API needs to interact with the Keystone after receiving the Token for verification, causing performance problems under high concurrency
Solution Approach 1:
The authentication process is segmented into two independent parts: (1) Token generation with embedded verification capability through Merkle tree structure, and (2) Local verification at API gateway without Keystone interaction. The Merkle tree divides authorization information into leaf nodes (individual resource permissions) and internal nodes (hash chains), allowing the root hash to serve as a compact verification signature that can be independently validated.
Solution Approach 2:
All authorization verification data is preliminarily computed and embedded into the token during the authentication phase. The Merkle tree structure pre-computes hash chains from leaf nodes (resource permissions) up to the root node, storing the root hash in the token. This preliminary action eliminates the need for real-time verification queries to Keystone during high-concurrency operations.
2Reliability
If PKI Token is used, then local authentication of service components is supported, but a CA is required to issue a certificate and the Token becomes too large causing request failures
Solution Approach 1:
The verification capability is extracted from the traditional Keystone-server-dependent model and embedded directly into the token itself through the Merkle tree root hash. Instead of relying on external CA certificates or centralized verification, each token contains self-sufficient authorization data in a compressed Merkle tree format, enabling local verification without increasing token size significantly.
Solution Approach 2:
The token structure transitions from storing complete authorization lists or large certificates to storing a compact Merkle tree root hash. This parameter change compresses the verification data from potentially large certificate structures into fixed-size hash values, maintaining reliability while dramatically reducing token length.
3Length of stationary object
If Fernet Token is used, then the Token size is reduced, but a symmetric encryption key needs to be distributed, rotated and periodically changed, and the Token must be verified by the Keystone, causing performance problems under high concurrency
Solution Approach 1:
The token becomes self-verifying through the embedded Merkle tree structure. The root hash in the token serves as a self-contained verification signature that can be validated locally at the API gateway without requiring Keystone interaction or symmetric key management. Each token independently carries its own verification credentials.
Solution Approach 2:
The Merkle tree root hash acts as an intermediary between the authorization data (leaf nodes) and the verification process. Instead of directly verifying individual resource permissions or requiring symmetric key decryption, the root hash mediates verification by providing a compact cryptographic summary that can be efficiently validated without Keystone involvement.
Data Source
AI summary
The present application discloses a method, apparatus and device for constructing a token for cloud platform resource access control. The method includes: acquiring a token application request of an authentication user; according to the token application request, generating an authorization metadata token corresponding to the authentication user; performing digital signature on the authorization metadata token by using a digital certificate, so as to generate a user token; and encrypting the user token by using a user public key, so as to generate an encrypted user token, and sending the encrypted user token and the digital certificate to a client of the authentication user, so that the client performs resource access challenge response by using the authorization metadata token.