A universal background permission hierarchical management and control and user authentication and authorization system

Abstract

The application discloses a universal background permission hierarchical management and user authentication and authorization system. In view of three core problems of ghost permission residues, multi-tenant horizontal unauthorized access and non-human identity permission out of control in a distributed multi-tenant background system, three core technologies are adopted, i.e. a multi-dimensional directed acyclic graph based on a time-decay state boundary combined with an incremental topological sorting algorithm, millisecond-level accurate calculation of permission change influence range in the memory and generation of an idempotent revocation instruction set, realization of consistent convergence of cross-system permission revocation, token dynamic coloring based on gateway bottom-layer physical context characteristics and AOP secondary cross-checking mechanism, blocking of cross-tenant unauthorized access caused by API parameter tampering from an architecture level, adaptive weight reduction mechanism driven by hidden Markov model behavior baseline and Z-Score abnormality detection, accurate convergence of non-human identity permission boundary to a measured target permission set and automatic recovery support.

Description

Technical Field

[0001] This invention belongs to the field of network security and identity authentication technology, specifically involving a general-purpose backend permission hierarchical control and user authentication authorization system, which is applicable to permission inheritance management, multi-tenant isolation authentication, and non-human identity dynamic permission convergence scenarios in distributed multi-tenant SaaS backend systems. Background Technology

[0002] With the widespread adoption of cloud computing, microservice architecture, and SaaS models, backend systems have evolved from monolithic architectures to distributed multi-service collaborative architectures. The types of identities in the system have expanded from single human users to non-human identity groups including API service accounts, automated scripts, and AI agents, resulting in unprecedented complexity in access control requirements.

[0003] The closest existing solution to this invention is a role-based access control (RBAC) architecture combined with JSON Web Token (JWT) and gateway-based unified authentication. A typical implementation of this architecture is as follows: after a user completes authentication, the authentication service queries the database for their role and permission information and encodes it into the payload field of the JWT token. The gateway layer verifies the token's validity and permissions before forwarding the request to the backend service. When permissions change, the system relies on cascading updates of the relational database and the natural expiration mechanism of the short-term validity of the JWT to achieve eventual consistency. Multi-tenant isolation is achieved by carrying plaintext tenant identifiers in the JWT payload. Machine identity is managed by issuing long-term static API keys and pre-configuring fixed permission policies.

[0004] The existing solutions mentioned above have the advantages of simple implementation and low operation and maintenance costs in small and medium-sized systems, but they expose three core defects in large-scale distributed multi-tenant scenarios.

[0005] First, there is a persistent problem of ghost permissions in the cross-system permission inheritance chain. In a large-scale microservice architecture, users, roles, policies, and resources form a multi-layered nested inheritance network. When an upper-level role is revoked or permissions are changed, the existing system relies on a relational database for table-by-table updates, resulting in significant synchronization delays. This leads to illegal ghost permissions remaining in downstream sub-roles or edge microservices. The time window from permission revocation to full system-wide effect can be as long as tens of minutes, creating a potential risk of internal data leakage.

[0006] Second, multi-tenant SaaS systems suffer from horizontal privilege escalation issues caused by API parameter tampering. Existing solutions carry tenant identifiers in plaintext or weakly encrypted form in JWT payloads or API request parameters. If the authentication logic has a flaw, attackers can bypass the isolation boundary and access other tenants' sensitive data simply by tampering with the tenant identifier parameter in the request. Existing standard JWT solutions do not have native defense capabilities against such request tampering attacks.

[0007] Third, there is the issue of uncontrolled and undynamically converged non-human identity permission boundaries. Existing IAM systems typically use static APIKeys for coarse-grained control, granting permissions far exceeding actual business needs. Furthermore, they lack semantic analysis and dynamic response capabilities for call behavior, failing to promptly converge permission boundaries when abnormal call patterns appear on machine identities. This becomes a core security blind spot in cloud-native environments. Summary of the Invention

[0008] In view of the problems existing in the prior art, the purpose of this invention is to provide a general-purpose backend permission hierarchical control and user authentication authorization system to solve the three core technical problems of ghost permission residue, multi-tenant horizontal unauthorization and non-human identity permission out of control in the prior art.

[0009] This invention is implemented as follows: a general-purpose backend permission hierarchical control and user authentication authorization system, including an identity authentication gateway layer, a permission graph calculation engine, a token coloring and cross-validation module, a non-human identity behavior baseline analysis and dynamic demotion module, and a distributed event synchronization bus.

[0010] The identity authentication gateway layer assumes the responsibility of a unified identity authentication entry point, integrates the OAuth2.0 / OIDC authentication module, the token dynamic coloring module, and the gateway behavior rule engine, and works with Redis cache to accelerate token verification.

[0011] The permission graph calculation engine abstracts the five types of entities in the system—users, identities, roles, policies, and resources—and their authorization relationships into a multi-dimensional directed acyclic graph with time-decaying state boundaries. It also has a built-in incremental topology sorting algorithm module that accurately calculates the scope of impact in memory and generates a minimum set of revocation instructions when permissions change.

[0012] The token coloring and cross-validation module extracts physical context features during the JWT token issuance phase and performs a one-way hashing with the authoritative tenant identifier to generate a colored signature, which is then embedded in the JWT extended field. During the resource access phase, a secondary cross-consistency check is performed by an aspect-oriented programming (AOP) interceptor.

[0013] The non-human identity behavior baseline analysis and dynamic weight reduction module establishes a behavior baseline for the historical call sequence of each non-human identity based on a hidden Markov model, and detects deviations in call behavior in real time and triggers an adaptive weight reduction mechanism.

[0014] The distributed event synchronization bus is built on a Kafka cluster and includes permission revocation message channels, behavior log message channels, and security alarm message channels, enabling decoupled collaboration between modules.

[0015] The technical solution of this invention to solve the phantom permission problem is as follows: The permission inheritance relationship is modeled as a multi-dimensional directed acyclic graph with time-decaying state boundaries. The node set covers five types of entities: users, identities, roles, policies, and resources. The directed edge set represents the authorization inheritance relationship. Each directed edge carries a valid time interval; when the current time exceeds the upper limit of the valid time interval, the edge automatically becomes logically invalid. When a permission change event is triggered, an incremental topology sorting algorithm is used to perform a breadth-first search starting from the triggering node involved in the change, accurately defining the scope of influence. Permission differential calculation is performed on the affected nodes to generate a minimum revocation instruction set. The instructions are encapsulated as idempotent messages carrying unique event identifiers and written to the Kafka revocation message channel. Each microservice node subscribes to and consumes the message, immediately invalidating its local permission cache, thereby achieving consistent convergence of cross-system permission revocation within a millisecond-level time window.

[0016] The technical solution of this invention to solve the multi-tenant horizontal privilege escalation problem is as follows: During the JWT token issuance stage at the gateway layer, three features are extracted from the underlying physical deployment context of the gateway: the tenant routing node identifier, the request access time period feature, and the gateway instance fingerprint. The client and attackers cannot obtain or forge these features from the request application layer. The three features are concatenated with the authoritative tenant identifier confirmed by identity authentication in a fixed order to form the original input string. The HMAC-SHA256 operation is performed using the symmetric key held by the gateway to generate a colored signature. The signature is written into the JWT extension field and signed and issued together with the standard payload. During the resource access stage, the AOP interceptor extracts the tenant identifier declared in the request, reconstructs the original input string and recalculates the signature value. The signature value is compared with the colored signature in the token. If they are inconsistent, the request is immediately rejected and a security alarm is triggered.

[0017] The technical solution of this invention to solve the problem of uncontrolled access for non-human identities is as follows: API call logs for each non-human identity are collected, call sequences are extracted using a sliding time window, and a behavioral baseline is established by learning Hidden Markov Model parameters through the Baum-Welch algorithm. The log-likelihood of the current call sequence under the baseline model is calculated in real time, and a deviation score is obtained through Z-Score standardization. When the deviation score is lower than a preset negative deviation threshold, the behavior is determined to be abnormal. The target permission set is derived by the intersection of the historical actual call interface set of the non-human identity and its statically configured permission set. The permission boundary configuration of the identity at the gateway layer is overridden through the Redis hot update mechanism, achieving non-blocking adaptive permission convergence. After the deviation score returns to normal and remains stable for a preset observation period, the permission boundary is automatically restored to the original static permission set.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: The cross-system consistency convergence time after permission revocation is reduced from minutes to less than 50 milliseconds, fundamentally eliminating ghost permission remnants and blocking the risk of internal data leakage caused by them.

[0019] By strongly binding the physical context characteristics of the request to the tenant identity in an unforgeable colored signature, horizontal privilege escalation attacks caused by API parameter tampering are blocked at the architectural level. The entire secondary verification process takes no more than 1 millisecond and does not introduce significant performance overhead.

[0020] It enables real-time perception and adaptive convergence of permissions for non-human identity call behaviors, precisely controls the boundaries of machine identity permissions within the historical test range, and avoids interruption to normal business through an automatic permission recovery mechanism. Attached Figure Description

[0021] Figure 1 This is a diagram of the overall system architecture of the present invention; Figure 2 This is a flowchart of the incremental topology sorting algorithm of the present invention; Figure 3 This is a flowchart of the token dynamic coloring and secondary cross-validation process of the present invention; Figure 4 This is a flowchart of the baseline analysis and dynamic weight reduction process for non-human identity behavior in this invention. Detailed Implementation

[0022] To further understand the invention's content, features, and effects, the following embodiments are provided, and detailed descriptions are given in conjunction with the accompanying drawings.

[0023] The structure of the present invention will now be described in detail with reference to the accompanying drawings.

[0024] System Overall Architecture like Figure 1As shown, the general-purpose backend permission hierarchical control and user authentication authorization system proposed in this invention consists of five functional modules: identity authentication gateway layer, permission graph calculation engine, token coloring and cross-validation module, non-human identity behavior baseline analysis and dynamic demotion module, and distributed event synchronization bus.

[0025] The client layer includes three types of access points: human users (browsers and mobile devices), API service accounts, and AI agents. All access is unified through an identity authentication gateway layer. This gateway layer integrates an OAuth2.0 / OIDC authentication module, a token dynamic coloring module, and a gateway behavior rule engine, and accelerates token verification through Redis caching. The core engine layer comprises two parallel sub-modules: a permission graph calculation engine and a non-human identity behavior baseline analysis and dynamic weight reduction module. The former incorporates an incremental topology sorting algorithm module, while the latter incorporates a Hidden Markov Model baseline model and a sliding window statistics module. The distributed event synchronization bus is built on a Kafka cluster and includes permission revocation command message channels, behavior log message channels, and security alarm message channels. The storage layer includes three storage components: a permission relationship graph storage (RedisGraph), a time-series behavior log library (ClickHouse), and a main permission policy database.

[0026] A Ghost Permission Cascading Calculation and Topology Revocation Engine Based on Multidimensional Directed Acyclic Graphs like Figure 2 As shown, this invention abstracts the five types of entities in the system—user, identity, role, policy, and resource—and their authorization relationships into a multi-dimensional directed acyclic graph G=(V,E,T) with time-decaying state boundaries. Here, V is a set of nodes, each representing an instance of one of the five types of entities; E is a set of directed edges, each indicating an authorization inheritance relationship from the source node to the target node, with the edge direction representing the direction of permission transfer; and T is the time-decaying state boundary carried by each edge, i.e., the effective time interval of the authorization relationship. When the current time exceeds the upper limit of the effective time interval, the edge automatically becomes logically invalid and is deleted from the graph. Directed edges in the graph point from high-permission nodes to low-permission nodes, and loops are not allowed, ensuring that there is no permission overflow caused by circular inheritance.

[0027] When a permission change event is triggered, this invention uses the Incremental Topological Sorting Algorithm (ITSA) to accurately calculate the impact explosion radius in memory and generate a minimum undo instruction set. The execution process is as follows: After receiving the permission change instruction, the permission management console parses the change operation into graph operation primitives such as edge deletion or node status update. The system records the set of source nodes involved in the change as the trigger node set, and each trigger node is marked as a dirty node. The time complexity of the marking operation is linearly related to the number of nodes involved in this change.

[0028] Starting from each trigger node, a breadth-first search is performed along the directed edges to traverse all reachable downstream nodes. All these downstream nodes are added to the affected node set, and the enqueue timestamp of each visited node is recorded to prevent duplicate processing when multiple paths converge to the same node in the graph. This step precisely defines the impact blast radius of this permission change.

[0029] For the connected subgraph formed by the affected node set and the edges between them, perform a local topological sort and generate a processing sequence for the affected nodes according to the Kahn algorithm. Specifically, calculate the in-degree of each node in the connected subgraph, add nodes with an in-degree of zero to the processing queue, gradually dequeue them and remove their outgoing edges until the queue is empty. The rest of the graph is not reordered to ensure that the algorithm is an incremental operation.

[0030] According to the processing sequence, permission differential calculation is performed on each node. The permission snapshot of the node before the change is performed with the permission set re-derived based on the changed graph structure to obtain the permission set that needs to be revoked. A revocation instruction is generated for nodes with non-empty sets. The set of all revocation instructions is the minimum revocation instruction set, ensuring that the revocation operation does not generate redundant instructions.

[0031] Each revocation instruction in the minimal revocation instruction set is encapsulated as an idempotent message carrying a unique event identifier and written to the corresponding permission revocation message channel partition in the Kafka cluster. The partitioning strategy is based on hash partitioning according to the service domain to which the affected node belongs. Each microservice node subscribes to the message channel of its partition. Upon receiving a revocation message, it performs an immediate invalidation operation on its local permission cache and submits a consumption confirmation to Kafka. The system ensures that the same revocation instruction will not produce side effects even if it is delivered repeatedly through the idempotency of the event identifier. Each consumer maintains a Bloom filter of processed event identifiers through Redis to achieve efficient duplicate message filtering.

[0032] Once all microservice nodes corresponding to the affected node set have submitted consumption confirmation, the system persists the changed local subgraph state to RedisGraph and clears all dirty node markers, completing the full-link closed-loop processing of this permission change. The entire process is completed within 50 milliseconds.

[0033] Context-aware token dynamic coloring and double cross-validation mechanism for multi-tenant isolation like Figure 3 As shown, this mechanism is divided into two parts: the token issuance phase and the resource access phase.

[0034] During the token issuance phase, after the user or service completes OAuth2.0 / OIDC authentication and authorization, the token dynamic coloring module at the gateway layer intervenes to perform the following processing: The gateway layer extracts three physical context features from the underlying context of the current HTTP connection: tenant routing node identifier, which is the tenant entry node identifier determined by the gateway based on the domain name or routing rules, carried in non-request parameters, request access time period feature, which uses minute-level time slots to reduce the impact of clock precision jitter, and gateway instance fingerprint, which is the deployment identifier of the gateway node currently processing the request. All three features come from the underlying physical deployment context of the gateway, and cannot be known or forged by the client or attacker at the request application layer.

[0035] The authenticated authoritative tenant identifier is extracted from the authoritative account record, not the request parameters. The three physical context features and the authoritative tenant identifier are concatenated in a fixed order to form the original input string M, using the gateway symmetric key centrally managed by the key management service. Perform HMAC-SHA256 operation to generate a colored signature:

[0036] in, It is a one-way hash digest of 256 bits in length. The symmetric key held by the gateway is centrally managed by a key management service and is not exposed to any external interface, ensuring that attackers are unaware of its existence. In cases where it is impossible to recalculate a valid tenant identifier, ; The original input string is the concatenation of three physical context features and the authoritative tenant identifier in a fixed order.

[0037] Will The hexadecimal encoding of the token is written into the JWT extension field x-ctx-sig, signed along with the standard payload, and then sent to the client. The client can only read the token content, but due to the lack of... And the underlying context characteristics of the gateway cannot be forged. .

[0038] During the resource access phase, the backend service performs secondary cross-validation through an AOP interceptor: the interceptor extracts the tenant identifier from the request claim parameters and reads the colored signature from the x-ctx-sig extended field of the JWT token carried in the request. The backend service receives the physical context features passed through by the gateway when forwarding requests through the encrypted internal header, reconstructs the original input string, recalculates the signature value using the same key, and compares it with the color signature in the token. If the two are equal, the request passes and is forwarded to the business logic. If they are not equal, it means that the tenant identifier in the request has been tampered with, the request is immediately rejected and a security alarm is triggered, and a 403 error response is returned. The entire verification process takes no more than 1 millisecond and does not introduce significant delay.

[0039] Behavioral baseline-driven dynamic weighting model for non-human identities like Figure 4 As shown, the processing of this module is divided into a baseline establishment stage and a real-time detection and weight reduction stage.

[0040] During the baseline establishment phase, the API gateway and the EnvoySidecar of each microservice record each API call initiated by a non-human identity as a standardized access log event, which includes the unique identifier of the non-human identity, the path of the microservice interface being called, the call timestamp, and the HTTP method type. The log events are asynchronously written to the ClickHouse columnar time-series database without blocking the main business call chain.

[0041] The historical logs of each non-human identifier are sliced ​​using a fixed time window (default configuration is 24 hours), and the API call sequence within the window is extracted. K-means clustering is performed on the interface call type to discretize the high-dimensional interface path space into a finite set of observation symbols, thereby reducing the dimensionality of the model input space.

[0042] The Baum-Welch algorithm is used to estimate the parameters of the observed sequence, and a Hidden Markov Model parameter triplet describing the normal behavior pattern of the non-human identity is learned. This triplet includes: a state transition probability matrix, describing the transition probability between different working modes; a set of hidden states corresponding to different working modes of the non-human identity (such as data reading mode, configuration query mode, etc.); an observation emission probability matrix, describing the probability of generating a specific interface call symbol in a specific working mode; and an initial state probability vector, describing the prior probability of each working mode at the beginning of the sequence. The baseline is incrementally updated using the Apache Flink stream processing framework with a micro-batch period of 5 to 10 minutes to ensure that the baseline adaptively iterates with the normal evolution of the non-human identity's business patterns.

[0043] During the real-time detection and weight reduction phase, when a non-human identity's real-time call sequence arrives at the gateway within the current 5-minute window, the system uses a forward algorithm to calculate the log-likelihood of the real-time sequence under the learned Hidden Markov Model, and obtains the deviation score after Z-Score standardization.

[0044] in, Scoring the degree of deviation; For the current real-time call sequence Hidden Markov Models The log-likelihood is calculated efficiently recursively using the forward algorithm. This represents the mean of the log-likelihood sequence within the historical sliding window. This corresponds to the standard deviation. When... Below the preset negative deviation threshold (default configuration is) When a significant abnormal deviation is detected in the current non-human identity behavior, an adaptive demotion process is triggered.

[0045] After triggering a demotion, the system queries ClickHouse for the set of API interfaces that the non-human identity has actually successfully called in the past 30 days, which is recorded as the actual permission set. The intersection of the actual permission set and the static permission set currently configured for the identity is taken to obtain the target permission set, which retains only the interface permissions that have been actually used in the past and removes redundant permission items that have never been actually called.

[0046] The system encodes the target permission set into the gateway rule engine's restriction configuration, and uses the Redis hot update mechanism to overwrite the local rate limiting and resource scope configuration parameters of the non-human identity. The API gateway will immediately take effect with the new permission boundary when the next request arrives. The entire hot update process does not restart the gateway process and does not affect the request processing of other identities. At the same time, the system pushes an alarm event to the security operations center, which includes a complete sequence of deviation behavior, triggering reasons and details of the demotion operation, for the security team to manually review.

[0047] If the deviation score of the non-human identity returns to the normal range within the subsequent time window and remains stable for three consecutive 5-minute observation windows, the system will automatically restore the permission boundary from the target permission set to the original static permission set, and record this demotion event in the behavior profile of the non-human identity for subsequent baseline optimization.

[0048] Distributed event synchronization bus The three core modules of this system are decoupled and coordinated through a distributed event synchronization bus composed of a Kafka cluster. The permission revocation message channel is written by the permission graph calculation engine, and each microservice node subscribes to and consumes it. This is used to broadcast the minimum revocation instruction set. The partitioning strategy uses hash partitioning based on the service domain of the affected node to ensure locality. The behavior log message channel is written by the API gateway and EnvoySidecar, and processed by Flink. This is used for near-line analysis of non-human identity behavior baselines. Partitioning is based on non-human identity identifiers to ensure the order of logs for the same identity. The security alarm message channel is written by the token cross-validation module and the dynamic demotion module, and subscribed to and consumed by the security operations platform. This aggregates security alarm events from across the system. All messages carry a unique idempotent event identifier. Each consumer maintains a Bloom filter of processed event identifiers through Redis to achieve efficient duplicate message filtering.

Claims

1. A general-purpose backend permission hierarchical control and user authentication authorization system, characterized in that, include: The identity authentication gateway layer integrates the OAuth2.0 / OIDC authentication module, the token dynamic coloring module, and the gateway behavior rule engine, and works with Redis cache to assume the responsibility of a unified identity authentication entry point; The permission graph calculation engine abstracts the five types of entities in the system—users, identities, roles, policies, and resources—and their authorization relationships into a multi-dimensional directed acyclic graph with time decay state boundaries. It has a built-in incremental topology sorting algorithm module that calculates the scope of impact in memory and generates a revocation instruction set when permissions change. The revocation instruction set is encapsulated by idempotent messages and then sent to each microservice node through a distributed event synchronization bus. The token coloring and cross-validation module extracts physical context features from the underlying physical deployment context of the gateway and performs HMAC-SHA256 one-way hash mixing with the authoritative tenant identifier during the JWT token issuance phase. The generated colored signature is embedded into the JWT extension field. During the resource access phase, the input is reconstructed by the AOP interceptor and the signature value is recalculated. A second cross-consistency check is performed with the colored signature in the token. The non-human identity behavior baseline analysis and dynamic demotion module establishes a behavior baseline for the historical call sequence of each non-human identity based on the Hidden Markov Model. It detects call behavior anomalies in real time through Z-Score deviation scoring, derives the target permission set by the intersection of the measured permission set and the static permission set, and overwrites the permission boundary configuration of the non-human identity at the gateway layer through Redis hot update. The distributed event synchronization bus, built on a Kafka cluster, includes permission revocation message channels, behavior log message channels, and security alarm message channels, enabling decoupled collaboration between various modules.

2. A permission revocation method based on a multidimensional directed acyclic graph, characterized in that, The following processing steps are included: Construct a multidimensional directed acyclic graph with time decay state boundaries. Use five types of entities in the system—users, identities, roles, policies, and resources—as nodes, and use authorization inheritance relationships as directed edges. Directed edges point from high-privilege nodes to low-privilege nodes and do not have loops. Each directed edge carries a valid time interval. When the current time exceeds the upper limit of the valid time interval, the edge automatically becomes logically invalid. After receiving the permission change instruction, the change operation is parsed into graph operation primitives, the source nodes involved in the change are marked as dirty nodes, and a breadth-first search is performed along the directed edge direction starting from the dirty nodes. All reachable downstream nodes are traversed and aggregated into an affected node set. The queuing timestamp of each visited node is recorded to prevent duplicate processing when multiple paths converge. Perform a local topological sort on the connected subgraph formed by the affected node set and the edges between them, and generate the processing sequence of the affected nodes according to the Kahn algorithm. Do not re-sort the rest of the graph. Perform permission differential calculation on each node according to the processing sequence, perform set difference operation on the permission snapshot before the change and the permission set re-derived based on the changed graph structure, generate revocation instructions for nodes with non-empty difference sets, and summarize all revocation instructions to form a revocation instruction set; Each revocation instruction in the revocation instruction set is encapsulated as an idempotent message carrying a unique event identifier and written to the Kafka permission revocation message channel. After each microservice node subscribes and consumes the message, it performs an immediate invalidation operation on the local permission cache and submits a consumption confirmation. After all nodes submit confirmations, the updated local subgraph state is persisted to the distributed graph storage and the dirty node marker is cleared.

3. A multi-tenant isolation method based on context-aware token dynamic coloring, characterized in that, include: Token issuance phase: After completing OAuth2.0 / OIDC authentication, the gateway layer extracts three physical context features from the underlying context of the current HTTP connection: tenant routing node identifier, request access time period feature, and gateway instance fingerprint. These three features all come from the gateway's underlying physical deployment context and cannot be obtained or forged by the client from the requesting application layer. The three physical context features are concatenated with the authenticated authoritative tenant identifier in a fixed order to form the original input string. The gateway's symmetric key, managed by the key management service, is used to perform HMAC-SHA256 operation to generate a colored signature. The colored signature is written into the JWT extension field and then signed and issued together with the standard payload. Resource access phase: The backend service's AOP interceptor extracts the tenant identifier of the request declaration from the current HTTP request parameters, reads the colored signature from the JWT token extension field, receives the physical context features passed through by the gateway through the encrypted internal header, reconstructs the original input string and recalculates the signature value using the same key, compares the recalculated signature value with the colored signature in the token for consistency, and immediately rejects the request and triggers a security alarm if the comparison is inconsistent.

4. A behavioral baseline-driven dynamic weighting method for non-human identities, characterized in that, include: Baseline establishment process: Collect API call logs initiated by non-human identities and write them into a time series database. Extract call sequences by slicing the historical logs of each non-human identity in a fixed time window. Perform K-means clustering on the interface call types to generate a finite set of observation symbols. Use the Baum-Welch algorithm to learn the parameters of the hidden Markov model to establish a behavioral baseline. The baseline is incrementally updated at a predetermined period through a stream processing framework. Real-time detection process: The forward algorithm is used to calculate the log likelihood of the real-time call sequence within the current time window under the baseline hidden Markov model. The deviation score is obtained by Z-Score standardization. When the deviation score is lower than the preset negative deviation threshold, the behavior is judged to be abnormal and the weight reduction process is triggered. The process of degrading permissions is as follows: The set of API interfaces that the non-human identity has successfully called within a preset historical period is retrieved from the time-series database as the actual test permission set. The intersection of the actual test permission set and the static permission set currently configured for the identity is taken to obtain the target permission set. The target permission set is overwritten to the permission boundary configuration of the non-human identity at the gateway layer through the Redis hot update mechanism, and an alarm event is pushed to the security operations center at the same time. Permission recovery process: Continuously monitor the deviation score. When the deviation score returns to the normal range and remains stable for a preset observation period, automatically restore the permission boundary from the target permission set to the original static permission set, and record this demotion event in the behavior profile.

5. The permission revocation method according to claim 2, characterized in that, The directed acyclic graph is stored in the RedisGraph distributed in-memory graph database, and the permission relationship graph resides in memory to support millisecond-level incremental topology calculations. The consumer of the idempotent message maintains a Bloom filter of processed event identifiers through Redis to achieve efficient filtering of duplicate messages and ensure that no side effects occur when the same revocation instruction is delivered repeatedly.

6. The permission revocation method according to claim 2, characterized in that, The permission revocation message channel is hash-partitioned according to the service domain to which the affected node belongs, to ensure the locality of revocation messages within the same service domain; The local topological sorting is performed only on the connected subgraphs formed by the affected node sets. Its time complexity is linearly related to the number of nodes and the number of internal edges in the affected node sets, and is independent of the size of the entire graph.

7. The multi-tenant isolation method according to claim 3, characterized in that, The requested access time period feature adopts minute-level time slot granularity to reduce the impact of clock precision jitter on the consistency of the colored signature; The gateway's symmetric key is uniformly managed by the key management service and is not exposed to any external interface; When the gateway forwards a request to the backend service, it transmits the physical context features in the form of an encrypted internal header. The backend service obtains the features through a secure internal call for signature reconstruction.

8. The dynamic weighting method according to claim 4, characterized in that, The operation of overwriting the gateway layer permission boundary configuration through Redis hot update during the demotion process does not restart the gateway process and does not affect the processing of requests from other non-human identities. The alarm event contains a complete sequence of deviation behaviors, triggering reasons, and details of the demotion operation. The hidden state set of the hidden Markov model corresponds to different working modes of non-human identities. The state transition probability matrix describes the transition probability between different working modes. The observation emission probability matrix describes the probability of generating a specific interface call symbol in a specific working mode.

9. The dynamic weighting method according to claim 4, characterized in that, During the baseline establishment process, historical logs are sliced ​​using a fixed 24-hour time window. During the real-time detection process, a 5-minute collection window is used for the real-time call sequence. The default configuration value for the preset negative deviation threshold is... The preset observation period is three consecutive 5-minute time windows, and the behavior log message channel is partitioned according to non-human identity identifiers to ensure the sequentiality of logs for the same non-human identity.

10. The system according to claim 1, characterized in that, The identity authentication gateway layer, permission graph calculation engine, token coloring and cross-validation module, and non-human identity behavior baseline analysis and dynamic demotion module are decoupled and coordinated through the distributed event synchronization bus. After the permission graph calculation engine completes the distributed distribution of the revocation instruction set, it persists the updated subgraph state and removes the dirty node mark only after all affected microservice nodes have submitted consumption confirmation, so as to ensure the closed-loop processing of cross-system permission revocation.

Images