Micro-service identity dynamic access control method and system

Abstract

The invention discloses a micro-service identity dynamic access control method and system, and relates to the field of electric digital data processing, and the method is used for the micro-service identity dynamic access control system and comprises an authentication service and a plurality of micro-services. When a user accesses the first micro-service, the authentication service performs identity verification and generates an access token including a user identity and an initial call chain. And when the first micro-service needs to call the second micro-service, generating a derived token based on the initial token, and adding the service identity to form an extended call chain. And the second micro-service identifies the third-party service through the extended call chain, determines the desensitization intensity according to the credible level of the third-party service, and performs corresponding desensitization processing on the data. By implementing the method, the access security of the sensitive data in the distributed system can be improved.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to a method and system for dynamic access control of microservice identity. Background Technology

[0002] With the widespread adoption of cloud-native architecture, distributed system architecture has become the mainstream design pattern for modern software systems. In distributed systems, a complete business process often requires collaborative calls between multiple service modules to complete. Each service module is responsible for specific business functions, and complex business logic is combined through inter-service calls. In this architecture, a single user request may trigger cascading calls to multiple services, forming a long call chain. Due to frequent data interactions between services, achieving efficient inter-service communication while ensuring data security has become one of the core technical challenges in distributed systems.

[0003] In existing technologies, data access control between services primarily employs role-based access control mechanisms. Specifically, the authentication service verifies a user's identity upon login and generates an access token based on the user's role. This access token contains the user's identity identifier and permission information. When a service needs to retrieve data, it sends a request to the data service along with the access token. Upon receiving the access token, the data service extracts the user's identity identifier, queries the database based on the user's role and corresponding permission level, and performs uniform level of data masking on sensitive fields before returning the data.

[0004] However, the above approach applies the same level of data masking to all calls, failing to dynamically adjust the masking strength based on the actual security requirements of the call scenario. When the call chain involves services with different trust levels, this fixed level of masking may expose too much data, increasing the risk of data leakage. Summary of the Invention

[0005] This application provides a method and system for dynamic access control of microservice identity, which can improve the access security of sensitive data in distributed systems.

[0006] Firstly, this application provides a microservice identity dynamic access control method, applied to a microservice identity dynamic access control system. This system includes an authentication service, a first microservice, and a second microservice. The method includes: when a target user initiates an access request to the first microservice through a client, the authentication service authenticates the target user. Upon successful authentication, an initial access token is generated, containing a user identity identifier and an initial call chain identifier, where the initial call chain identifier contains only the target user's identity node; when the first microservice receives the access request, it parses the target data identifier in the access request and determines whether... The first microservice needs to be called. If so, the first microservice generates a derived access token based on the initial access token. This derived access token appends the service identity identifier of the first microservice to the initial call chain identifier, forming an extended call chain identifier. When the first microservice initiates a call to the second microservice, the second microservice extracts the extended call chain identifier from the derived access token, traverses each service identity identifier in the extended call chain identifier, and identifies whether a third-party service identity identifier exists in the extended call chain identifier. When a third-party service identity identifier exists, the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient.

[0007] In the above embodiments, when a third-party service call occurs, the system can identify the third-party service in the call chain based on dynamically generated access tokens and call chain identifiers, and dynamically adjust the data anonymization strength according to its trust level. This mechanism avoids the problems of overexposure or insufficient protection that may result from fixed anonymization strategies, achieving a precise match between data protection strength and service trust level, and effectively improving the access security of sensitive data in distributed systems.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the first microservice generates a derived access token based on the initial access token. The derived access token appends the service identity identifier of the first microservice to the initial call chain identifier to form an extended call chain identifier. Specifically, this includes: the first microservice extracts the initial call chain identifier from the initial access token; the first microservice obtains its own service identity identifier and uses the service identity identifier as a new node; the first microservice appends the new node to the end of the initial call chain identifier to generate an extended call chain identifier; and the first microservice encapsulates the extended call chain identifier into the derived access token.

[0009] In the above embodiments, the derived access token can dynamically append a service identity identifier to the initial call chain identifier, forming a complete service call path record. This chain-based tracing method enables each node to accurately perceive the upstream call source, providing a reliable basis for access control decisions and enhancing the traceability and security of the service call process.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the second microservice calculates a de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient. Specifically, this includes: the second microservice obtaining a set of security indicators corresponding to the third-party service identity identifier from a preset service trust level library; the security indicator set including service runtime, call frequency, and data processing compliance score; the second microservice calculating the dynamic trust level of the third-party service identity identifier based on the security indicator set; the second microservice calculating the de-identification strength coefficient based on the difference between the dynamic trust level and the preset baseline trust level; and the second microservice selecting a corresponding graded de-identification strategy based on the de-identification strength coefficient, and performing adaptive strength de-identification processing on sensitive fields in the original data record.

[0011] In the above embodiments, by analyzing multi-dimensional indicators such as service runtime, call frequency, and compliance score, the service trust level can be accurately assessed, and the data anonymization intensity can be adjusted accordingly. This refined data protection method not only ensures security requirements but also avoids data availability loss due to excessive anonymization, thereby improving data protection effectiveness.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of identifying whether a third-party service identity identifier exists in the extended call chain identifier, the method further includes: when no third-party service identity identifier exists, the second microservice queries the original data record from the data storage layer according to the user identity identifier, and performs basic desensitization processing on the original data record according to the permission level corresponding to the user identity identifier.

[0013] In the above embodiments, data processing strategies can be intelligently selected based on call chain analysis results, and differentiated de-identification processing can be applied to internal and external service calls. This dual-mode access control method effectively improves the processing efficiency of internal service calls and optimizes overall performance while ensuring security.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the second microservice queries the original data records from the data storage layer based on the user identity identifier, and performs basic de-identification processing on the original data records according to the permission level corresponding to the user identity identifier. Specifically, this includes: the second microservice obtaining a set of scenario tags corresponding to the user identity identifier, which is used to identify the data usage purpose of the user identity identifier in different business scenarios; the second microservice filtering out the original data records matching the current business scenario from the data storage layer based on the scenario tag set, and identifying sensitive fields in the original data records; the second microservice obtaining the data sensitivity preferences set by the user identity identifier, which is used to indicate the personalized display method of different types of sensitive fields; and the second microservice generating field de-identification rules based on the permission level and data sensitivity preferences, and performing basic de-identification processing on the sensitive fields according to the field de-identification rules.

[0015] In the above embodiments, by combining scene tags, sensitive field identification, and user preference settings, personalized data anonymization rules can be generated. This multi-dimensional data processing approach not only meets the security needs of different scenarios but also provides flexible data display options, enhancing the user experience.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient, the method further includes: the second microservice sets a call depth counter in the derived access token, the initial value of which is equal to the number of nodes contained in the extended call chain identifier; when the second microservice calls the third microservice, the second microservice compares the current value of the call depth counter with a preset maximum call depth threshold; if the current value exceeds the preset maximum call depth threshold, the third microservice rejects the call request from the second microservice to the third microservice.

[0017] In the above embodiments, the call chain depth can be monitored in real time and thresholds can be compared to promptly identify and block abnormal calls. This proactive protection method effectively avoids the risk of resource exhaustion caused by uncontrolled call chains and enhances operational stability.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient, the method further includes: the second microservice collecting the value of the call depth counter at preset time intervals to generate a historical value sequence of the call depth counter; the second microservice calculating the average of N consecutive values ​​in the historical value sequence and using the average as the load metric value of the current call path; when the load metric value exceeds a preset load threshold, the second microservice reducing the preset maximum call depth threshold by a preset adjustment step size; the second microservice statistically analyzing the load metric values ​​of each call path, and storing call paths with load metric values ​​less than the preset load threshold in a path optimization list, wherein each record in the path optimization list contains a call path identifier and a corresponding load metric value.

[0019] In the above embodiments, the call depth threshold can be dynamically optimized by invoking depth data acquisition and load metric calculation. This adaptive adjustment method not only ensures stable operation but also provides a reliable basis for call path optimization, thereby improving overall operating efficiency.

[0020] In a second aspect, embodiments of this application provide a microservice identity dynamic access control system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the microservice identity dynamic access control system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a microservice identity dynamic access control system, cause the microservice identity dynamic access control system to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a microservice identity dynamic access control system, cause the microservice identity dynamic access control system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the microservice identity dynamic access control system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By employing a microservice identity recognition mechanism based on dynamic access tokens, the system can track service call chains in real time, accurately identify the identities of third-party services, and effectively solve the problem that fixed access control policies in existing technologies cannot cope with complex call scenarios. This enables adaptive protection of sensitive data during service calls. The system maintains a complete call chain identifier in the access token, allowing each service node to perceive the upstream call source and take corresponding data protection measures accordingly. This dynamically adjusted data anonymization mechanism avoids the data availability loss caused by the one-size-fits-all protection in traditional solutions, while also preventing data leakage risks due to insufficient protection.

[0025] 2. By employing an access token extension mechanism based on call chains, the system accurately records service call paths, enabling precise tracing of call sources. This effectively solves the problem of difficulty in tracing service call relationships in existing technologies, thus achieving transparent access control in microservice architectures. The system appends the current service identifier to the call chain with each service call, forming a complete record of the service call path. This chain-based tracing mechanism not only supports subsequent access control decisions but also provides reliable data support for system operation and maintenance and security auditing. By analyzing call chain information, the system can promptly detect abnormal service call patterns and prevent potential security risks.

[0026] 3. Due to the adoption of a multi-dimensional security indicator evaluation mechanism, the system can dynamically calculate service trustworthiness levels and adaptively adjust data protection strength, effectively solving the problem of accurately controlling the strength of de-identification processing in existing technologies, thereby achieving refined data security protection. The system constructs an objective service trustworthiness evaluation system by comprehensively analyzing security indicators from multiple dimensions such as service runtime, call frequency, and compliance scores. The de-identification strategy, dynamically adjusted based on the evaluation results, ensures data security requirements while maximizing data availability, thus improving the system's data protection effectiveness. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a microservice identity dynamic access control method in an embodiment of this application; Figure 2 This is another flowchart illustrating the microservice identity dynamic access control method in this application embodiment; Figure 3 This is a schematic diagram of the physical device structure of a microservice identity dynamic access control system in the embodiments of this application. Detailed Implementation

[0028] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0030] For ease of understanding, the method provided in this implementation is described in process below. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a microservice identity dynamic access control method in an embodiment of this application.

[0031] S101. When a target user initiates an access request to the first microservice through a client, the authentication service authenticates the target user. After successful authentication, an initial access token is generated. The initial access token contains the user's identity identifier and the initial call chain identifier. The initial call chain identifier contains only the target user's identity node.

[0032] In the initial access token generation step, the client represents the application programming interface (API) used by the user to initiate service access. The authentication service refers to a dedicated service module used to verify user identity. The initial access token represents an authorization credential containing user identity information and call chain information. The user identity identifier is used to uniquely identify the target user. The initial call chain identifier refers to the ordered sequence of nodes involved in the service call process. The identity node represents the basic node in the call chain that represents the user's identity.

[0033] When a user needs to access the microservice system, they first initiate an access request through the client interface provided by the system. Upon receiving the request, the authentication service retrieves the user's credentials, including username and password. The authentication service verifies the user credentials according to preset authentication rules. If verification is successful, an access token containing the user's unique identifier and the initial call chain is generated. At this point, the initial call chain only contains nodes representing the user's identity and is used to record subsequent service calls.

[0034] The implementation methods upon successful verification include: Optionally, the authentication service first checks whether the request contains valid user credentials, then queries the user information database to verify the validity of the credentials. After successful verification, a token ID containing a random string is generated, and the user identifier and initial call chain information are encoded and encapsulated into the token. Finally, the token is digitally signed. Optionally, the authentication service completes user verification by calling an external identity authentication system. After successful verification, a token ID is generated based on the timestamp and user identifier, an initial call chain containing only the user's identity node is created, the call chain and user information are written into the token payload, and the token is signed using an asymmetric encryption algorithm.

[0035] The implementation methods for verification failure include, optionally, the authentication service returning an error code for authentication failure and recording the reason for failure in the log; optionally, the authentication service counting the number of verification failures, temporarily locking the user account when the number of failures exceeds a threshold, and sending a security alert to the user through a preset channel. It is understood that other methods can also be used to achieve user authentication and token generation, which are not limited here.

[0036] S102. When the first microservice receives the access request, it parses the target data identifier in the access request and determines whether the second microservice needs to be called based on the target data identifier.

[0037] In the access request parsing step, the access request represents a call message sent by the client to a microservice. The target data identifier is an encoding used to uniquely identify the requested data. The first microservice represents the service node receiving the user request. The second microservice represents other service nodes that may need to be called. After receiving the client's access request, the first microservice first parses the data identifier information contained in the request. Then, based on the predefined service dependency configuration, it determines whether processing the data requires calling functions provided by other microservices. This determination process considers factors such as the type and format of the data identifier and the corresponding business scenario.

[0038] When other services need to be called, the implementation methods include, optionally, the first microservice extracts the data identifier parameter from the request URL, queries the service registry to obtain the data processing dependency relationship, determines whether the second microservice needs to be called according to the dependency configuration, records the judgment result for subsequent processing, and creates a service call context containing the target service information and call parameters; Optionally, the first microservice parses the data identifier field in the request body, compares it with the service call rules cached locally to determine the processing dependencies, associates the determination result with the request context and saves it, and prepares subsequent service call information, including the call method, timeout settings, etc.

[0039] When no other services need to be called, the implementation methods include, optionally, the first microservice directly processes the request data, selects the corresponding processing logic according to the data identifier, performs data verification and transformation, returns the processing result to the client, and records the processing log at the same time; Optionally, the first microservice completes data processing locally, including data format validation, business rule checks, and result encapsulation, while asynchronously recording processing logs, and finally encapsulating the response result for return.

[0040] It is understandable that other methods can be used to implement request parsing and call judgment, and no restrictions are imposed here.

[0041] S103. If necessary, the first microservice generates a derived access token based on the initial access token. The derived access token appends the service identity identifier of the first microservice to the initial call chain identifier to form an extended call chain identifier.

[0042] In the derived access token generation step, the derived access token represents a new authorization credential generated based on the initial token. The service identity identifier is the code used to uniquely identify the microservice. The extended call chain identifier represents the complete call path after appending new nodes to the initial call chain. When it is determined that a second microservice needs to be called, the first microservice creates a new derived token based on the received initial access token. During the creation process, the first microservice adds its own service identifier as a new node to the end of the call chain, forming an extended call chain containing user nodes and service nodes. The newly generated derived token contains complete call chain information.

[0043] The implementation methods when the derived token is successfully generated include, optionally, the first microservice parses the initial token to obtain the call chain, verifies the validity and integrity of the token, adds a new node containing the service ID and timestamp, signs the extended call chain using the private key, and encapsulates the signature result and the original token information together into the derived token; Optionally, the first microservice extracts call information from the initial token, verifies the token signature and expiration time, creates a new node containing the service identifier and call parameters, appends the node to the call chain, recalculates the token digest, and generates a derived token using the digest value and service key.

[0044] The implementation methods for when the derived token generation fails include, optionally, the first microservice capturing the token processing exception, returning an error message indicating that the token generation failed, recording a detailed error stack, terminating subsequent calls, and releasing related resources; Optionally, the first microservice records failure details, including failure time, cause, and context information, sends an alarm notification to the monitoring system, executes a preset failure handling process, and ensures system state consistency.

[0045] It is understandable that other methods can be used to generate derived tokens, and this is not limited here.

[0046] S104. When the first microservice initiates a call to the second microservice, the second microservice extracts the extended call chain identifier from the derived access token, traverses each service identity identifier in the extended call chain identifier, and identifies whether there is a third-party service identity identifier in the extended call chain identifier.

[0047] In the call chain identification step, the second microservice represents the target service node receiving the call request. The extended call chain identifier represents the complete service call path record. The third-party service identity identifier refers to the external service identifier that is not internal to the system. When the first microservice initiates a call, the second microservice first parses the complete call chain information from the received derived access token, and then traverses each service identifier in the call chain according to the node order, determining whether a third-party service node exists based on preset service identity rules.

[0048] In practical applications, the second microservice can employ various methods to complete call chain parsing and identity verification. One approach is for the second microservice to extract call chain data from the derived token, verify the digital signature of the call chain, parse the call chain into an ordered list of nodes, traverse the node list to check the registration information of each service identifier, and determine whether it is a third-party service based on the service registration domain. Another method involves the second microservice obtaining call chain information from the token payload, verifying the integrity hash value of the call chain, constructing a node traversal iterator, sequentially reading the service identifier of each node, and querying the service metadata database to determine the service identity type.

[0049] During the call chain verification process, if any anomalies are detected, the system needs to take appropriate measures. When the second microservice detects a failure in call chain integrity verification, it will record the exception information, return an invalid token error response to the caller, and abort the current request processing. Furthermore, if the second microservice detects an anomaly in the call chain structure, it will generate a detailed error log, execute a security alert process, and refuse to continue processing request data.

[0050] It is understandable that other methods can be used to parse the call chain and identify identities, and no restrictions are imposed here.

[0051] In some embodiments, this step specifically includes: The first microservice extracts the initial call chain identifier from the initial access token, obtains its own service identity identifier, uses the service identity identifier as a new node, appends the new node to the end of the initial call chain identifier to generate an extended call chain identifier, and encapsulates the extended call chain identifier into the derived access token.

[0052] The initial access token is a digital credential containing user identity and call chain information, encoded in JWT format. The initial call chain identifier is an ordered sequence recording the service call path, storing node information using a JSON array. The service identity identifier is a unique identifier for the microservice, consisting of the service name and version number. New nodes represent the current service's call chain nodes, containing service identifiers and timestamp information. The extended call chain identifier is the complete path record after adding new nodes to the original call chain. The derived access token is a new credential generated based on the initial token, inheriting the original token's basic information.

[0053] In the implementation process, the first microservice first decodes and verifies the initial access token, extracting the initial call chain array from the token's payload. Next, it obtains its service identification information from the service registry, including the service ID "service-001" and version number "v1.0". Then, it creates a new call chain node, with the node structure containing three fields: serviceId, version, and timestamp, filled with the service identification information and the current timestamp, respectively. The first microservice appends the new node object to the end of the initial call chain array, forming a complete call chain containing user and service nodes. Finally, it signs the expanded call chain along with other information from the original token to generate a new derived access token. This entire process ensures the continuity and integrity of the call chain, providing traceable identity information for subsequent service calls. For example, if the initial call chain is [{"type":"user","id":"user-001"}], it expands to [{"type":"user","id":"user-001"}, {"type":"service","id":"service-001","version":"v1.0","timestamp":1621234567890}].

[0054] S105. When a third-party service identity is present, the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient.

[0055] Trust level represents a quantitative assessment indicator of service security. De-identification strength coefficient is a calculation parameter that controls the degree of data de-identification. Enhanced de-identification processing refers to data protection measures that are dynamically adjusted according to security requirements. After identifying a third-party service node, the second microservice queries the service's trust level information from a pre-set service rating database, calculates a specific de-identification coefficient based on the trust level, and then selects an appropriate data processing strategy based on the de-identification coefficient.

[0056] For data anonymization of third-party services, the system provides a flexible implementation mechanism. The second microservice first queries the service rating database to obtain historical performance data of the third-party service, including service stability and security event records. It then calculates a comprehensive trust score based on multi-dimensional indicators, converts the trust score into an anonymization strength coefficient, and selects the corresponding field anonymization rules. Simultaneously, the second microservice can also read real-time monitoring indicators of the third-party service, calculate the current trust level using a preset evaluation model, determine the anonymization coefficient based on the deviation of the trust level from the baseline, and apply the appropriate data transformation algorithm.

[0057] During the data masking process, various anomalies may occur that require proper handling. If the second microservice detects an anomaly during the masking process, it will immediately roll back the executed data transformation, return a failure error message, and record a detailed reason for the failure. When the second microservice detects an anomaly in the execution of the masking rules, it will activate a data protection emergency mechanism to temporarily increase the masking strength and ensure that sensitive information is not leaked.

[0058] It is understandable that other methods can be used to achieve data anonymization, and no specific method is specified here.

[0059] In some embodiments, this step specifically includes: The second microservice obtains a set of security indicators corresponding to the third-party service identity from a preset service trust level library. This set of security indicators includes service runtime, call frequency, and data processing compliance score. The second microservice calculates the dynamic trust level of the third-party service identity based on the set of security indicators. The second microservice calculates the de-identification strength coefficient based on the difference between the dynamic trust level and the preset baseline trust level. The second microservice selects the corresponding graded de-identification strategy based on the de-identification strength coefficient and performs adaptive strength de-identification processing on the sensitive fields in the original data record.

[0060] The Service Trust Level Library is a database of security assessment metrics for storage services, recording the mapping relationship between service identifiers and security metrics using key-value pairs. The security metric set includes three quantitative indicators: service runtime (in hours), call frequency (times / minute), and compliance score (0-100). The dynamic trust level is a service trustworthiness assessment value calculated based on real-time security metrics, ranging from 0 to 1. The baseline trust level is a system-preset standard trustworthiness threshold used for difference comparison. The data anonymization strength coefficient is a coefficient value controlling the degree of data anonymization, ranging from 0.1 to 1.0. The tiered anonymization strategy is a set of data processing rules formulated based on different strength coefficients.

[0061] In actual implementation, the second microservice first queries the security metrics of third-party services from the trust level database using the service identifier. For example, regarding service runtime, if the service runs continuously for more than 720 hours, the score is 1.0; for every 24 hours less runtime, the score decreases by 0.1. Call frequency is calculated by monitoring the average call volume over the last 10 minutes; if it is below the preset threshold of 50 calls / minute, the score is 1.0; for every 10 calls / minute exceeding this threshold, the score decreases by 0.1. Compliance scoring directly uses the latest evaluation score; a score of 90 or above is 1.0; for every 10 points lower, the score decreases by 0.2. The three scores are then weighted and averaged (with weights of 0.3, 0.3, and 0.4 respectively) to obtain the dynamic trust level. The dynamic trust level is then compared to the baseline level (default 0.8), and the absolute value of the difference is calculated. This value is multiplied by an adjustment factor of 2.0 to obtain the de-identification strength coefficient. Finally, the appropriate de-identification strategy is selected based on the strength coefficient: coefficients of 0.1-0.3 employ complete de-identification (all fields are hidden), 0.3-0.6 employ partial de-identification (retaining the first and last characters), and 0.6-1.0 employ mild de-identification (only hiding the sensitive parts). For example, the de-identification results for the mobile phone number "13812345678" under different strengths are "****", "1385678", and "138**5678", respectively. The entire process achieves adaptive data protection based on service trustworthiness.

[0062] S106. When there is no third-party service identity identifier, the second microservice queries the original data record from the data storage layer based on the user identity identifier, and performs basic desensitization processing on the original data record according to the permission level corresponding to the user identity identifier.

[0063] The data storage layer represents the system's persistent storage component. Permission levels refer to the user's access control level over data. Basic data masking represents the standard data protection process based on user permissions. After confirming that there are no third-party services in the call chain, the second microservice uses the user's identity to query the corresponding permission configuration, retrieves the original data from the data storage layer, and performs the appropriate data masking based on the user's permission level.

[0064] For data access control of internal services, the system implements a user permission-based data masking mechanism. The second microservice first queries the permission management system to obtain the user's data access level, filters visible data fields according to the access level, applies default field masking rules, generates a data view that meets the permission requirements, and records data access logs. In addition, the second microservice also supports reading personalized data display preferences from user configurations, and combining them with the system's preset masking strategies to perform hierarchical filtering and transformation of the original data to ensure that the returned results conform to the user's permissions and preference settings.

[0065] In the permission verification and data processing stages, the system needs to strictly control abnormal situations. When the second microservice detects insufficient user permissions, it will return an access restriction message, record the unauthorized access event, and notify the security audit module. If the second microservice discovers abnormal permission configuration, it will use the strictest data masking strategy to process the data and trigger the permission configuration check process to ensure data access security.

[0066] It is understandable that other methods can be used to achieve basic desensitization, and no specific method is specified here.

[0067] In some embodiments, this step specifically includes: The second microservice obtains a set of scenario tags corresponding to the user's identity identifier. This set of scenario tags is used to identify the purpose of data usage for the user's identity identifier in different business scenarios. The second microservice filters the original data records that match the current business scenario from the data storage layer based on the set of scenario tags, and identifies sensitive fields in the original data records. The second microservice obtains the data sensitivity preferences set by the user's identity identifier. These data sensitivity preferences are used to indicate the personalized display methods for different types of sensitive fields. The second microservice generates field desensitization rules based on the permission level and data sensitivity preferences, and performs basic desensitization processing on sensitive fields according to the field desensitization rules.

[0068] A scenario tag set is a group of identifiers describing the scenarios in which user data is used, employing a multi-dimensional tag system to record business scenario attributes. Sensitive fields refer to data attributes that require protection, including types such as personal identifiers and asset information. Data sensitivity preferences are user-defined data display options used to personalize the way fields are displayed. Field anonymization rules are data processing instructions generated based on permission levels and user preferences, specifying concrete anonymization procedures.

[0069] The specific data processing flow of the second microservice is as follows: First, it retrieves a set of scenario tags from the user configuration. The tag structure includes attributes such as business type (e.g., payment, query), purpose (e.g., risk control, statistics), and time range. For example, the tag set might be {businessType: "payment", purpose: "risk-control", timeRange: "real-time"}. Next, it uses these tags to construct data query conditions and filters data records that match the current scenario from the data storage layer. For the data returned by the query, it identifies fields that need protection through a predefined sensitive field mapping table, such as mobile phone numbers, ID card numbers, and bank card numbers.

[0070] The system then reads the user's data sensitivity preference configuration. This preference configuration is stored in JSON format and defines display rules for different types of sensitive fields, such as {phoneNumber: "partial", idCard: "masked", bankCard: "lastFour"}. The second microservice combines the user's permission level (0-9) with their sensitivity preferences to generate specific field masking rules. These rules define how fields are processed, including complete hiding, partial display, and format conversion. Higher permission levels result in lower masking levels. For example, for a user with permission level 7, the phone number "13812345678" is processed as "138****5678" based on the "partial" preference; for a user with permission level 3, the same number might be processed as "****345678". Finally, the system performs masking operations on sensitive fields in the data records according to the generated rules, ensuring that the returned results meet both the user's personalized needs and access control requirements.

[0071] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the microservice identity dynamic access control method in this application embodiment.

[0072] S201. When a third-party service identity identifier exists, the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient.

[0073] Understandably, this step is similar to step S105, and will not be described again here.

[0074] S202. The second microservice sets a call depth counter in the derived access token. The initial value of the call depth counter is equal to the number of nodes contained in the extended call chain identifier.

[0075] The call depth counter is a counting mechanism used to track and control the call hierarchy of microservices, stored using a 32-bit integer value. The derived access token is the identity credential passed during a service call, consisting of a token header, payload, and signature. The extended call chain identifier is an ordered sequence recording the service call path, storing service node information using a JSON array. The number of nodes reflects the total number of service nodes involved in the current call chain.

[0076] In a microservice architecture, precise counting and limiting of call depth are needed to control the complexity of service calls. The implementation process first parses the extended call chain data in the derived access token, traverses the call chain array, and counts the number of nodes. For example, when the call chain contains three nodes: [{"nodeId":"user-001","type":"user"}, {"nodeId":"service-A","type":"service"}, {"nodeId":"service-B","type":"service"}], the count is set to 3. Then, a depth-counter field is added to the header of the derived access token, the count value is written, and BASE64 encoded. Simultaneously, a depth_info object is added to the token payload to record the initial setting time and update history of the counter. Finally, the token signature is recalculated to ensure the integrity of the counting information. This mechanism provides the basic data support for subsequent call depth control.

[0077] S203. When the second microservice calls the third microservice, the second microservice compares the current value of the call depth counter with the preset maximum call depth threshold.

[0078] The current value of the call depth counter represents the accumulated service call layers, increasing as the call chain extends. The preset maximum call depth threshold is a system-defined upper limit for the call chain length, used to prevent the call chain from getting out of control. The third microservice represents the next processing node in the call chain.

[0079] When making inter-service calls, microservice systems must strictly control the extent of the call chain. Specifically, the `depth-counter` field value is first extracted from the header of the derived access token, and the BASE64 encoded value is decoded into an integer. A maximum call depth threshold (e.g., `maxCallDepth=5`) is defined in the system configuration file as the criterion. The current count value is compared with the threshold using the formula: `depthExceeded = currentDepth > maxCallDepth`. Simultaneously, the verification timestamp and verification result are recorded in the token's `depth_info` object. This verification mechanism ensures the controllability of service calls and prevents system resource exhaustion or performance degradation due to excessively long call chains.

[0080] S204. If the current value exceeds the preset maximum call depth threshold, the third microservice rejects the call request from the second microservice to the third microservice.

[0081] The over-limit handling mechanism specifies the measures to be taken when the call depth exceeds the limit. This involves handling the rejection of call requests, including the generation and return of error responses. The third microservice, as the target service node, is responsible for executing the final access control. The second microservice, as the source service node that initiated the call, needs to handle the case of call failure.

[0082] In distributed systems, call depth control directly impacts system stability and availability. When call depth exceeds the limit, the following process is implemented: First, the third microservice constructs a standard error response object, including the error code (DEPTH_EXCEEDED=4001), error description (Calldepthlimitexceeded), current depth value, and maximum allowed depth. The response header sets Content-Type to application / json and uses the status code 429 (Too Many Requests). Detailed information is appended to the response body: {"error_code": 4001, "message": "Calldepthlimitexceeded", "current_depth": 6, "max_depth": 5, "timestamp": "2025-12-13T10:30:00Z"}. The third microservice returns this response to the second microservice and logs the rejection event. This mechanism ensures system controllability and stability by hard-limiting call depth. The logs are recorded in a structured format, including fields such as call source, target service, depth information, and timestamp, which facilitates subsequent problem analysis and system optimization.

[0083] S205. The second microservice collects the value of the call depth counter at preset time intervals and generates a historical value sequence of the call depth counter.

[0084] The preset time interval is a fixed data sampling period, typically set to 1-5 seconds. The call depth counter value is the call level statistics at a specific moment. The historical value sequence is a collection of counter sample data stored in chronological order, implemented using a circular array.

[0085] Microservice systems require continuous monitoring of the depth trends of service calls. In practice, the second microservice starts a separate monitoring thread that periodically reads the depth-counter value at a preset sampling interval (e.g., 2 seconds). Each sample packages the acquired value and the sampling timestamp into a sampling record: {timestamp: "2025-12-13T10:30:00Z", depth_value: 4}. The system uses a circular array of size 100 to store the most recent sampling records, overwriting the oldest data when the array is full. Simultaneously, the sampled data is asynchronously written to a time-series database, with the record format (service_id, timestamp, depth_value) for long-term trend analysis. This sampling mechanism provides fundamental data support for load analysis.

[0086] S206. The second microservice calculates the average of N consecutive values ​​in the historical numerical sequence and uses the average as the load metric for the current call chain.

[0087] The historical numerical sequence consists of depth counts from the most recent N sampling periods. The N consecutive values ​​are typically between 10 and 20, representing the analysis window size. The average value is calculated using a sliding window method. The load metric reflects the busyness of the call chain.

[0088] The system assesses service call load by analyzing historical data. The calculation process first reads the most recent N (e.g., 15) sample records from a circular array, checking the continuity and validity of the data. The average is calculated using the cumulative summation formula: loadMetric = (∑depth_values) / N. For example, if the 15 sample values ​​for a certain time window are [4, 4, 5, 4, 5, 5, 4, 5, 6, 5, 4, 5, 4, 5, 5], the calculated average load value is 4.67. The system encapsulates the calculation result and time window information into a load record: {window_start: "2025-12-13T10:30:00Z", window_end: "2025-12-13T10:30:30Z", load_metric: 4.67}. This calculation method smooths out short-term fluctuations and reflects the actual load level of the call chain.

[0089] S207. When the load metric exceeds the preset load threshold, the second microservice will reduce the preset maximum call depth threshold by the preset adjustment step.

[0090] Load metrics reflect the busyness of the call chain. The preset load threshold is the maximum load level allowed by the system, such as 4.5. The preset adjustment step size is the unit value for dynamically modifying the depth threshold, typically 1. The maximum call depth threshold is the dynamically adjustable upper limit of the depth.

[0091] The system responds to load changes by dynamically adjusting the depth threshold. The adjustment process first compares the current load metric with the preset threshold: isOverloaded = loadMetric > loadThreshold. When an overloaded state is detected, the threshold is adjusted: newMaxDepth = currentMaxDepth - adjustStep. For example, when the load metric is 4.8, exceeding the preset threshold of 4.5, the current maximum call depth of 5 is reduced by 1 to obtain a new threshold of 4. After the system adjusts the threshold, it updates the configuration: {max_depth: 4, update_time: "2025-12-13T10:30:30Z", trigger_load: 4.8}. This adaptive mechanism alleviates system pressure by restricting the call depth.

[0092] S208. The second microservice counts the load metrics of each call path and stores the call paths with load metrics less than the preset load threshold into the path optimization list. Each record in this path optimization list contains a call path identifier and the corresponding load metric.

[0093] A call path is a call sequence between services, represented by a node list. The load metric is the load indicator for each path. The preset load threshold is used to filter low-load paths. The path optimization list stores path information that meets the optimization conditions.

[0094] The system needs to identify and record service call paths with good performance. During implementation, the second microservice maintains a path-load mapping table, where the key is the call path identifier (such as "serviceA->serviceB->serviceC") and the value is the corresponding load metric record. The system periodically traverses the mapping table to filter paths with load values below the threshold: paths.filter(p => p.loadMetric < loadThreshold). The filtered results are stored in the optimization list, and each record format is: {path_id: "path-001", service_chain: ["serviceA", "serviceB", "serviceC"], load_metric: 3.8, update_time: "2025-12-13T10:30:00Z"}. These records can be used for subsequent call path optimization and load balancing decisions. The system also maintains a path index to support quick query of optimized paths based on conditions such as load value and update time.

[0095] The following describes the microservice identity dynamic access control system in the embodiments of the present invention application from the perspective of hardware processing. Please refer to Figure 3This is a schematic diagram of the physical device structure of a microservice identity dynamic access control system in this application embodiment.

[0096] It should be noted that, Figure 3 The structure of the microservice identity dynamic access control system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0097] like Figure 3 As shown, the microservice identity dynamic access control system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 302 or programs loaded from storage section 308 into random access memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0098] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0099] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0100] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0102] Specifically, the microservice identity dynamic access control system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the microservice identity dynamic access control method provided in the above embodiment.

[0103] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the microservice identity dynamic access control system described in the above embodiments; or it may exist independently and not assembled into the microservice identity dynamic access control system. The storage medium carries one or more computer programs, which, when executed by a processor of the microservice identity dynamic access control system, cause the microservice identity dynamic access control system to implement the microservice identity dynamic access control method provided in the above embodiments.

[0104] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0105] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0106] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for dynamic access control of microservice identity, characterized in that, An application is made to a microservice identity dynamic access control system, which includes an authentication service, a first microservice, and a second microservice. The method includes: When a target user initiates an access request to the first microservice through a client, the authentication service verifies the target user's identity. After the identity verification is successful, an initial access token is generated. The initial access token contains a user identity identifier and an initial call chain identifier. The initial call chain identifier contains only the target user's identity node. When the first microservice receives the access request, the first microservice parses the target data identifier in the access request and determines whether the second microservice needs to be called based on the target data identifier. If necessary, the first microservice generates a derived access token based on the initial access token, and appends the service identity identifier of the first microservice to the initial call chain identifier to form an extended call chain identifier. When the first microservice initiates a call to the second microservice, the second microservice extracts the extended call chain identifier from the derived access token, traverses each service identity identifier in the extended call chain identifier, and identifies whether there is a third-party service identity identifier in the extended call chain identifier. When a third-party service identity is present, the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient.

2. The method according to claim 1, characterized in that, The first microservice generates a derived access token based on the initial access token, and the derived access token is appended with the service identity identifier of the first microservice to the initial call chain identifier to form an extended call chain identifier. The specific steps include: The first microservice extracts the initial call chain identifier from the initial access token; The first microservice obtains its own service identity identifier and uses the service identity identifier as a new node; The first microservice appends the new node to the end of the initial call chain identifier to generate the extended call chain identifier; The first microservice encapsulates the extended call chain identifier into the derived access token.

3. The method according to claim 1, characterized in that, The second microservice calculates a de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient, specifically including: The second microservice obtains a set of security indicators corresponding to the third-party service identity from a preset service trust level library. The set of security indicators includes service runtime, call frequency, and data processing compliance score. The second microservice calculates the dynamic trust level of the third-party service identity identifier based on the set of security indicators; The second microservice calculates the desensitization strength coefficient based on the difference between the dynamic trust level and the preset benchmark trust level; The second microservice selects the corresponding hierarchical desensitization strategy based on the desensitization strength coefficient and performs adaptive strength desensitization processing on the sensitive fields in the original data record.

4. The method according to claim 1, characterized in that, After the step of identifying whether a third-party service identity is present in the extended call chain identifier, the method further includes: When no third-party service identity identifier exists, the second microservice queries the original data record from the data storage layer based on the user identity identifier, and performs basic de-identification processing on the original data record according to the permission level corresponding to the user identity identifier.

5. The method according to claim 4, characterized in that, The second microservice queries the original data record from the data storage layer based on the user identity identifier, and performs basic data anonymization processing on the original data record according to the permission level corresponding to the user identity identifier. Specifically, this includes: The second microservice obtains the set of scenario tags corresponding to the user identity identifier, and the set of scenario tags is used to identify the data usage purpose of the user identity identifier in different business scenarios; The second microservice filters out original data records that match the current business scenario from the data storage layer based on the scenario tag set, and identifies sensitive fields in the original data records; The second microservice obtains the data sensitivity preference set by the user identity identifier, and the data sensitivity preference is used to indicate the personalized display method of different types of sensitive fields; The second microservice generates field desensitization rules based on the permission level and the data sensitivity preference, and performs basic desensitization processing on the sensitive fields according to the field desensitization rules.

6. The method according to claim 1, characterized in that, After the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient, the method further includes: The second microservice sets a call depth counter in the derived access token, and the initial value of the call depth counter is equal to the number of nodes contained in the extended call chain identifier; When the second microservice calls the third microservice, the second microservice compares the current value of the call depth counter with the preset maximum call depth threshold. If the current value exceeds the preset maximum call depth threshold, the third microservice rejects the call request from the second microservice to the third microservice.

7. The method according to claim 6, characterized in that, After the second microservice calculates the de-identification strength coefficient based on the trust level corresponding to the third-party service identity identifier, and performs enhanced de-identification processing on the original data record based on the de-identification strength coefficient, the method further includes: The second microservice collects the value of the call depth counter at preset time intervals and generates a historical value sequence of the call depth counter; The second microservice calculates the average of N consecutive values ​​in the historical numerical sequence and uses the average as the load metric for the current call chain; When the load metric exceeds the preset load threshold, the second microservice will reduce the preset maximum call depth threshold by a preset adjustment step. The second microservice collects the load metric values ​​of each call path and stores the call paths with load metric values ​​less than the preset load threshold in a path optimization list. Each record in the path optimization list includes a call path identifier and a corresponding load metric value.

8. A microservice identity dynamic access control system, characterized in that, The microservice identity dynamic access control system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the microservice identity dynamic access control system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the microservice identity dynamic access control system, the microservice identity dynamic access control system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the microservice identity dynamic access control system, the microservice identity dynamic access control system performs the method as described in any one of claims 1-7.

Images