Multi-tenant multi-user login method based on enhanced OAuth2
By generating tenant key proofs through zero-knowledge proofs and homomorphic encryption, and combining them with reinforcement learning access controllers, this approach addresses the tenant isolation and access management issues of the OAuth2 protocol, enabling fine-grained access control and improving authentication security and system availability.
Patent Information
- Application Number
- CN202511469041.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-15
- Publication Date
- 2025-12-16
- Estimated Expiration
- 2045-10-15
AI Technical Summary
The existing OAuth2 protocol lacks a tenant isolation mechanism, which cannot strictly distinguish tenant identity and permissions, leading to increased risks of cross-tenant access. Permission management is static and difficult to adjust dynamically, the authentication system is vulnerable to single point of failure, and key management lacks a security mechanism, making it difficult to cope with complex network attacks.
A method based on zero-knowledge proof and homomorphic encryption is adopted to generate tenant key proof and verification token. Combined with reinforcement learning access controller, permissions are dynamically adjusted, and distributed cache is used to store session identifiers to achieve fine-grained access control and authentication decoupling.
It effectively prevents unauthorized access across tenants, dynamically adjusts permissions, improves authentication security and system availability, reduces false alarm rates, and adapts to complex access control needs.
Smart Images

Figure CN120956528B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to network security technology, and in particular to a multi-tenant multi-user login method based on enhanced OAuth2. BACKGROUND
[0002] With the wide application of cloud computing and SaaS services, multi-tenant architecture has become a standard design pattern for modern enterprise-level applications. Under this architecture, the same software system needs to serve multiple tenants and a large number of users, which poses a serious challenge to identity authentication and permission management. The main defects and deficiencies of the prior art include:
[0003] The standard OAuth2 protocol lacks an effective tenant isolation mechanism and cannot strictly distinguish the identity and permission scope of different tenants at the token level, resulting in an increased risk of cross-tenant access. In particular, in a multi-tenant environment that shares infrastructure, once an access token is stolen, an attacker may gain unauthorized access to multiple tenant resources.
[0004] The permission management model uses a static configuration method and cannot dynamically adjust the permission policy according to user behavior patterns and context information, resulting in over-authorization or permission sprawl problems, which cannot meet the needs of modern applications for fine-grained and dynamic permission control, especially in enterprise environments where user roles and business scenarios change frequently.
[0005] Existing authentication and authorization systems usually store sensitive credentials centrally, forming a single point of failure risk, and lack sufficient security mechanisms for key management. Once the key is compromised, the security of the entire system will be severely threatened, and it is also difficult to deal with increasingly complex network attack methods, such as replay attacks, man-in-the-middle attacks, and other advanced threats. SUMMARY
[0006] The embodiments of the present application provide a multi-tenant multi-user login method based on enhanced OAuth2, which can solve the problems in the prior art.
[0007] In a first aspect, the embodiments of the present application provide a multi-tenant multi-user login method based on enhanced OAuth2, comprising:
[0008] Obtaining a tenant key threshold based on a tenant identifier in a login request, and obtaining an access token based on a user identifier by performing standard OAuth2 authentication;
[0009] generate a tenant key proof based on a zero-knowledge proof protocol and the tenant key threshold; encrypt the tenant key proof and the access token using a homomorphic encryption algorithm to generate tenant fingerprint information; store master key shards to a key management node, and generate a tenant verification token based on the tenant fingerprint information through secure multi-party computation of the key management node; and encrypt the tenant verification token and the access token in combination to generate an enhanced access token.
[0010] obtain historical access data of a user under a tenant; based on the historical access data, construct a reinforcement learning access controller, take user behavior as an observation state, and take a permission operation as an action space; collect real-time behavior data of the user, and generate an initial permission list based on continuous learning of the access controller on the real-time behavior data; perform anomaly detection on the initial permission list, and generate a fine-grained permission list in combination with the tenant verification token;
[0011] generate a session identifier based on the enhanced access token and the fine-grained permission list, and store the session identifier and authentication and authorization information to a distributed cache.
[0012] The step of generating a tenant key proof based on a zero-knowledge proof protocol and the tenant key threshold comprises:
[0013] obtain a tenant security level and a tenant resource sensitivity associated with the tenant identifier; generate a reference security value according to the tenant security level, and generate a resource sensitivity coefficient according to the tenant resource sensitivity; generate a tenant key threshold based on the reference security value, the resource sensitivity coefficient, and a dynamic adjustment factor, wherein the dynamic adjustment factor is obtained by weighted calculation of a real-time security threat level, a number of tenant authentication failures, and a historical attack frequency;
[0014] generate a zero-knowledge proof parameter based on a preset elliptic curve parameter, and generate an interactive commitment value using the zero-knowledge proof parameter and a tenant private key;
[0015] generate a tenant identity commitment according to the tenant private key and the interactive commitment value, construct a threshold satisfaction proof using the tenant key threshold and the interactive commitment value, and generate an auxiliary random value based on a preset group order; combine the tenant identity commitment, the threshold satisfaction proof, and the auxiliary random value to generate a zero-knowledge proof; perform parameter verification on the zero-knowledge proof, and when the verification is passed, generate a tenant key proof based on the zero-knowledge proof, the interactive commitment value, and the tenant private key.
[0016] The step of storing master key shards to a key management node, and generating a tenant verification token based on the tenant fingerprint information through secure multi-party computation of the key management node comprises:
[0017] The master key is stored in multiple key management nodes by a hierarchical dynamic threshold scheme, the threshold value and the total number of nodes of the hierarchical dynamic threshold scheme are determined according to the load intensity and communication efficiency of the key management nodes; the key management nodes are divided into multiple hierarchical groups based on node computing power scores and network topology distances; a nested polynomial structure is constructed for each hierarchical group, wherein the constant term of the inner polynomial is set as the master key value, and the coefficients of the outer polynomial are determined by the weighted values of the access behavior credibility and resource call frequency of the tenant; a unique key fragment is generated for each key management node according to the constructed polynomial and is stored and distributed;
[0018] After the tenant fingerprint information is processed for privacy protection, the key fragments in each of the key management nodes perform calculation with differential privacy in the homomorphic encryption domain, and distributed zero-knowledge proof is performed to generate a tenant verification token.
[0019] After the tenant fingerprint information is processed for privacy protection, the key fragments in each of the key management nodes perform calculation with differential privacy in the homomorphic encryption domain, and distributed zero-knowledge proof is performed to generate a tenant verification token.
[0020] The identity feature vector and the behavior feature vector are extracted from the tenant fingerprint information, and linear transformation is performed to generate a feature segment in a privacy protection form;
[0021] The feature segment is sent to multiple key management nodes, and each key management node performs homomorphic inner product operation on the key fragment held by the key management node and the feature segment in the encryption domain, and introduces differential privacy noise of Laplace distribution in the homomorphic inner product operation result to obtain a partial verification factor;
[0022] The calculation weight of each key management node is determined according to the credibility of the key management node, and the calculation weight and the corresponding partial verification factor are subjected to secure multi-party summation operation to generate an aggregated verification value;
[0023] When the number of key management nodes participating in the secure multi-party summation operation reaches a preset threshold value, the key management nodes perform distributed zero-knowledge proof protocol to verify the calculation process of the aggregated verification value, and combine the aggregated verification value that passes the verification with the hash value of the identity feature vector to generate a tenant verification token.
[0024] Based on the historical access data, an reinforcement learning access controller is constructed, the user behavior is taken as an observation state, and the permission operation is taken as an action space; the steps of collecting real-time behavior data of the user, and the access controller performing continuous learning based on the real-time behavior data to generate an initial permission list include:
[0025] The historical access data is extracted to obtain timing features, behavior features and environment features, and the timing features, the behavior features and the environment features are standardized by segmenting through a sliding time window to obtain standardized features;
[0026] A reinforcement learning access controller is constructed, the standardized features are combined into a user state vector, the user state vector includes a timing feature vector, a behavior feature vector and a context feature vector, a permission granting, revoking and maintaining operation is constructed as an action space, a composite reward function is constructed based on a security compliance degree reward, an access efficiency reward and a risk penalty term;
[0027] Real-time behavior data of a user is collected, and a real-time feature vector is obtained by using an attention mechanism to sequence encode the real-time behavior data of the user, the attention mechanism processes a current query vector and a historical behavior key-value pair; the access controller performs continuous learning based on the real-time feature vector, updates an access control policy through a policy gradient, and calculates an action value based on a value function estimate;
[0028] The confidence of each permission is calculated based on the action value and the consistency of the historical behavior, the confidence is filtered based on a preset filtering threshold, and a conflict resolution is performed using a permission dependency graph to generate an initial permission list.
[0029] The step of continuously learning of the access controller based on the real-time feature vector includes:
[0030] The real-time feature vector is input into a double-channel neural network of the access controller, a first channel constructs a local policy network to extract short-term behavior features, and a second channel constructs a global policy network to extract long-term behavior patterns;
[0031] A policy gradient of the access control policy is calculated based on outputs of the local policy network and the global policy network, the policy gradient evaluates historical decision trajectories through importance sampling, and an entropy regularization term is introduced;
[0032] A double value function is constructed to calculate the action value, the double value function estimates an immediate reward value and a long-term reward value respectively, and a time difference error is used to guide an update direction of the access control policy;
[0033] An adaptive learning rate is set based on a confidence interval theory, when a user behavior distribution change caused by an update of the access control policy exceeds a preset confidence interval, a learning step is automatically adjusted to ensure stable convergence of the access control policy.
[0034] The step of performing anomaly detection on the initial permission list and generating a fine-grained permission list in combination with the tenant verification token includes:
[0035] Based on a sliding time window, historical access behaviors of the user on each permission in the initial permission list are analyzed, a time sequence access mode is calculated, the time sequence access mode is converted into a permission frequency feature;
[0036] A tenant verification token is used to extract a tenant access time constraint, and a permission access rule library is constructed based on a preset time sequence rule template;
[0037] The permission frequency feature is matched with the permission access rule library, an abnormal permission that does not conform to the time sequence rule is identified, the access time of the abnormal permission is constrained to generate a time-limited permission set, the permission set is granularly divided in combination with a security level in the tenant verification token, and a fine-grained permission list with time constraints is generated.
[0038] In a second aspect of the embodiment of the application, an electronic device is provided, including:
[0039] A processor;
[0040] A memory for storing processor-executable instructions;
[0041] The processor is configured to invoke the instructions stored in the memory to execute the method described above.
[0042] In a third aspect of the embodiment of the application, a computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.
[0043] The multi-tenant multi-user login method based on the enhanced OAuth2 provided by the application protects the tenant key by combining zero-knowledge proof and homomorphic encryption, realizes the verifiability and security isolation of the tenant identity, effectively prevents cross-tenant unauthorized access and identity impersonation, and significantly improves the authentication security in the multi-tenant environment.
[0044] The access controller constructed by reinforcement learning can dynamically adjust the permission range according to the historical behavior of the user, realizes adaptive allocation of permissions, and filters abnormal operation requests through an abnormal detection mechanism, thereby improving the user experience while ensuring system security and reducing the false positive rate and authentication friction.
[0045] The enhanced access token is combined with the fine-grained permission list to generate a session identifier and store it in a distributed cache, realizes decoupling of authentication and authorization, supports fast permission verification under large-scale concurrent access, and improves system availability and scalability through a distributed architecture, thereby adapting to complex access control requirements in the cloud-native multi-tenant environment. BRIEF DESCRIPTION OF DRAWINGS
[0046] Figure 1A flowchart of a multi-tenant multi-user login method based on enhanced OAuth2 of an embodiment of the present application is shown in Figure 1.
[0047] Figure 2 A technical flowchart for key fragment storage and verification token generation is shown in Figure 4. DETAILED DESCRIPTION
[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0049] The technical solutions of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and some embodiments can not be described again for the same or similar concepts or processes.
[0050] Figure 1 A flowchart of a multi-tenant multi-user login method based on enhanced OAuth2 of an embodiment of the present application is shown in Figure 1. Figure 1 As shown in Figure 1, the method comprises the following steps.
[0051] Based on a tenant identifier in a login request, a tenant key threshold is obtained, and a standard OAuth2 authentication based on a user identifier is performed to obtain an access token;
[0052] Based on a zero-knowledge proof protocol and the tenant key threshold, a tenant key proof is generated. The tenant key proof and the access token are encrypted using a homomorphic encryption algorithm to generate tenant fingerprint information. The master key fragments are stored in a key management node, and based on the tenant fingerprint information, a tenant verification token is generated through secure multi-party computation of the key management node. The enhanced access token is generated by combining and encrypting the tenant verification token and the access token;
[0053] The historical access data of a user under a tenant is obtained. Based on the historical access data, a reinforcement learning access controller is constructed, and the user behavior is taken as an observation state and the permission operation is taken as an action space. Real-time behavior data of the user is collected, and the access controller performs continuous learning based on the real-time behavior data to generate an initial permission list. The initial permission list is subjected to abnormality detection, and a fine-grained permission list is generated in combination with the tenant verification token.
[0054] Based on the enhanced access token and the fine-grained permission list, a session identifier is generated, and the session identifier and authentication authorization information are stored in a distributed cache.
[0055] In this embodiment, when a user initiates a login request, a tenant identifier is extracted from the request, which is usually a 24-character unique string. A tenant configuration database is maintained to store security parameters such as tenant key threshold. Query the database with the tenant identifier as the key to obtain the corresponding tenant key threshold. The tenant key threshold defines the number of key shards and the minimum number of shards required for reconstruction. For example, a certain enterprise tenant's key threshold is configured as (5, 3), indicating that the key is divided into 5 shards, and at least 3 shards are required to reconstruct the complete key. Using the authorization code mode of OAuth2, first redirect the user to the authorization endpoint of the authentication server, and after the user provides identity credentials (such as username and password or biometrics), the authentication server returns the authorization code. Use the authorization code to initiate a request to the token endpoint to obtain an access token. Standard OAuth2 access tokens are in JWT format, containing user identification, permission scope, token expiration time, etc., signed by the authentication server's private key. For example, a certain user successfully authenticated access token contains user identification "u789012", permission scope "readwrite", and expiration time is 3600 seconds after the current time.
[0056] Zero-knowledge proof allows to prove the validity of holding the tenant key without disclosing the key itself. Schnorr protocol is used to construct zero-knowledge proof, and the proof generation process includes three steps: commitment, challenge and response. The prover first generates a commitment value based on the tenant key and a random number, and sends the commitment value to the verifier. The verifier generates a random challenge value and returns it to the prover. The prover calculates the response value according to the original key, random number and challenge value. The final tenant key proof contains the commitment value and response value, with a size of about 64 bytes. The tenant fingerprint information is generated by encrypting the tenant key proof and access token using homomorphic encryption algorithm. Homomorphic encryption allows certain operations to be performed on encrypted data without decryption first. Paillier homomorphic encryption algorithm is used, with a 2048-bit key for encryption. The encryption process first concatenates the tenant key proof and access token into a unified format data block, and then applies the homomorphic encryption function to generate the ciphertext. Homomorphic encryption ensures that tenant fingerprint information remains confidential even during transmission and computation, while retaining the ability to perform specific operations on encrypted data. The generated tenant fingerprint information is an encrypted data block of about 512 bytes, which can be securely transmitted between different components.
[0057] The Shamir secret sharing scheme is used to implement the master key fragmentation. Based on the tenant key threshold (t, n), the master key is divided into n fragments, where any t fragments can reconstruct the master key, and less than t fragments cannot obtain any information about the master key. Each key fragment is represented by an (x, y) coordinate pair, where x is the fragment index and y is the corresponding fragment value. These fragments are encrypted and stored separately on different key management nodes, with each node holding only one fragment. For example, for the aforementioned (5, 3) threshold configuration, the master key is divided into 5 fragments, each stored on a separate key management node. Based on the tenant fingerprint information, the tenant verification token is generated through secure multi-party computation of the key management nodes. Secure multi-party computation allows multiple participants to jointly compute a function while maintaining the privacy of their respective inputs. The key management nodes are used as computing participants, with each node holding its own key fragment. During the computation, only intermediate results are exchanged between nodes, and the respective key fragments are not exposed. The threshold signature protocol is used in the specific implementation, and at least t nodes participate in the computation to generate a valid signature. The result of the secure multi-party computation is a tenant verification token signed using the reconstructed master key, containing information such as tenant identification, security level, resource range, and usage restrictions. For example, a certain enterprise tenant's verification token contains the tenant identification "t123456", a security level of 4 (the highest level among 1-5), information about the allowed resource range and working time constraints, etc. The tenant verification token and the access token are combined and encrypted to generate an enhanced access token. The HMAC-SHA256 algorithm is used in the combination process, with the access token as the message and the tenant verification token as the key to generate an authentication code. Then, the access token, tenant verification token, and authentication code are concatenated, and the AES-256-GCM algorithm is used for encryption to generate the final enhanced access token. The enhanced access token uses a hierarchical structure, with the outer layer being the transmission encryption layer and the inner layer containing the original access token, tenant verification token, and integrity verification information. This structure ensures the confidentiality, integrity, and non-repudiation of the token.
[0058] The historical access data is extracted from the access logs, including user operation records in the past 90 days, to build a reinforcement learning access controller. The controller adopts a deep Q network (DQN) architecture, taking user behavior as the observation state and permission operation as the action space. The observation state is a multi-dimensional vector containing user features, time features, and behavior sequence features. User features include user roles, departments, job levels, etc.; time features include current time, workday flag, time period type, etc.; behavior sequence features include the type, frequency, and time interval of the last 10 operations. The action space defines the permission control operations that can be performed, including granting permissions, denying permissions, and requiring additional verification, etc. Each action corresponds to a permission operation decision. The deep Q network consists of three layers of neural networks, with the input layer corresponding to the state dimension, the hidden layer containing 64 neurons, and the output layer corresponding to the action space size. The experience replay mechanism is used to optimize the learning process, maintaining an experience pool with a capacity of 10000 to store state-action-reward-next state transition samples.
[0059] Real-time behavior data includes operation sequences, resource access requests, and environmental information in the current session. These data are encoded into state vectors and input into the deep Q network. The network outputs the Q value of each action, and the action with the highest Q value is selected as the permission decision. For example, when a user requests access to a sensitive database, it is identified that such operations are usually performed during working hours and the user has relevant historical records, so temporary access permission is granted. Each resource and operation combination is evaluated to generate a complete initial permission list. The permission list is represented in JSON format, containing resource identifiers, operation types, permission levels, and validity periods, etc. During the continuous learning process, the Q value is updated based on user feedback and operation results to adjust the permission policy. For example, if the user successfully completes the operation without triggering a security alert, a positive reward is given; if the operation is marked as a potential risk by security, a negative reward is given.
[0060] A hybrid method based on statistics and rules is used for initial permission list anomaly detection, and a risk score of each permission is calculated. The risk score is based on multiple factors: operation sensitivity, user historical behavior deviation, time anomaly degree, and environment risk, etc. For example, for an operation with high sensitivity, rarely performed by the user in history, and requested at non-working hours, a high risk score is assigned. Permissions with risk scores exceeding a threshold are marked as abnormal permissions. The security level and access restrictions are extracted from the tenant verification token, which are used to adjust the permission granularity and restriction conditions. For tenants with high security level, coarse-grained permissions (such as "file management") are subdivided into multiple fine-grained permissions (such as "file read", "file create", etc.). Time limit conditions are also added to abnormal permissions according to the time constraints in the tenant verification token. For example, a certain database modification permission is limited to use within working hours 9:00-17:00, and requires secondary verification for each use. The final fine-grained permission list is more detailed and stricter than the initial permission list, especially for high-risk operations.
[0061] The session identifier is a 128-bit random identifier that uniquely identifies the user's current access session. The session identifier is generated using the HMAC-SHA256 algorithm with the enhanced access token and the hash value of the permission list as input. This ensures that the session identifier is bound to a specific user, a specific tenant, and a specific set of permissions, preventing session hijacking and replay attacks. The session identifier is stored in the distributed cache along with the authentication and authorization information. The authentication and authorization information includes the enhanced access token, the fine-grained permission list, the session creation time, and the expiration time, etc. The distributed cache uses a consistent hashing algorithm to distribute data across multiple nodes, improving read-write performance and availability. The key of the cache item is the session identifier, and the value is the encrypted authentication and authorization information package. The cache content is encrypted using the AES-256-GCM algorithm, and the key is distributed to the authorized service nodes through a secure channel. The cache item is set with an appropriate expiration time, usually consistent with the validity period of the access token. When the user requests access to a protected resource, the session identifier is verified, and the authentication and authorization information is retrieved from the cache to determine whether to allow access based on the fine-grained permission list.
[0062] In an optional implementation, the step of generating a tenant key proof based on a zero-knowledge proof protocol and the tenant key threshold comprises:
[0063] A tenant security level and a tenant resource sensitivity associated with the tenant identifier are obtained; a reference security value is generated according to the tenant security level, and a resource sensitivity coefficient is generated according to the tenant resource sensitivity; a tenant key threshold is generated based on the reference security value, the resource sensitivity coefficient, and a dynamic adjustment factor, wherein the dynamic adjustment factor is calculated according to a real-time security threat level, a number of tenant authentication failures, and a weighted history attack frequency;
[0064] The zero-knowledge proof parameter is generated based on preset elliptic curve parameters, and an interactive commitment value is generated by using the zero-knowledge proof parameter and a tenant private key;
[0065] A tenant identity commitment is generated according to the tenant private key and the interactive commitment value, a threshold satisfaction proof is constructed by using the tenant key threshold and the interactive commitment value, an auxiliary random value is generated based on a preset group order, the tenant identity commitment, the threshold satisfaction proof and the auxiliary random value are combined to generate a zero-knowledge proof, and parameter verification is performed on the zero-knowledge proof. When the verification is passed, a tenant key proof is generated based on the zero-knowledge proof, the interactive commitment value and the tenant private key.
[0066] For example, the tenant security level is obtained based on the following multi-dimensional quantitative indicators: data importance (accounting for 30%), number of access sensitive APIs (accounting for 25%), compliance requirement level (accounting for 25%), and business criticality (accounting for 20%). After standardizing these indicators, weighted calculation is performed, and mapping is performed to three levels of high (80-100 points), medium (50-79 points) and low (0-49 points), and the corresponding benchmark security values are 100, 60 and 30 respectively. The tenant resource sensitivity is quantified by a resource classification evaluation framework, which considers data privacy level (GDPR classification standard), regulatory compliance requirements and potential impact of data leakage, to generate four levels of extremely sensitive (coefficient 2.0, such as containing payment information), high sensitive (coefficient 1.5, such as personal identification information), medium sensitive (coefficient 1.2, such as user preference data) and low sensitive (coefficient 1.0, such as public information).
[0067] The dynamic adjustment factor considers three dimensions: real-time security threat level, tenant authentication failure number and historical attack frequency. The real-time security threat level is evaluated in real time by an anomaly detection algorithm of security monitoring, and the severity of the detected abnormal behavior is converted into a standardized value between 0 and 1. For example, when a large amount of abnormal traffic is detected in the network, the value can be set to 0.8; the tenant authentication failure number is converted into a weight value between 0 and 1 by using an exponential decay function f(x)=1-e^(-x / 5), where x is the number of failures in the last 24 hours; the historical attack frequency is based on the attack records against the tenant in the past 30 days, and the weight is calculated by a normalization function g(y)=min(y / 20,1), where y is the number of attacks. The three dimensions are linearly combined with weights of 0.4, 0.3 and 0.3 respectively to obtain the final dynamic adjustment factor.
[0068] The tenant key threshold = benchmark security value x resource sensitivity coefficient x (1 + dynamic adjustment factor). This ensures that the key threshold can be dynamically adjusted according to the security requirements.
[0069] To generate the zero-knowledge proof parameters, operations are performed based on preset elliptic curve parameters (such as the secp256k1 curve). First, two base points are generated: the main base point G and the auxiliary base point H, where H is calculated by a secret random number h and G (H = h x G). These points constitute a set of zero-knowledge proof parameters. An interactive commitment value comm is generated using these zero-knowledge proof parameters and the tenant private key sk, specifically calculated as comm = sk x G + r x H, where r is a generated random obfuscation factor. The interactive commitment value enables verification operations without directly exposing the private key.
[0070] According to the tenant private key sk and the above-generated interactive commitment value comm, a tenant identity commitment id_comm is constructed, calculated as id_comm = SHA-256(sk || comm). Then, the tenant key threshold threshold calculated earlier and the interactive commitment value comm are used to construct a threshold satisfaction proof proof_threshold. This threshold satisfaction proof proves that the security strength value of the tenant private key (calculated as V = SHA-256(sk) mod (2^32)) is greater than or equal to the required threshold threshold without revealing the actual V value. At the same time, based on the preset elliptic curve group order n, an auxiliary random value aux is generated, selected within the range of 1 to n-1. The tenant identity commitment id_comm, the threshold satisfaction proof proof_threshold, and the auxiliary random value aux are combined into a standardized data structure to generate a complete zero-knowledge proof proof. The specific combination method is: id_comm, proof_threshold, and aux are serialized in order and spliced, and a type identifier and a length prefix are added to form a DER format proof data that conforms to the ASN.1 encoding rules. This structured proof format ensures that each component can be accurately identified and processed during verification, while ensuring the integrity and tamper resistance of the proof. This zero-knowledge proof contains enough information to verify the authenticity of the tenant identity and the compliance of the security level, while protecting the security of the tenant private key.
[0071] To verify the validity of the zero-knowledge proof, the verification includes: checking whether id_comm is correctly constructed, whether proof_threshold conforms to the range proof verification algorithm, and whether aux is within the valid range. After verification, using the HMAC-SHA256 algorithm, the tenant private key sk as the key, and the zero-knowledge proof proof and the interactive commitment value comm as the message content, the final tenant key proof key_proof = HMAC-SHA256(sk, proof || comm) is generated.
[0072] The application can provide differentiated protection for tenants with different security levels by dynamically adjusting the key threshold, and automatically adjust the security policy according to real-time security threats. The application of zero-knowledge proof ensures identity verification without revealing sensitive information, effectively preventing man-in-the-middle attacks and credential theft risks. The method significantly improves the security verification strength in a multi-tenant environment, while reducing the trust dependence in traditional methods, providing higher-level security protection and compliance support for sensitive business scenarios.
[0073] In an optional embodiment, the master key is stored in the key management node, and the step of generating a tenant verification token based on the tenant fingerprint information through secure multi-party computation of the key management node includes:
[0074] The master key is stored in multiple key management nodes through a hierarchical dynamic threshold scheme, and the threshold value and the total number of nodes of the hierarchical dynamic threshold scheme are determined according to the load intensity and communication efficiency of the key management nodes; the key management nodes are divided into multiple hierarchical groups based on node computing capacity scores and network topology distances; a nested polynomial structure is constructed for each hierarchical group, wherein the constant term of the inner polynomial is set to the master key value, and the coefficients of the outer polynomial are determined by the weighted values of the tenant's access behavior credibility and resource call frequency; a unique key fragment is generated for each key management node according to the constructed polynomial and stored;
[0075] After the tenant fingerprint information is processed for privacy protection, the key fragments in each of the key management nodes perform differential privacy calculation in the homomorphic encryption domain, and execute distributed zero-knowledge proof to generate a tenant verification token.
[0076] In combination Figure 2 The key fragment storage and verification token generation technical flowchart is described, for example, the load intensity index of each key management node is calculated, which is derived by monitoring the weighted average of the CPU usage, memory occupancy and network bandwidth utilization of the node. For example, the CPU usage of a node is 65%, the memory occupancy is 70%, and the network bandwidth utilization is 50%, and the weights are set to 0.4, 0.3 and 0.3 respectively, then the load intensity of the node is 65% x 0.4 + 70% x 0.3 + 50% x 0.3 = 62%. At the same time, the communication efficiency between nodes is measured, including the average response time and data transmission rate. For a node pair with a response time of 15 milliseconds and a data transmission rate of 80 MB / s, the communication efficiency score is calculated as 85 points (full score 100 points).
[0077] The threshold value determination step sets the basic threshold proportion to 30% with load intensity and communication efficiency as key input parameters, and dynamically adjusts according to the load intensity index. The specific adjustment method is: when the average load intensity rises by 5 percentage points, the threshold value increases by 2% of the number of nodes. At the same time, considering the influence of communication efficiency, for the network environment with a communication efficiency score of less than 70 points, an additional 3% threshold value is added to cope with network partition and communication delay. For example, in a network environment containing 100 key management nodes, the average load intensity is 75%, and the communication efficiency score is 65 points, the basic threshold value is 30, the load intensity contribution increment is (75%-60%) / 5% x 2% x 100=6, the communication efficiency contribution increment is 3% x 100=3, and the final threshold value is 30+6+3=39. The determination of the total number of nodes is also based on load intensity and communication efficiency, and the required number of nodes is calculated by a resource estimation function. This function compares the peak business load with the processing capacity of a single node to obtain the basic node demand, and then increases the redundant nodes according to the communication efficiency score. For example, for a business with an estimated peak of 1000 key operations per second and a single node processing capacity of 15 times per second, the basic node demand is 1000 ÷ 15 ≈ 67, and if the communication efficiency score is 80 points, a 25% redundancy rate is set, and the final total number of nodes is determined to be 67 x (1+25%) ≈ 84, rounded to 85 nodes.
[0078] The computing power of the key management node is obtained by scoring through standardized encryption operation speed testing. In the test, a fixed number of RSA encryption and decryption operations and symmetric encryption operations are performed on each node, the completion time is recorded and converted into a standard score. For example, a node completes 10,000 RSA-2048 encryption operations in 2 seconds, obtaining a computing power score of 92 points. At the same time, the network topology distance between nodes is measured, which is calculated by the average round-trip time and network hop count between nodes. For example, the round-trip time from node A to node B is 8 milliseconds, and the network hop count is 3, so the topology distance between them is rated as "short distance".
[0079] Based on the above computing power score and network topology distance, a hierarchical clustering algorithm is used to divide the key management nodes into multiple hierarchical groups. For example, for 100 nodes, they can be divided into 4 hierarchical groups: the first level contains 20 high-performance core nodes (score 90-100 points); the second level contains 30 medium-high-performance nodes (score 80-89 points); the third level contains 30 medium-performance nodes (score 70-79 points); and the fourth level contains 20 basic-performance nodes (score 60-69 points). The network topology distance between nodes in each hierarchical group is short, ensuring efficient communication.
[0080] The inner polynomials of the nested polynomial structure are implemented by the Shamir secret sharing scheme, which is a t-1 order polynomial, where t is the inner threshold value. The constant term of the inner polynomial is set as the master key value, such as a 256-bit master key, and the other coefficient terms are randomly generated values. Taking 30 as the inner threshold value as an example, a 29-order polynomial is constructed, the constant term is set as the master key value, and 29 random coefficients are generated to fill the other terms of the polynomial. The outer polynomial is constructed separately for each hierarchical group. For the i-th hierarchical group, a ni-1 order polynomial is constructed, where ni is the threshold value of the level. The constant term of the outer polynomial is set as the value of the inner polynomial at the identification point of the level.
[0081] When calculating the coefficients of the outer polynomial, the access behavior credibility and resource call frequency of the tenant are considered. The access behavior credibility is calculated by analyzing the consistency of the tenant's historical access behavior, the anomaly detection result and the identity verification success rate, with a value range of 0 to 1. For example, a certain tenant has consistent access patterns in the past 30 days, no abnormal behavior, and an identity verification success rate of 98%, so its access behavior credibility is rated as 0.92. The resource call frequency is obtained by recording the number of resource calls by the tenant and comparing it with the average level. For example, a certain tenant has an average of 15 API calls per minute in the past 24 hours, while the average level is 10 calls per minute, so its standardized resource call frequency is 1.5.
[0082] The access behavior credibility and standardized resource call frequency are calculated by weighted average to obtain the weight factor. The weight calculation formula is: weight factor = access behavior credibility x 0.6 + standardized resource call frequency x 0.4. For the above tenant, weight factor = 0.92 x 0.6 + 1.5 x 0.4 = 1.152. The weight factor is converted to the coefficient value of the outer polynomial by a mapping function, ensuring that the key fragments generated by the high credibility tenant are more stable and reliable.
[0083] A unique identification value is assigned to each key management node, which is substituted into the outer polynomial of the corresponding hierarchical group to calculate the key fragment of the node. For example, the node identified as 42 in the second level has a key fragment value equal to the function value of the second level outer polynomial at x = 42. The key fragments are securely transmitted to each node through a TLS encrypted channel, and each node receives the key fragments and stores them using the local key of the node, and sets access control policies to limit the operation permissions of the key fragments.
[0084] In processing tenant fingerprint information, first, privacy protection processing is performed. The device features, behavior patterns and access history data in the tenant fingerprint information are extracted, and a feature hashing technology is applied to convert the fingerprint information into a fixed-length feature vector. For sensitive information such as IP addresses, a fuzzing process is applied to convert the accurate IP address into regional-level information. For device identifiers, a salted hash process is used and random perturbation is added. For access time patterns, the accurate time points are converted into time period distribution statistical information. For example, the accurate pattern of "accessing at 9:05 every day" is converted into the fuzzy feature of "high frequency of morning access on weekdays".
[0085] The processed tenant fingerprint information is encrypted and distributed to the key management nodes participating in the calculation. A homomorphic encryption scheme is adopted, so that the data can still be calculated in the encrypted state. Each node uses the key shard it holds to perform homomorphic operations on the encrypted fingerprint information to obtain partial verification results. In the calculation process, the node introduces random noise subject to Laplace distribution to achieve differential privacy protection. For example, for a certain statistical value v, the node adds Laplace noise with a mean of 0 and a scale parameter of △f / ε, where △f is the sensitivity and ε is the privacy budget, usually set to a value between 0.1 and 1.
[0086] After each node completes the homomorphic calculation with differential privacy, a distributed zero-knowledge proof protocol is executed. Each node generates a partial proof based on its own key shard, proving that it has correctly performed the calculation process and holds a valid key shard, while not revealing the content of the key shard. When a sufficient number of valid partial proofs are collected, these partial proofs are combined through an aggregation algorithm to generate a complete tenant verification token. The token contains the tenant identity, access permission range, validity period and collective signature of the key management nodes, and can be verified but difficult to forge.
[0087] The present application realizes high-security distributed storage of master keys through a hierarchical dynamic threshold scheme and a nested polynomial structure, effectively preventing single-point failures and internal threats. This scheme significantly improves the identity verification strength in a multi-tenant environment while maintaining good performance and scalability, providing higher-level security assurance for sensitive business scenarios.
[0088] In an optional implementation, after the tenant fingerprint information is processed for privacy protection, the steps of generating a tenant verification token through the key shards in each of the key management nodes for calculation in the homomorphic encryption domain with differential privacy and executing a distributed zero-knowledge proof include:
[0089] Identity feature vectors and behavior feature vectors are extracted from the tenant fingerprint information, and linear transformation is performed to generate feature segments in a privacy-protected form;
[0090] The feature segments are sent to a plurality of the key management nodes, each of the key management nodes performs a homomorphic inner product operation on a key fragment held by the key management node and the feature segments in an encryption domain, and introduces differential privacy noise of a Laplace distribution in a result of the homomorphic inner product operation to obtain a partial verification factor;
[0091] A calculation weight of each of the key management nodes is determined according to the credibility of the key management node, and the calculation weight and the corresponding partial verification factor are subjected to a secure multi-party summation operation to generate an aggregated verification value;
[0092] When the number of the key management nodes participating in the secure multi-party summation operation reaches a preset threshold value, the key management nodes perform a distributed zero-knowledge proof protocol to verify a calculation process of the aggregated verification value, and combine a hash value of the identity feature vector and the aggregated verification value that passes the verification to generate a tenant verification token.
[0093] For example, the identity feature vector extracted from the tenant fingerprint information includes static identity features such as device hardware identification, account history information and authentication credential features, and is usually constructed as a 128-dimensional vector. For example, the device hardware identification of a certain tenant includes a processor serial number hash value, a network adapter MAC address hash value and a hard disk serial number hash value; the account history information includes account creation time, historical login location distribution and password modification frequency; and the authentication credential features include biometric feature templates, two-factor authentication usage patterns and the like. The behavior feature vector includes dynamic behavior features such as access patterns, operation habits and resource usage preferences, and is usually constructed as a 64-dimensional vector. For example, the access patterns of a certain tenant include daily access time period distribution, session duration average value and page access order features; the operation habits include keyboard input rate, mouse movement features and function module usage preferences; and the resource usage preferences include commonly used API call distribution, data access frequency and query pattern features.
[0094] The extracted feature vectors are formed into feature segments through a random projection matrix, which is generated according to a secure seed value and has a dimension twice that of the original feature vector. The 128-dimensional identity feature vector and the 64-dimensional behavior feature vector are combined into a 192-dimensional joint feature vector, which is transformed using a 384x192-dimensional random projection matrix to obtain a 384-dimensional transformed vector. The vector is uniformly divided into a plurality of feature segments, and the number of the feature segments is the same as the number of the key management nodes participating in the calculation. For example, if there are 12 key management nodes participating in the calculation, each node is allocated a 32-dimensional feature segment. The linear transformation process preserves the similarity relationship of the original features, while making it impossible to reverse the original feature information from a single feature segment, thereby achieving data privacy protection.
[0095] The feature fragment is sent to multiple key management nodes through a TLS 1.3 encrypted channel. Each node uses Paillier homomorphic encryption processing to receive the feature fragment, supporting addition and scalar multiplication operations in the ciphertext state. After receiving the 32-dimensional encrypted feature fragment, the node can perform calculations without decryption. The node locally stores a corresponding 32-dimensional key slice value. The node performs a homomorphic multiplication operation on each dimension of the encrypted feature value a number of times equal to the key slice value, which is equivalent to completing the multiplication of the feature value and the key slice value in the encrypted state. After completing the multiplication operation of the 32-dimensional data, the node uses the additive property of homomorphic encryption to perform a homomorphic addition operation on the 32 encrypted product results to obtain the final homomorphic inner product encryption value.
[0096] After calculating the homomorphic inner product value, the key management node introduces differential privacy noise subject to Laplace distribution into the result. The node first calculates the sensitivity of the homomorphic inner product operation, which is the maximum output change caused by a single input change. For a 32-dimensional feature fragment and key slice, if the value range of each dimension is 0-1, the sensitivity calculation value is 32. The node generates random noise subject to Laplace distribution according to the preset privacy budget ε (usually set to a value between 0.5-1) and the sensitivity. The noise proportion parameter is set to the sensitivity divided by the privacy budget value, for example, the sensitivity is 32 and the privacy budget is 0.8, then the noise proportion parameter is 40. The noise generated by the node is added to the homomorphic inner product operation result to form a partial verification factor. The differential privacy noise ensures that even if an attacker obtains multiple calculation results, the original feature information cannot be accurately inferred.
[0097] The credibility of the key management node is obtained through comprehensive evaluation of historical performance, hardware security level and network environment security. The historical performance includes node running stability, response time consistency and past verification result accuracy; the hardware security level evaluates whether the node is equipped with a trusted execution environment, a secure encryption chip and other security hardware; the network environment security considers the protection level of the network where the node is located and the historical security events. The node credibility is converted to a calculation weight value between 0 and 1, and nodes with higher credibility obtain higher weights. For example, the credibility scores of three nodes are 95, 88 and 82 respectively, and the normalized calculation weights are 0.36, 0.33 and 0.31 respectively.
[0098] Each key management node uses a calculation weight and a corresponding partial verification factor to perform a secure multi-party summation operation. A secret sharing mechanism is used, and each node multiplies its own partial verification factor with the calculation weight to obtain a weighted verification factor. The node decomposes the weighted verification factor into a sum of multiple random values, retains one of them, and encrypts the other random values and transmits them to other nodes participating in the calculation. Each node aggregates all the received random values and the random value retained by itself to obtain a local aggregation result. The local aggregation results of all nodes are added to obtain the final aggregated verification value. This process ensures that any single node cannot obtain the partial verification factors of other nodes.
[0099] When the number of key management nodes participating in the secure multi-party summation operation reaches a preset threshold value, a distributed zero-knowledge proof protocol uses a non-interactive proof. The proving party (each key management node) proves that it has correctly performed the verification calculation and holds a valid key shard, without revealing the content of the key shard. Each node generates a proof of the calculation process, including a feature fragment receiving proof, a homomorphic inner product calculation proof, and a differential privacy addition proof. Other nodes verify the validity of these proofs to ensure the integrity and correctness of the calculation process. For example, the proof generated by a certain node indicates that the node indeed received the allocated 32-dimensional feature fragment, correctly performed the homomorphic inner product calculation, and added the differential privacy noise as specified.
[0100] After verification, the aggregated verification value is combined with the hash value of the identity feature vector to generate a tenant verification token. A secure hash algorithm (such as SHA-256) is used to calculate the hash value of the identity feature vector, producing a fixed-length unique identifier. This identifier is combined with the aggregated verification value, a timestamp, and access permission level information, and signed using the collective signature of the key management nodes participating in the calculation to generate the final tenant verification token. The tenant verification token structure includes: token header (version information, algorithm identifier, token type), payload (identity, verification value, issuance time, expiration time, permission range), and signature part (node collective signature). The generated tenant verification token can be verified but is difficult to forge.
[0101] The present application realizes privacy protection of tenant fingerprint information through feature vector extraction and linear transformation, guarantees data privacy during calculation through homomorphic encryption and differential privacy, prevents single-point attack risks through key shard and secure multi-party calculation mechanism, and ensures the security and correctness of the verification process through distributed zero-knowledge proof. The overall design forms a multi-level protection system, significantly improves the identity verification security in a multi-tenant environment, protects tenant privacy, and provides a highly secure identity verification solution for sensitive business scenarios.
[0102] In an alternative embodiment, based on the historical access data, a reinforcement learning access controller is constructed, taking user behavior as an observation state and permission operation as an action space; collecting real-time behavior data of the user, the access controller continuously learns based on the real-time behavior data, and the step of generating an initial permission list comprises:
[0103] Temporal features, behavior features and environmental features are extracted from the historical access data, and standardized features are obtained by standardizing the features after segmenting through a sliding time window;
[0104] A reinforcement learning access controller is constructed, the standardized features are combined into a user state vector, the user state vector includes a temporal feature vector, a behavior feature vector and a context feature vector, the granting, revoking and maintaining operations of permissions are constructed as an action space, and a composite reward function is constructed based on a security compliance reward, an access efficiency reward and a risk penalty term;
[0105] Real-time behavior data of the user is collected, and a real-time feature vector is obtained by using an attention mechanism to sequence encode the real-time behavior data of the user, the attention mechanism processes the current query vector and the historical behavior key-value pair; the access controller continuously learns based on the real-time feature vector, updates the access control policy through policy gradient, and calculates the action value based on the value function estimation;
[0106] The confidence of each permission is calculated based on the action value and the consistency of historical behavior, the confidence is filtered based on a preset filtering threshold, and conflict resolution is performed using a permission dependency graph to generate an initial permission list.
[0107] For example, temporal features include user access time distribution, operation interval pattern and session duration, and other time-related features. For example, for the historical access data of a user in a technical department, the temporal feature extraction includes a working day access frequency of 35 times per day, a non-working day access frequency of 5 times per day, an access proportion from 9am to 12pm of 45%, an access proportion from 1pm to 6pm of 50%, and a late-night access proportion of 5%, and a typical session duration of 45 minutes. Behavior features include operation type distribution, access resource category and interaction mode, and other features that describe user behavior habits. For example, the user's resource library access proportion is 60%, the document access proportion is 25%, the monitoring access proportion is 15%, the submit operation to query operation ratio is 1:4, and the keyboard operation to mouse operation ratio is 3:1. Environmental features include access location, device type and network environment, and other context information. For example, 95% of the user's access comes from the enterprise intranet, 5% comes from VPN connection, 85% uses a workstation for access, and 15% uses a mobile device for access.
[0108] The extracted features are processed by sliding time windows. The time window is set to 7 days, and the sliding step is 1 day, that is, each window contains 7 consecutive days of data, and adjacent windows overlap for 6 days. The features in each time window are aggregated and statistics are calculated, such as the mean, standard deviation, maximum, minimum, and quantile of the features. For example, the average access frequency in a certain time window is 30 times per day, the standard deviation is 5 times, the maximum is 42 times, the minimum is 20 times, and the 75% quantile is 35 times. The aggregated features are standardized to map the feature values to the same numerical range and eliminate the dimensional differences. Standardization uses the z-score method, which subtracts the mean from the original feature value and divides by the standard deviation, so that the processed feature mean is 0 and the standard deviation is 1. For example, the original access frequency is 35 times, the mean is 30 times, and the standard deviation is 5 times. The standardized value is (35-30) / 5=1. Through standardization, a standardized feature set is obtained, which is used for subsequent construction of a reinforcement learning model.
[0109] A reinforcement learning access controller is constructed, and the standardized features are combined into a user state vector. The user state vector is composed of three parts: a time series feature vector, a behavior feature vector, and a context feature vector. The time series feature vector has a dimension of 24, including access frequency, operation interval distribution, and session duration statistics in each time period; the behavior feature vector has a dimension of 32, including operation type distribution, resource access mode, and interaction behavior features; and the context feature vector has a dimension of 16, including location encoding, device type encoding, and network environment features. The three feature vectors are connected to form a 72-dimensional user state vector, which is used as the state space of reinforcement learning. The granting, revoking, and maintaining operations of permissions are constructed as the action space. For each of the 50 basic permissions, there are three operations of granting, revoking, and maintaining, which constitute 150 basic actions.
[0110] In the composite reward function, the safety compliance reward calculation formula is: safety compliance = 1 - (number of granted permissions - minimum number of permissions required for responsibilities) / total number of permissions. The value ranges from 0 to 1, and the higher the value, the more the permission configuration conforms to the principle of least privilege. For example, a user's responsibilities require 12 permissions, and 15 permissions are currently granted, with a total of 50 permissions, the safety compliance is 1 - (15-12) / 50 = 0.94. The access efficiency reward calculation formula is: access efficiency = baseline completion time / actual completion time. The baseline completion time is based on historical data statistics, representing the average time for a user with an ideal permission configuration to complete a specific task. For example, the baseline time for a resource review task is 30 minutes, and the user's actual completion time is 35 minutes, so the access efficiency is 30 / 35 = 0.857. The risk penalty term is calculated based on the permission risk score: risk penalty = sum of risk scores of all granted permissions / maximum risk score. The risk score of each permission is predefined according to its sensitivity and potential impact, ranging from 1 to 10. For example, if the total risk score of the granted permissions is 25, and the maximum risk score is 500, then the risk penalty is 25 / 500 = 0.05. The composite reward function combines these three indicators by weighting: composite reward = 0.3 x safety compliance + 0.2 x access efficiency - 0.5 x risk penalty. The weight ratio of 3:2:5 reflects the priority of security risk control over compliance and efficiency.
[0111] Real-time behavior data of the user is collected, including operation sequences in the current session, resource access requests, and environmental information, etc. For example, a user successively accesses project management, resource library, and build in the current session, submits an update and triggers the build process. Real-time feature vectors are obtained by using attention mechanism to sequence encode the real-time behavior data of the user. The attention mechanism is implemented as follows: the current operation is encoded into a query vector with a dimension of 32; the historical operations are encoded into a set of key vectors, each with a dimension of 32; and the corresponding context information is encoded into a set of value vectors, each with a dimension of 48. The dot product of the query vector and each key vector is calculated, and a scaling factor is used for adjustment, which is the square root of the dimension of the key vector. An exponential function is applied to the adjusted dot product result, and the sum of all exponential values is obtained. The attention weight of each key is equal to the exponential value corresponding to the key divided by the sum, ensuring that the sum of all weights is 1. Finally, the attention weights are weighted and summed with the corresponding value vectors to obtain the context-aware real-time feature representation. For example, when the user performs a resource submission operation, the similarity between this operation and historical operations is calculated, and it is found that the similarity with a similar resource submission operation three months ago is 0.85, and the similarity with a configuration modification operation last week is 0.35. Accordingly, the attention weights are allocated as 0.78 and 0.22, respectively, and the generated real-time feature vector retains more context information of the similar resource submission operation.
[0112] Two neural networks are used: a policy network and a value function network. The policy network input is a real-time feature vector, and the output is a probability distribution of each action. The network structure includes three fully connected layers with hidden layer dimensions of 128 and 64, respectively, using ReLU activation functions, and the output layer uses a Softmax function to ensure the probability sum is 1. The value function network input is also a real-time feature vector, and the output is a state value estimate. The network structure includes two fully connected layers with a hidden layer dimension of 64, using ReLU activation functions. The policy gradient update uses the REINFORCE algorithm, and the specific formula is: for each permission operation a, the policy network parameters are updated in the direction of the cumulative reward G multiplied by the action a's logarithmic probability gradient, multiplied by the learning rate a. In practice, the learning rate a = 0.001 is used, and a baseline is introduced to reduce variance, with the baseline being the state value predicted by the value function network. The value function network is updated through time difference learning, with the goal of minimizing the mean square error between the predicted value and the actual cumulative reward. The learning rate is set to 0.01, and the discount factor γ = 0.95. Network parameters are updated every 50 user sessions, using mini-batch gradient descent with a batch size of 32. For example, when it is observed that granting a user resource review permission allows the user to complete work more efficiently without causing security problems, the actual composite reward is 0.75, which is higher than the expected 0.65, and the probability of granting this permission in similar states is increased, and the corresponding parameters of the policy network are increased by about 0.001 × (0.75 - 0.65) × 0.08 = 0.0008 (assuming the logarithmic probability gradient is 0.08).
[0113] The action value is estimated by the value function network, representing the expected cumulative reward of performing a specific action in the current state. The historical behavior consistency measures the degree of conformity of the current action to the user's historical behavior pattern, and the calculation formula is: historical behavior consistency = current action frequency in history × 0.4 + cosine similarity of current action and historical high-frequency action × 0.6. The frequency statistics use the behavior data of the last 30 days, and the cosine similarity is calculated through the vector representation of the action. The action value and the historical behavior consistency are weighted and summed in a 7:3 ratio to obtain the confidence of each permission operation. For example, for a user's resource library read permission, if the action value is 0.85 and the historical behavior consistency is 0.90, the confidence of the permission is 0.85 × 0.7 + 0.90 × 0.3 = 0.865.
[0114] For general permissions, the filtering threshold is set to 0.7; for high sensitivity permissions, the threshold is set to 0.85, ensuring that only high confidence cases are granted sensitive permissions. Conflict resolution is performed using a permission dependency graph, which is a directed graph where nodes represent permissions and edges represent relationships between permissions. The permission dependency graph is represented using an adjacency matrix, with matrix element values of: 1 for dependency relationship (the former depends on the latter), -1 for mutual exclusion relationship, and 0 for no relationship. For example, a 50x50 adjacency matrix is constructed for 50 permissions. The permission dependency graph is pre-built based on design and business rules, and can be updated through runtime learning. The conflict resolution algorithm is as follows: for the filtered permission list, first check the dependency relationship and build a permission dependency tree. Starting from the leaf node, check if the dependency of each permission is included in the list, and if not, add the dependency. For example, if the resource deletion permission (permission ID 15) depends on the resource write permission (permission ID 10), but only the deletion permission is identified and the write permission is not identified, check the adjacency matrix element matrix
[15]
[10] =1 to confirm the dependency relationship, and automatically add the write permission. After adding the dependency, check the mutual exclusion relationship and build a conflict set. For each pair of mutually exclusive permissions, keep the one with higher confidence. For example, if the tenant administrator role (permission ID 30) and the tenant normal user role (permission ID 31) are mutually exclusive, the adjacency matrix element matrix
[30]
[31] =matrix
[31]
[30] =-1, and the confidence of the two is 0.82 and 0.78 respectively, the administrator role is kept and the normal user role is removed. When there are multiple complex situations of mutual dependency or mutual exclusion, a graph traversal algorithm is used to find the optimal solution. First, build a permission conflict graph, then use the maximum weight independent set algorithm to find the permission set with the highest total confidence and no conflict. The algorithm uses a greedy strategy, selecting the permission with the highest confidence and no conflict with the selected permissions each time to join the result set. Through dependency graph processing, the final initial permission list is generated, ensuring the completeness and consistency of the permission configuration.
[0115] The present application realizes adaptive permission control based on user behavior through reinforcement learning technology, effectively solving the problems of over-authorization and permission management complexity in traditional permission management. It can continuously learn user behavior patterns and adjust permission policies in real time, improving user work efficiency while ensuring security. Through the application of attention mechanism and permission dependency graph, it can more accurately capture user intent and permission relationships, generate reasonable and safe permission configurations, and significantly reduce security risks and management costs.
[0116] In an optional implementation, the step of continuously learning based on the real-time feature vector by the access controller comprises:
[0117] inputting the real-time feature vector into a dual-channel neural network of the access controller, a first channel constructing a local policy network to extract short-term behavior features, and a second channel constructing a global policy network to extract long-term behavior patterns;
[0118] calculating a policy gradient of the access control policy based on outputs of the local policy network and the global policy network, the policy gradient evaluating historical decision trajectories through importance sampling and introducing an entropy regularization term;
[0119] constructing a dual-value function to calculate the action value, the dual-value function respectively estimating an immediate reward value and a long-term reward value, and guiding an update direction of the access control policy through a time difference error;
[0120] setting an adaptive learning rate based on a confidence interval theory, automatically adjusting a learning step when a user behavior distribution change caused by the update of the access control policy exceeds a preset confidence interval, and ensuring stable convergence of the access control policy.
[0121] For example, the access controller receives a 48-dimensional real-time feature vector as input and passes it to a dual-channel neural network for processing. The dual-channel neural network includes two parallel processing paths: a local policy network and a global policy network. The local policy network focuses on extracting short-term behavior features of the user, adopts a three-layer fully connected network structure, and the hidden layer dimensions are 64 and 32, respectively, with a ReLU activation function. The input layer of the local policy network receives the complete 48-dimensional real-time feature vector, which is linearly transformed by a weight matrix and a bias term and then processed by an activation function to generate a 64-dimensional intermediate feature representation. These intermediate features are further processed by the second layer weight transformation and activation processing to obtain a 32-dimensional local behavior feature representation. The last layer maps the features to the action space, and the output dimension is equal to the number of actions (e.g., 150 basic actions). The local policy network focuses on the user behavior patterns in the last 7 days, and gives higher weights to features with strong timeliness. For example, for a user's recent frequent access to a resource library, the local policy network will generate a policy output that tends to grant access to the resource library.
[0122] The global policy network is responsible for extracting long-term behavior patterns, adopts a recurrent neural network structure containing memory units, and can capture the long-term dependence of user behavior. The global policy network first passes the 48-dimensional real-time feature vector through an embedding layer with a dimension of 32, and then inputs it into a bidirectional gated recurrent unit containing 64 memory units. The recurrent unit processes the input sequence bidirectionally, with forward propagation capturing information flow from the past to the present, and backward propagation capturing dependence from the present to the past. The time window of the global policy network is set to 90 days, effectively remembering the user's long-term stable behavior characteristics through the recurrent structure. The results of bidirectional processing are merged into a 64-dimensional global feature representation, which is then mapped to the same dimension of the action space through a fully connected layer. The global policy network is more sensitive to long-term stable behavior patterns related to user roles, for example, the code review behavior exhibited by technical managers over a long period of time will be identified as a stable feature, even if such operations are not performed in the short term.
[0123] The outputs of the two networks are combined in a weighted combination with a ratio of 7:3, with the short-term behavior weight being 0.7 and the long-term behavior weight being 0.3, to obtain the comprehensive strategy output. For example, for the resource library write permission, if the local policy network outputs a grant probability of 0.82 and the global policy network outputs a grant probability of 0.65, then the comprehensive strategy output is 0.82x0.7+0.65x0.3=0.769. The importance sampling technique is used to evaluate the historical decision trajectory, and the importance weight is calculated based on the behavior distribution ratio of the current strategy and the historical strategy. In specific implementation, an experience replay buffer with a capacity of 1000 is maintained to store user historical interaction data, including state, action, reward, and next state. Each time it is updated, 128 historical trajectories are randomly sampled from the buffer, and the ratio of the likelihood probability under the current strategy to the likelihood probability under the recorded strategy is calculated as the importance weight. For example, a certain historical trajectory has a likelihood probability of 0.15 at the time of recording and a likelihood probability of 0.18 under the current strategy, so its importance weight is 0.18 / 0.15=1.2. An entropy regularization term is also introduced to encourage strategy diversity and prevent the strategy from converging to a suboptimal solution too early. The entropy regularization term calculates the entropy value of the strategy distribution and multiplies it by a weight factor (initially set to 0.01 and gradually reduced to 0.001 as training progresses) to add to the optimization objective. For highly determined permission operations, the strategy distribution tends to be deterministic, with low entropy values. For uncertain operation decisions, the strategy distribution is more dispersed, with higher entropy values.
[0124] The dual value functions estimate the immediate reward and long-term reward of the permission operation, respectively. The immediate value function adopts a three-layer fully connected network structure, and the input layer receives the combined representation of the real-time feature vector and action. The combined representation is formed by connecting the 48-dimensional real-time feature vector and the 150-dimensional action one-hot encoding vector to form a 198-dimensional input vector. Different normalization processing is applied for continuous value features and discrete encoding: the continuous features use the min-max normalization to map the values to the [0, 1] interval, and the discrete encoding maintains the one-hot representation form. The first hidden layer has a dimension of 128, the second hidden layer has a dimension of 64, and the ReLU activation function is used. The output layer is a single neuron, which uses a linear activation function to output a scalar value representing the immediate reward estimate of executing a specific action. The long-term value function adopts a similar fully connected structure, but adds an LSTM memory module after the first hidden layer, which contains 64 memory units and a time step of 10, capable of capturing long-term impact sequences of actions. The LSTM module receives the historical state-action sequence as input and extracts the temporal dependence. The input of the long-term value function includes not only the current state-action pair, but also the past 9 time steps of state-action pairs, forming a complete time window. The outputs of the two value functions are combined according to the permission sensitivity: a pre-defined permission sensitivity list is used to divide all permissions into two categories: ordinary permissions and high-sensitivity permissions. High-sensitivity permissions include 15 key operation permissions such as data deletion, user management, permission configuration, and encryption key access, with a sensitivity score greater than 7 (out of 10); the rest are ordinary permissions. For ordinary permission operations, the immediate value function weight is 0.6 and the long-term value function weight is 0.4; for high-sensitivity permission operations, the immediate value function weight is 0.4 and the long-term value function weight is 0.6, giving more weight to long-term security impact. Time difference error is used to guide policy update, which is calculated as the actual reward plus the discounted next state value function estimate, minus the current state value function estimate. The discount factor is set to 0.95, indicating the degree of emphasis on future rewards. The mean square error loss function is constructed to minimize the time difference error, and the loss function is the square of the time difference error. The value function network is updated through the gradient descent algorithm, using the Adam optimizer with an initial learning rate of 0.001 and a batch size of 64. For example, if the current state value function estimate is 0.65, the reward obtained after executing a certain action is 0.3, and the next state value function estimate is 0.72, then the time difference error is 0.3 + 0.95 x 0.72 - 0.65 = 0.334. The network parameter update amount is related to this error, learning rate, and input gradient. Training stability is enhanced by target network technology, which maintains two copies of the value function: the online network and the target network. The online network is updated after each interaction, and the target network parameters are updated once every 100 interactions through soft update, with an update ratio of 0.01, i.e. 1% of the target network parameters moving towards the online network parameters.A positive time difference error indicates that the action is better than expected, and the policy update direction is to increase the probability of the action; a negative time difference error indicates that the action is worse than expected, and the policy update direction is to reduce the probability of the action. The two value functions work together, that is, the immediate value function is more sensitive to the short-term effect of the permission operation (such as access efficiency), and the long-term value function is more sensitive to the cumulative security risk, and the comprehensive judgment can balance security and ease of use.
[0125] Setting an adaptive learning rate based on the confidence interval theory can ensure the stability of policy updating. Before each policy update, the difference in behavior distribution between the current policy and the policy before updating is calculated. The behavior distribution difference is measured by the KL divergence of the action probability distribution of the two policies in the same state. The confidence interval threshold is pre-set to 0.02, representing the maximum allowed distribution variation. When the calculated KL divergence value exceeds the threshold, the learning step is automatically adjusted. The specific adjustment method is as follows: if the KL divergence value is 0.035, which exceeds the threshold 0.02, then the learning rate is multiplied by the ratio of the threshold to the actual value, that is, 0.02 / 0.035≈0.57, so that the update step is reduced. If the KL divergence value is 0.01, which is lower than the threshold, then the learning rate is multiplied by 1.1, which moderately increases the update step to speed up convergence. The initial value of the learning rate is set to 0.001, the upper limit is set to 0.01, and the lower limit is set to 0.0001, to ensure adjustment within a reasonable range. Through this adaptive mechanism, it can adapt to the learning needs at different stages while ensuring stable convergence of the policy. For users with sudden changes in behavior patterns, the learning rate will be automatically reduced to avoid overreaction; for users with stable behavior, the learning rate will be moderately increased to speed up policy optimization.
[0126] The access controller regularly evaluates the performance of the policy, and when the cumulative reward is stable or reaches a pre-set number of iterations (e.g., 1000 iterations), the current policy is saved as a checkpoint. A rollback mechanism is also implemented, which automatically rolls back to the last stable checkpoint if the new policy performs poorly (cumulative reward decreases by more than 15%) in actual application, ensuring that policy updates do not significantly degrade performance. For example, if after an update it is detected that user operation efficiency has decreased by 20% and security compliance has decreased by 10%, it will roll back to the last checkpoint and adjust the exploration strategy to try other optimization directions.
[0127] The present application realizes the comprehensive analysis of short-term behavior and long-term patterns through the dual-channel neural network structure and the adaptive learning mechanism, effectively solving the problems of response lag and over-generalization in traditional access control. The dual value function design allows simultaneous consideration of the immediate effect and long-term impact of permission operations, improving the accuracy and security of permission allocation. The adaptive learning rate mechanism ensures smooth transition when user behavior patterns change, avoiding policy shocks and overreaction.
[0128] In an alternative embodiment, the step of performing anomaly detection on the initial permission list and generating a fine-grained permission list in combination with the tenant verification token comprises:
[0129] Based on the analysis of the historical access behavior of the user on each permission in the initial permission list, a time-series access pattern is calculated, and the time-series access pattern is converted into a permission frequency feature;
[0130] The tenant access time constraint is extracted using the tenant verification token, and a permission access rule library is constructed based on a preset time-series rule template;
[0131] The permission frequency feature is matched with the permission access rule library to identify abnormal permissions that do not conform to the time-series rules. The access time of the abnormal permissions is constrained to generate a time-limited permission set, and the permission set is divided into fine-grained permissions with time constraints in combination with the security level in the tenant verification token.
[0132] For example, based on the analysis of the historical access behavior, the sliding time window is set to 14 days, and the sliding step is 1 day, i.e. each window contains 14 consecutive days of data, and adjacent windows overlap by 13 days. For each permission, multi-dimensional time-series features are extracted within the time window, including access frequency, access time distribution, and access duration, etc. The access frequency is calculated to count the number of accesses to a specific permission per day, forming a 14-dimensional daily frequency vector; the access time distribution divides the 24 hours of a day into 8 time periods (3 hours each), and the access proportion of each time period is calculated, forming an 8-dimensional time period distribution vector; the access duration calculates the average duration and standard deviation of each permission use, forming a 2-dimensional duration vector. These features are combined to form a 24-dimensional time-series feature vector. For example, for a user's resource editing permission, the following time-series features are extracted: the average access frequency on weekdays is 12 times / day, and the average access frequency on weekends is 2 times / day; the access is mainly concentrated in the time periods of 9:00-12:00 (35%) and 14:00-17:00 (40%); the average duration is 25 minutes, and the standard deviation is 8 minutes.
[0133] The temporal access pattern is converted into the permission frequency feature, and the conversion process includes three steps: feature aggregation, pattern extraction, and frequency calculation. Feature aggregation reduces the original 24-dimensional temporal feature, and uses principal component analysis to retain the principal components required to explain 90% of the variance, usually reducing to 8-10 dimensions. Pattern extraction uses a density clustering algorithm to identify high-density areas in the temporal feature space, and classifies the user's access behavior into several typical patterns. In specific implementation, the DBSCAN density clustering algorithm is used, with the parameters set as: neighborhood radius 0.35, minimum point number 5. These parameters are optimized through grid search to balance clustering quality and computational efficiency. For each identified access pattern, the frequency of occurrence is calculated, i.e. the proportion of the pattern in all observation windows. The final permission frequency feature includes the main access patterns of each permission and the corresponding frequency values. For example, for the aforementioned resource editing permission, two main access patterns are identified: one is short-time editing in the morning of weekdays (frequency 0.65), and the other is long-time editing in the afternoon of weekdays (frequency 0.30), and the rest are atypical patterns (frequency 0.05).
[0134] The tenant verification token contains tenant-level security policy information in JSON Web Token format, including tenant identifier, security level, time constraints, and resource scope fields. The time constraints field specifies the time range that the tenant allows access, including allowed weekdays, working hours, and special time periods. A typical tenant verification token structure contains tenant identifier, security level value (1-5 integer), time constraints (weekday list, working hours range, special time period), and resource scope information. Parse the tenant verification token and extract the time constraint information, and convert it to a standardized time constraint representation. For example, a certain enterprise tenant verification token contains the following time constraints: allow access from 8:00 to 20:00 on weekdays (Monday to Friday), and allow technical maintenance personnel to access specific resources from 10:00 to 16:00 on weekends in special cases. Build a permission access rule library based on preset timing rule templates. Timing rule templates are a set of predefined time pattern descriptions, including working hours patterns, non-working hours patterns, and abnormal access patterns. Each template contains two parts: time conditions (such as time period, periodicity, continuity) and behavior conditions (such as frequency threshold, duration). Combine tenant time constraints with timing rule templates to generate specific access rules for each type of permission. The rules are represented using a decision table, with behavior permission types listed as time conditions, and cell contents as allowed access behavior characteristics. For example, for resource editing permissions, the following rules are generated: normal rule - allow high-frequency access (> 10 times / day) from 9:00 to 18:00 on weekdays; limit rule - allow low-frequency access (≤ 5 times / day) from 18:00 to 22:00 on weekdays; exception rule - access from 22:00 to 9:00 the next day or all day on weekends requires additional verification. The rule library uses a decision tree structure for storage, facilitating fast querying and matching. Rule storage uses a key-value pair database, with keys as the combination of permission identifiers and time conditions, and values as the corresponding behavior conditions and processing strategies.
[0135] The permission frequency feature is matched with the permission access rule library, and the matching process uses a fuzzy logic scoring mechanism to calculate the degree of compliance between the actual use mode of each permission and the rules. The compliance score ranges from 0 to 1, and the closer to 1 indicates the greater compliance with the rules. The specific calculation method is: for each time period, calculate the cosine similarity between the user behavior feature vector and the rule requirement feature vector, and then perform a weighted average according to the importance of the time period. Calculate the compliance for each access mode of each permission and the rules in the rule library, and take the weighted average value as the overall compliance of the permission. When the compliance of the permission is lower than the preset threshold (usually set to 0.75), the permission is marked as an abnormal permission. For example, if a user's resource export permission is mainly used during non-working hours (2:00-4:00, accounting for 85% of the total use), the compliance with the normal rules in the rule library is only 0.35, which is lower than the threshold 0.75, and the permission is marked as an abnormal permission. The abnormal level division is realized, and the compliance 0.5-0.75 is defined as a low-risk abnormality, 0.25-0.5 is defined as a medium-risk abnormality, and 0-0.25 is defined as a high-risk abnormality. Different risk levels correspond to different processing strategies.
[0136] In the step of generating the time-limited permission set, the constraint generation follows the principle of least privilege, and for each abnormal permission, the most compliant time period in its historical access mode is identified, and the permission use is limited to these time periods. The constraint generation algorithm first calculates the ratio of the use frequency of the abnormal permission in each time period to the allowed frequency of the rule, and selects the time period with the closest ratio to 1 as the reference time period. Then, the allowed time period is expanded forward and backward from the reference time period until it covers 80% of the user's normal use scenarios or reaches the preset maximum time window (usually 50% of the working time). For permissions that completely do not comply with the rules, access is completely prohibited or additional verification steps are required. The time constraint uses a fine time expression, supporting complex situations such as weekday / weekend differentiation, time period limitation, and special date exceptions. For example, for the aforementioned resource export permission, the following time constraint is generated: only allow use during working hours 10:00-16:00, require two-factor authentication for each use, and no more than 3 times per day. The generated time-limited permission set uses a standardized JSON format, and each permission item contains permission identifier, resource range, operation type, time constraint, and additional conditions, etc.
[0137] The time-limited permission set is granularly divided according to the security level in the tenant verification token. The security level field in the tenant verification token defines the overall security policy strictness of the tenant, and adopts an integer value of 1-5, wherein 1 represents the lowest security level, and 5 represents the highest security level. A security level mapping table is maintained to map the security level value to a specific granular division strategy parameter: the security level 1-2 corresponds to a low security strategy, and a granularity coefficient is 0.3; the security level 3 corresponds to a medium security strategy, and the granularity coefficient is 0.6; and the security level 4-5 corresponds to a high security strategy, and the granularity coefficient is 0.9. The granularity coefficient directly affects the degree of detail of permission splitting, and the higher the coefficient, the more detailed the splitting.
[0138] A permission dependency graph is constructed based on the function correlation of permissions and operation risks. The dependency graph is a weighted directed graph, the nodes represent permissions, the edges represent the dependency relationship between permissions, and the weight of the edge represents the dependency strength. By analyzing the historical operation logs, the conditional probability between permissions is calculated to determine the dependency relationship and strength. For example, if permission A has an 80% probability of using permission B after use, it is considered that B depends on A, and the dependency strength is 0.8. In combination with business expert knowledge, a risk coefficient is assigned to each permission, ranging from 0 to 1, and the closer to 1, the higher the risk. For example, the risk coefficient of "viewing public documents" is 0.1, and the risk coefficient of "deleting core databases" is 0.95. The dependency graph construction algorithm first extracts operation sequences from the original operation logs, then uses a sliding window (window size of 5 operations) to count the operation co-occurrence frequency, and finally calculates the weight of the edge through the conditional probability.
[0139] The spectral clustering algorithm is used to segment the permission dependency graph, and the permissions are divided into subsets of different granularities. The parameters of spectral clustering are dynamically adjusted according to the security level of the tenant: the cluster number K is determined based on the security level and the total number of permissions, and the calculation method is to multiply the basic cluster number by (1 plus the security level multiplied by 0.2), wherein the basic cluster number is a benchmark value preset according to the size of the permission set. For example, for a tenant with a security level of 3, the basic cluster number is 10, and the actual cluster number is 16. The spectral clustering result is post-processed to ensure that high-risk permissions are not divided into the same cluster as low-risk permissions. For each cluster, further subsets are divided based on the functional similarity and risk level of the permissions. The functional similarity is calculated by the text similarity of the permission description, using TF-IDF vectorization and cosine similarity measurement.
[0140] For tenants with higher security levels, the single permission is further decomposed into multiple fine-grained operation permissions. The decomposition process is based on a pre-defined permission decomposition template library, containing fine-grained decomposition schemes for common permission types. For example, the "file management" permission can be decomposed into "file read", "file create", "file modify", "file delete", and "file share" five fine-grained permissions. The decomposition depth is directly related to the security level: tenants with security levels 1-2 usually do not decompose; tenants with security level 3 perform one-level decomposition; tenants with security levels 4-5 perform two-level or deeper decomposition. For example, for tenants with security level 5, the "file modify" permission is further decomposed into "modify file content", "modify file attributes", and "modify file permissions" three more fine-grained permissions.
[0141] For each fine-grained permission, apply the corresponding time constraint from the time-limited permission set. The strictness of the time constraint is also related to the security level: the higher the security level, the stricter the time constraint. Control is performed using a time constraint adjustment factor, calculated as the base time constraint multiplied by (1 plus (security level minus 1) times 0.15), where the base time constraint is the pre-set standard constraint. For example, if the base time constraint allows access from 9:00 to 18:00 on weekdays, the actual constraint for tenants with security level 4 is narrowed to 10:00 to 17:00 on weekdays.
[0142] The final fine-grained permission list is generated in XACML (Extensible Access Control Markup Language) format, containing complete access control information such as permission identification, resource range, operation type, time constraint, and additional conditions. The XACML document structure contains elements such as policy, rule, target, and condition, which can accurately express complex access control rules. For permission information that needs to be shared across multiple intervals, generate a JWT format token for easy transmission, which contains an encrypted digest of the permission list. The JWT token structure contains three parts: header, payload, and signature, with the payload containing permission information in a compressed format to reduce token size. The token is signed using the RSA-256 algorithm to ensure the integrity and tamper-proof nature of the token.
[0143] When a new fine-grained permission list is generated, the previous version is saved and the change reason, change content and change time are recorded. For high-security-sensitive permission changes, the administrator is required to confirm or provide additional authorization. A permission usage log is also maintained, recording information such as the time, resources, and operation results of each permission access, providing a data foundation for subsequent anomaly detection and rule optimization. The permission list update adopts an incremental approach, only transmitting the changed parts, reducing communication overhead. The update operation uses a two-phase commit protocol to ensure the consistency of the permission data. In a multi-tenant environment, the permission lists of different tenants are stored separately to avoid permission leakage between tenants. The entire permission generation and management process follows the principle of least privilege and the principle of separation of duties to ensure security and auditability.
[0144] When a new fine-grained permission list is generated, conflicts between permissions are checked, such as one permission allowing access in a certain time period and another permission prohibiting access in the same time period. Conflict detection uses a Boolean satisfiability problem solving method to convert permission rules into Boolean expressions and detect conflicts through a solver. For detected conflicts, a pre-set conflict resolution strategy is applied, usually following the "deny first" principle, i.e. when multiple rules conflict, the rule with higher priority is preferred.
[0145] The present application realizes precise detection of permission anomalies through time series access pattern analysis and rule matching, and realizes fine-grained permission control based on the security level of the tenant verification token. The time constraint mechanism realizes differentiated access restriction in combination with the security level, effectively preventing unauthorized access during the abnormal period.
[0146] In a second aspect of the embodiments of the present application, an electronic device is provided, comprising:
[0147] a processor;
[0148] a memory for storing processor-executable instructions;
[0149] The processor is configured to invoke the instructions stored in the memory to execute the method described above.
[0150] In a third aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.
[0151] The present application can be a method, device, system and / or computer program product. The computer program product can include a computer readable storage medium having loaded thereon computer readable program instructions for executing various aspects of the present application.
[0152] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions recorded in the above embodiments can be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. A multi-tenant, multi-user login method based on enhanced OAuth2, characterized in that, include: The tenant key threshold is obtained based on the tenant identifier in the login request, and the access token is obtained by performing standard OAuth2 authentication based on the user identifier. A tenant key proof is generated based on the zero-knowledge proof protocol and the tenant key threshold. The tenant key proof and the access token are encrypted using a homomorphic encryption algorithm to generate tenant fingerprint information; The master key is fragmented and stored in the key management node, and a tenant verification token is generated through secure multi-party computation by the key management node based on the tenant fingerprint information. The tenant verification token and the access token are combined and encrypted to generate an enhanced access token; Obtain historical access data of users under the tenant; based on the historical access data, construct a reinforcement learning access controller, taking user behavior as the observation state and permission operation as the action space; The system collects real-time user behavior data, and the access controller continuously learns based on the real-time behavior data to generate an initial permission list. Anomaly detection is performed on the initial permission list, and a fine-grained permission list is generated by combining the tenant verification token; A session identifier is generated based on the enhanced access token and the fine-grained permission list, and the session identifier and authentication authorization information are stored in a distributed cache.
2. The method according to claim 1, characterized in that, The steps for generating a tenant key proof based on a zero-knowledge proof protocol and the tenant key threshold include: Obtain the tenant security level and tenant resource sensitivity associated with the tenant identifier; generate a baseline security value based on the tenant security level and a resource sensitivity coefficient based on the tenant resource sensitivity; generate a tenant key threshold based on the baseline security value, the resource sensitivity coefficient, and a dynamic adjustment factor, wherein the dynamic adjustment factor is calculated by weighting the real-time security threat level, the number of tenant authentication failures, and the frequency of historical attacks. Zero-knowledge proof parameters are generated based on preset elliptic curve parameters, and an interactive commitment value is generated using the zero-knowledge proof parameters and the tenant's private key. A tenant identity commitment is generated based on the tenant's private key and the interaction commitment value. A threshold satisfaction proof is constructed using the tenant key threshold and the interaction commitment value. An auxiliary random value is generated based on a preset group order. The tenant identity commitment, the threshold satisfaction proof, and the auxiliary random value are combined to generate a zero-knowledge proof. The zero-knowledge proof is validated by parameters. When the validation passes, a tenant key proof is generated based on the zero-knowledge proof, the interaction commitment value, and the tenant's private key.
3. The method according to claim 1, characterized in that, The steps of storing the master key in fragments to the key management node, and generating a tenant verification token through secure multi-party computation by the key management node based on the tenant fingerprint information, include: The master key is fragmented and stored across multiple key management nodes using a hierarchical dynamic threshold scheme. The threshold value and total number of nodes for the hierarchical dynamic threshold scheme are determined based on the load intensity and communication efficiency of the key management nodes. The key management nodes are divided into multiple hierarchical groups based on node computing power scores and network topology distances. A nested polynomial structure is constructed for each hierarchical group, where the constant term of the inner polynomial is set as the master key value, and the coefficients of the outer polynomial are determined by a weighted value of the trustworthiness of the tenant's access behavior and the frequency of resource calls. A unique key fragment is generated for each key management node according to the constructed polynomial and distributed for storage. After processing the tenant fingerprint information for privacy protection, differential privacy calculations are performed in the homomorphic encryption domain through key sharding in each of the key management nodes, and distributed zero-knowledge proofs are executed to generate tenant verification tokens.
4. The method according to claim 3, characterized in that, After performing privacy protection processing on the tenant fingerprint information, the steps of generating a tenant verification token by performing differential privacy computation in the homomorphic encryption domain through key fragmentation in each of the key management nodes and executing distributed zero-knowledge proofs include: Extract identity feature vectors and behavioral feature vectors from the tenant fingerprint information, and perform linear transformation to generate privacy-preserving feature fragments; The feature fragment is sent to multiple key management nodes. Each key management node performs a homomorphic inner product operation between the key fragment it holds and the feature fragment in the cryptographic domain, and introduces Laplace-distributed differential privacy noise into the result of the homomorphic inner product operation to obtain a partial verification factor. The computational weight of each key management node is determined based on the trustworthiness of the key management node. The computational weight is then used to perform a secure multi-party summation operation with the corresponding partial verification factor to generate an aggregate verification value. When the number of key management nodes participating in the secure multi-party summation operation reaches a preset threshold, the key management nodes execute a distributed zero-knowledge proof protocol to verify the calculation process of the aggregated verification value, and combine the verified aggregated verification value with the hash value of the identity feature vector to generate a tenant verification token.
5. The method according to claim 1, characterized in that, Based on the historical access data, a reinforcement learning access controller is constructed, which takes user behavior as the observation state and permission operation as the action space. The steps of collecting real-time user behavior data and having the access controller continuously learn based on the real-time behavior data to generate an initial permission list include: The historical access data is extracted with temporal features, behavioral features, and environmental features. After being segmented by a sliding time window, the data is standardized to obtain standardized features. A reinforcement learning access controller is constructed, and the standardized features are combined into a user state vector. The user state vector includes a temporal feature vector, a behavioral feature vector, and a contextual feature vector. The granting, revocation, and maintenance of permissions are constructed as an action space. A composite reward function is constructed based on security compliance rewards, access efficiency rewards, and risk penalty items. Real-time user behavior data is collected, and the real-time user behavior data is sequence encoded using an attention mechanism to obtain a real-time feature vector. The attention mechanism processes the current query vector and historical behavior key-value pairs. The access controller continuously learns based on the real-time feature vector, updates the access control policy through policy gradient, and calculates the action value based on value function estimation. The confidence level of each permission is calculated based on the action value and consistency of historical behavior. The confidence level is then filtered based on a preset filtering threshold, and conflict resolution is performed using a permission dependency graph to generate an initial permission list.
6. The method according to claim 5, characterized in that, The steps of the access controller performing continuous learning based on the real-time feature vector include: The real-time feature vector is input into the dual-channel neural network of the access controller. The first channel constructs a local policy network to extract short-term behavioral features, and the second channel constructs a global policy network to extract long-term behavioral patterns. The policy gradient of the access control policy is calculated based on the outputs of the local policy network and the global policy network. The policy gradient evaluates the historical decision trajectory through importance sampling and introduces an entropy regularization term. A dual-valued function is constructed to calculate the value of the action. The dual-valued function estimates the immediate reward value and the long-term reward value respectively. The time difference error guides the update direction of the access control policy. An adaptive learning rate is set based on the confidence interval theory. When the change in user behavior distribution caused by the update of the access control policy exceeds the preset confidence interval, the learning step size is automatically adjusted to ensure that the access control policy converges stably.
7. The method according to claim 1, characterized in that, The steps of performing anomaly detection on the initial permission list and generating a fine-grained permission list in conjunction with the tenant verification token include: Based on the analysis of the user's historical access behavior to each permission in the initial permission list using a sliding time window, the time-series access pattern is calculated and converted into permission frequency features. The tenant access time constraints are extracted using the tenant verification token, and an access permission rule base is constructed based on a preset time-series rule template. The frequency characteristics of the permissions are matched with the permission access rule base to identify abnormal permissions that do not conform to the time sequence rules; the access time of the abnormal permissions is constrained to generate a time-restricted permission set; the permission set is further divided into fine-grained parts based on the security level in the tenant verification token to generate a fine-grained permission list with time constraints.
8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.
9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.
Citation Information
Patent Citations
A key sharing method based on cloud outsourcing and an access control system thereof
CN109936530A
Login method and device of multi-tenant system
CN113901428A