Micro-service architecture-oriented user permission system building method and management system
By using annotations to declare data permissions in a microservice architecture and managing them globally based on an improved RBAC model, the complexity of permission configuration and insufficient synchronization in existing frameworks under microservice architecture are solved. This achieves data-level permission control and dynamic synchronization, adapting to complex business scenarios and various development frameworks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-22
- Publication Date
- 2026-04-03
AI Technical Summary
Existing Spring Security and Apache Shiro permission management frameworks lack native automatic permission discovery and synchronization mechanisms in microservice architectures, and permission configuration is complex, making it difficult to meet the permission management needs of complex business scenarios that require precise data ranges.
By using annotations to declare data permissions in business microservice modules, the unified permission module collects and stores the data permission list, performs global permission management based on the improved RBAC data model, supports fine-grained data operation control, and realizes dynamic synchronization and matching of permissions through scheduled tasks.
It achieves data-level access control in a microservice architecture, reduces development costs, supports precise adaptation to complex business scenarios, ensures the consistency and dynamism of permissions, adapts to reactive and non-reactive development frameworks, and improves system security.
Smart Images
Figure CN121786855A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data permission technology, specifically to a method and management system for building a user permission system for microservice architecture. Background Technology
[0002] The current mainstream permission management frameworks are Spring Security and Apache Shiro.
[0003] Spring Security, as part of the Spring ecosystem, provides Role-Based Access Control (RBAC) and robust permission management capabilities. It implements security control through a series of filter chains, supporting various security functions such as authentication, authorization, and session management, and can be seamlessly integrated with the Spring ecosystem. It achieves permission control through URL interception, method-level annotations, and other methods, offering high extensibility. Apache Shiro is another widely used security framework that provides authentication, authorization, encryption, and session management capabilities.
[0004] However, both frameworks have some shortcomings in practical applications. Spring Security's permission configuration is relatively complex, requiring the writing of numerous Java configuration files or XML configuration files, making the learning curve steep. While Shiro is relatively simple, its functionality is also limited, and it performs poorly when handling complex permission models. In a microservice architecture, neither framework has a native automatic permission discovery and synchronization mechanism, requiring additional development of related functions to implement inter-service permission management. Both frameworks also have limited support for fine-grained permission control, making it difficult to meet the needs of precise data-range permission management in complex business scenarios. Summary of the Invention
[0005] To help solve the above-mentioned technical problems, this application provides a method and management system for building a user permission system for microservice architecture.
[0006] Firstly, this application provides a method for building a user permission system for a microservice architecture, including the following steps: Permission initialization phase: S1: In each business microservice module, declare the data permissions of the interface using annotations; S2: When each business microservice module starts, scan and parse the annotations, generate a data permission list for the microservice module, and establish a mapping relationship between the request interface and the required data permissions; S3: Through a unified permission module independent of the business microservice modules, the data permission string list generated by each business microservice module in S2 is collected and stored to form a global permission list; the system administrator assigns the required permissions to users through the global permission list.
[0007] Permission verification runtime phases: S4: After successful user login authentication, query the set of permissions granted to the user through the unified permission module, and store the queried permission information into the user session; S5: When a user request reaches a certain business microservice module, based on the mapping relationship between the request interface and the required data permissions established in S2, the required data permission set corresponding to the permission list of the module to which the request belongs is found according to the interface path of the request, and the set is matched with the permissions cached in the current user session; S6: Determine whether to allow access based on the matching results.
[0008] Preferably, S1 includes: in the application code of each business microservice module, using a first annotation defined on the controller class to declare a data field, and using a second annotation defined on the request interface method to declare the specific operation scope and type of the data field; S2 includes: when each of the business microservice modules starts, scanning and parsing the first and second annotations in S1 through a permission manager to generate a list of all defined data permission strings in the microservice module; at the same time, establishing a mapping relationship between each request interface and one or more data permissions required to execute the interface through a permission matcher.
[0009] Preferred, The first annotation @DomainPermission contains the following attributes: module: Used to declare the system module to which the data domain belongs; name: The identifier name used to declare the data field; description: Used to provide a descriptive description of the data field; The data access scope defined in the second annotation @OperationPermission includes personal data and all data; the defined data operation types include at least one of read, write, save, delete, update, query, download, and upload.
[0010] Preferably, the user permission system is based on an improved RBAC data model. In S3, the unified permission module stores and manages global permissions based on this model; in S4 and S5, user permissions are queried and authenticated based on this model, which is represented by a nine-tuple: RBAC=(U,R,M,F,P,UR,MF,RF,FP) ,in, U Represents the system user set. R Represents the set of system roles. M Represents the system menu set. F This represents a set of menu functions. P Represents a set of data permissions, and P=D×DA×DO ,in D For system data sets, DA For the set of data access scopes, DO For data operation set, This indicates the allocation relationship between users and roles; This indicates the binding relationship between menu items and functions; This indicates the authorization relationship between roles and functions; This indicates the binding relationship between functionality and data permissions.
[0011] Preferably, the menu set owned by user u is defined by the following formula: , The set of data permissions owned by user u is defined by the following formula: .
[0012] Preferably, S3 includes: The unified permission module periodically queries the data permission lists of each business microservice module through a scheduled task and updates the global permission list.
[0013] Preferably, S3 includes: The unified permission module uses the Feign client to call the permission query interface provided by each business microservice module to complete the collection and synchronization of permissions.
[0014] Preferably, S6 includes: If the required data permission set is empty, or if there is an intersection between the required data permission set and the permission set cached in the user session, then the match is considered successful and access is allowed. If the required data permission set is not empty and there is no intersection with the permission set cached in the user session, then the match is considered unsuccessful and access is denied.
[0015] Preferably, the method also supports both reactive and non-reactive technology stacks. By detecting the running mode when the application starts, it automatically enables a reactive authentication filter based on WebSession or a non-reactive authentication filter based on HttpSession.
[0016] Secondly, this application provides a user permission management system for microservice architecture, which adopts the following technical solution: A user permission management system for microservice architecture, used to implement the user permission system construction method for microservice architecture as described in the first aspect, wherein it includes: Multiple business microservice modules, each deploying: The annotation declaration unit is used to declare the first annotation @DomainPermission on the controller class to define the data field, and to declare the second annotation @OperationPermission on the request interface method to define the data operation; The local permission processing unit includes: The permission manager is used to scan and parse the annotations when the module starts up, and generate a list of data permission strings for the module. The permission matcher is used to establish the mapping relationship between the requested interface and the required data permissions; A unified permission module, deployed as an independent microservice, communicates and connects with the multiple business microservice modules. The unified permission module includes: The permission collection and synchronization unit is used to collect and store data permission string lists from various business microservice modules, forming and maintaining a global permission list; The authentication execution unit is distributed in each business microservice module. When a user request arrives, it calls the permission matcher to obtain the required permission set and matches it with the permissions in the user session to determine whether access is allowed.
[0017] In summary, compared with the prior art, this application has the following beneficial effects: 1. The user permission data model has been improved, enabling data-level granular permission control in addition to supporting menu page and menu function permission control. Based on the enrichment of data objects, the data query path has been optimized. For user login scenarios, queries for user menu information follow a related query path of "user-role-menu function-menu information," while queries for user permission information follow a related query path of "user-role-menu function-data permission." The two query paths exhibit an equal number of related levels.
[0018] 2. Annotation-based permission declarations enable rapid standardization of API permission configuration, significantly reducing development costs and lowering the barrier to entry. Data permissions are generated in real-time using a dynamic calculation mechanism, avoiding potential inconsistencies and update lags in manual permission configuration and persistence. By expanding the scope of data access and the selectable dimensions of data operation behaviors, multiple differentiated authentication rule systems can be built for the same API, achieving precise adaptation to different business scenarios.
[0019] 3. A distributed user permission system adapted to microservice architecture effectively compensates for the shortcomings of traditional user permission systems in distributed scenarios, allowing microservice modules to focus on the development of core business functions without needing to concern themselves with the underlying implementation of user authentication logic. Under a microservice architecture, all modules can independently define and authenticate system permissions, and the addition or removal of a single module has no impact on the overall system operation. New microservice modules can dynamically access system permissions for business modules through configuration adjustments of the permission module.
[0020] 4. Supports rapid integration of reactive and non-reactive development frameworks, compatible with traditional Servlet application development scenarios, and also meets special development scenarios such as high concurrency and low latency. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the permission framework process based on user login and request initiation in this application; Figure 2 This is a code block 1 from this application, illustrating the code for initializing the permission set based on @DomainPermission. Figure 3 This is a code block 2 of the application, illustrating the code for completing the interface based on @OperationPermission - permission matching information. Figure 4 This is a code diagram illustrating the core logic of request permission matching in code block 3 of this application; Figure 5 This is a code diagram illustrating the core logic for periodically updating microservice module permissions in code block 4 of this application. Figure 6 To illustrate the code diagram showing the permission management required by the project after introducing this dependency component, the `@EnablePermissionSecurity` declaration in the startup class is provided. Figure 7 To illustrate the code diagram in the controller class where @EnablePermissionSecurity defines the data permissions for the corresponding controller after this dependency component is introduced; Figure 8This is a code diagram showing how @OperationPermission defines the operation type and scope of the corresponding interface in the controller method declaration after this dependency component is introduced. Detailed Implementation
[0022] The present application will be further described below with reference to the accompanying drawings. The structure and principle of the present application are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
[0023] Figure 1 This is a schematic diagram of the permission framework based on user login and request initiation in this application. The overall process is as follows: After a user initiates a login request through the login module, the system first performs authentication verification: if authentication fails, an error message is returned directly; if authentication succeeds, the system queries the user's permission information and stores it in the session storage module. When a user initiates a business request, the system simultaneously executes two parallel operations: on the one hand, it reads the set of permissions the user already possesses from the session; on the other hand, it obtains the set of permissions required for the current request. Subsequently, the permission matching module compares the two permission sets: if a match is found, the business logic is executed and a success message is returned; if a match fails, an error message is returned.
[0024] During system initialization, after project startup, predefined system permissions are first registered, followed by the initiation of a client permission synchronization mechanism. The system synchronizes permission data from other microservices via scheduled tasks, ultimately constructing a global permission set, which serves as the baseline data source for permission matching. The entire process, through a two-way permission verification mechanism (real-time matching of user permissions with requested permissions) and a distributed permission synchronization strategy, ensures the dynamism and consistency of permission management, effectively preventing unauthorized access and enhancing system security.
[0025] This application discloses a method for building a user permission system for a microservice architecture, which includes the following steps: Permission initialization phase: S1: In each business microservice module, declare the data permissions of the interface using annotations; S2: When each business microservice module starts, scan and parse the annotations, generate a data permission list for the microservice module, and establish a mapping relationship between the request interface and the required data permissions; S3: Through a unified permission module independent of the business microservice modules, the data permission string list generated by each business microservice module in S2 is collected and stored to form a global permission list; the system administrator assigns the required permissions to users through the global permission list.
[0026] Permission verification runtime phases: S4: After successful user login authentication, query the set of permissions granted to the user through the unified permission module, and store the queried permission information into the user session; S5: When a user request reaches a certain business microservice module, based on the mapping relationship between the request interface and the required data permissions established in S2, the required data permission set corresponding to the permission list of the module to which the request belongs is found according to the interface path of the request, and the set is matched with the permissions cached in the current user session; S6: Determine whether to allow access based on the matching results.
[0027] S1-S3 of this application correspond to Figure 1 The initialization phase (permission registration, synchronization, and global collection construction) corresponds to S4. Figure 1 User login and permission caching processes, S5 corresponding Figure 1 The request processing and permission matching process.
[0028] In this application embodiment, "each business microservice module" refers to the application unit in the microservice architecture that is responsible for implementing specific business functions (such as user management, order processing, inventory query, etc.) and can be independently developed, deployed, and extended. They are technically separate from the "unified permission module" responsible for permission management.
[0029] Each business microservice module is started as an independent Java application and its application context (ApplicationContext) is initialized. During this process, the permission manager and permission matcher defined in this application are initialized, and annotation scanning and permission mapping steps are performed.
[0030] This application requires that the "unified permission module" be independent of the business microservice module. This means that the module itself is also an independent microservice, deployed separately from the business microservice, and has its own independent data source and running process.
[0031] It has the following technical effects: Business microservices can focus on developing core business logic without worrying about complex permission collection, storage, and allocation logic. Permission management, as a cross-cutting concern, is handled by a dedicated unified permission module, making the system architecture clearer.
[0032] Because the permission information of all business microservices is aggregated into a single, unified permission module, system administrators can view and assign permissions globally through a unified interface. Simultaneously, this module proactively communicates with each business microservice via scheduled tasks, enabling timely detection of newly launched microservices or changes to their permission definitions, and updating the global view accordingly, thus achieving dynamic permission discovery and synchronization. This solves the problems of scattered, difficult-to-maintain, and easily inconsistent permission configurations in traditional distributed systems.
[0033] In this embodiment of the application, the first annotation @DomainPermission includes the following attributes: module: Used to declare the system module to which the data domain belongs; name: The identifier name used to declare the data field; description: Used to provide a descriptive description of the data field.
[0034] The standardized `@DomainPermission` annotation provides a unified and highly readable metadata definition for data resources within the system. This makes permissions themselves self-describing resources, facilitating automated processing and clear display in the management interface, thus improving the standardization and operability of permission management.
[0035] The data access scope defined in the second annotation @OperationPermission includes personal data and all data; the defined data operation types include at least one of read, write, save, delete, update, query, download, and upload.
[0036] The `@OperationPermission` annotation provides fine-grained, multi-dimensional permission control capabilities. By differentiating data scope (personal / all) and various operation types, it can accurately adapt to complex business scenario requirements, achieving precise permission control from the page level to the data row level and field level, thus solving the shortcomings of traditional permission frameworks in fine-grained control.
[0037] The user permission system is based on an improved RBAC data model. In S3, the unified permission module stores and manages global permissions based on this model; in S4, user permissions are queried and authenticated based on this model, which is represented by a nine-tuple: RBAC=(U,R,M,F,P,UR,MF,RF,FP) ,in, U Represents the system user set. R Represents the set of system roles. M Represents the system menu set. F This represents a set of menu functions. P Represents a set of data permissions, and P=D×DA×DO ,in D For system data sets, DA For the set of data access scopes, DO For data operation set, This indicates the allocation relationship between users and roles; This indicates the binding relationship between menu items and functions; This indicates the authorization relationship between roles and functions; This indicates the binding relationship between functionality and data permissions.
[0038] This improved RBAC nine-tuple data model, by introducing entities such as menu functions (F) and data permissions (P) and their complex relationships, theoretically perfects the complete mapping chain from user to role, to function, and then to specific data operation permissions.
[0039] The set of menus owned by user u is defined by the following formula: , The set of data permissions owned by user u is defined by the following formula: .
[0040] These two mathematical formulas clearly define the efficient derivation path for user final permissions. By abstracting complex multi-table join queries into clear set operations, not only is query performance optimized (especially when batch retrieving permissions during user login), but more importantly, it ensures the accuracy and consistency of permission calculations. Regardless of how permission relationships change, this path can accurately calculate the user's real-time permissions.
[0041] S2 includes: The unified permission module periodically queries the data permission lists of each business microservice module through a scheduled task and updates the global permission list.
[0042] S3 includes: The unified permission module uses the Feign client to call the permission query interface provided by each business microservice module to complete the collection and synchronization of permissions.
[0043] S4 includes: The permissions cached in the user session are obtained when the user logs in by querying their associated roles, menu functions, and bound data permissions; If the required data permission set is empty, or if there is an intersection between the required data permission set and the permission set cached in the user session, then the match is considered successful and access is allowed. If the required data permission set is not empty and there is no intersection with the permission set cached in the user session, then the match is considered unsuccessful and access is denied.
[0044] The method also supports both reactive and non-reactive technology stacks. By detecting the running mode when the application starts, it automatically enables either a WebSession-based reactive authentication filter or an HttpSession-based non-reactive authentication filter.
[0045] By combining scheduled tasks and the Feign client—specifically a declarative HTTP client—eventual consistency and automatic synchronization of permissions are achieved in a microservice architecture. Even if a new microservice module is deployed or the permission definitions of existing modules change, no manual intervention is required; the system automatically detects and updates the global view, ensuring the timeliness of permission data in a distributed environment. By adapting to both reactive and non-reactive technology stacks, this application breaks through the limitations of technical frameworks, enabling this permission system to be seamlessly applied to traditional applications and high-concurrency, low-latency reactive systems, thus expanding its application scenarios.
[0046] Specifically, the technical solution of this application includes: 1. User Permission Data Model Description Based on the traditional RBAC model, the user permission data model used in this invention has been optimized and expanded, supplementing the mapping relationship between menus and menu functions, the mapping relationship between data and permissions, etc. The specific modeling description is as follows: If u represents a system user, then the set of system users can be represented as: Let r represent a system role, then the set of system roles can be represented as follows: UR represents the user role relationships stored in the system. (u, r) represents the system role, where r is assigned to system user u. Therefore, the set of system roles owned by user u can be represented as: .
[0047] If m represents the system menu, then the system menu set can be represented as follows: If f represents a menu function, then the system menu function set can be represented as follows: MF represents the relationship between menus and menu functions stored in the system, and each menu function corresponds to only one unique system menu. ; RF represents the relationship between roles and menu functions stored in the system. (r, f) represents the system function f bound to the system role r. Therefore, the set of system menus owned by user u can be represented as follows: .
[0048] If d represents system data, then the system data set can be represented as follows: If da represents the system data access range, then the set of system data access ranges can be represented as follows: If 'do' represents a system data operation, then the set of system data operations can be represented as follows: P represents the data permissions within the system. P=D× DA×DO FP represents the relationship between menu functions and data permissions stored within the system. (f, p) represents the data operation permission P bound to the system menu function f. Therefore, the set of system data permissions possessed by user u can be represented as follows: .
[0049] In summary, the user access control data model is represented by a nine-tuple: RBAC=(U,R,M,F,P,UR,MF,RF,FP) .
[0050] The complete menu bar displayed to user u within the system can be defined as: ; The system permissions that user u possesses within the system can be defined as follows: ; 2. Annotation-based system authentication implementation Create the annotations @DomainPermission and @OperationPermission to define system data permissions: @DomainPermission is used for data definition, including data type, data type description, system module, and other information. Example: @DomainPermission(module="rbac", name="user", description="User Data") The `@OperationPermission` annotation is used to define data operations, including the data access scope (SCOPE, which can be either OWN for personal data or ALL for all data) and the data operation type (OPERATION, which can be either READ, WRITE, SAVE, DELETE, UPDATE, QUERY, DOWNLOAD, or UPLOAD). Example: `@OperationPermission(operations={OperationPermission.Operation.WRITE,OperationPermission.Operation.DELETE},scope=OperationPermission.Scope.ALL)` When the project starts, RequestPermissionManager and RequestPermissionMatcher initialize and generate a list of system data permissions. RequestPermissionManager generates a complete list of system data permissions based on @DomainPermission and @OperationPermission. The list contains all data permission operations defined within the system. Example: {"rbac:user:all:read","rbac:user:all:write","rbac:user:all:save","rbac:user:all:delete","rbac:user:all:update","rbac:user:all:query","rbac:user:all:download","rbac:user:all:upload"}. RequestPermissionMatcher generates a list of API and RequestPermission mappings based on the API definition, @DomainPermission, and @OperationPermission. Example: [{" / api / user / query",["rbac:role:all:read","rbac:role:all:query"]},{" / api / user / save",["rbac:role:all:write","rbac:role:all:save"]}).
[0051] When a user logs in, the system retrieves a list of data permissions held by the current user by querying the relationships between user, role, and menu functions, and stores this list in the session. When a user initiates an API request, the system obtains the set of permissions required by the corresponding API through RequestPermissionMatcher and matches it against the user's data permissions in the session. If a match is found, the API request is allowed; otherwise, it is rejected.
[0052] 3. System authentication implementation in microservice architecture In a microservice architecture, system data permissions defined by the `@DomainPermission` and `@OperationPermission` annotations are only valid within the current module; system data permissions between different microservice modules are not visible to each other. The `authority` module is the system permission management module for microservices, responsible for collecting permissions from microservice modules and assigning them to specific users. When the `authority` module starts, it reads the system permissions of business modules based on the application configuration and stores them centrally. When assigning user permissions, it retrieves all system permissions through the `authority` module's system permission query API. The `authority` module has a scheduled task that periodically checks for changes in system permissions between microservice modules. If the system permissions of a specific microservice module are updated, they can be dynamically added to the full system permission list via the scheduled task without affecting the operation of other microservice modules.
[0053] 4. Responsive system authentication implementation Heterogeneous technology stacks are a key feature of microservice architectures. Based on SpringMVC and SpringWebflux, two different programming paradigms, this architecture implements two sets of authentication filters: one for reactive applications and one for non-reactive ones. It also implements two separate session management systems: one for reactive WebSession and one for non-reactive HttpSession, thus providing system authentication support for both reactive and non-reactive Servlet applications. When the application starts, it detects the current application's running mode and activates the corresponding authentication filter accordingly. The reactive and non-reactive authentication filters are mutually exclusive; only one set of system authentication filters is active during application runtime.
[0054] This application also proposes a user permission management system for microservice architecture, used to implement the above-mentioned method for building a user permission system for microservice architecture, characterized by including: Multiple business microservice modules, each deploying: The annotation declaration unit is used to declare the first annotation @DomainPermission on the controller class to define the data field, and to declare the second annotation @OperationPermission on the request interface method to define the data operation; The local permission processing unit includes: The permission manager is used to scan and parse the annotations when the module starts up, and generate a list of data permission strings for the module. The permission matcher is used to establish the mapping relationship between the requested interface and the required data permissions; A unified permission module, deployed as an independent microservice, communicates and connects with the multiple business microservice modules. The unified permission module includes: The permission collection and synchronization unit is used to collect and store data permission string lists from various business microservice modules, forming and maintaining a global permission list; The authentication execution unit is distributed in each business microservice module. When a user request arrives, it calls the permission matcher to obtain the required permission set and matches it with the permissions in the user session to determine whether access is allowed.
Claims
1. A method for building a user permission system for a microservice architecture, characterized in that, Includes the following steps: Permission initialization phase: S1: In each business microservice module, declare the data permissions of the interface using annotations; S2: When each business microservice module starts, scan and parse the annotations, generate a data permission list for the microservice module, and establish a mapping relationship between the request interface and the required data permissions; S3: Through a unified permission module independent of the business microservice modules, collect and store the list of data permission strings generated by each business microservice module in S2 to form a global permission list; System administrators assign the necessary permissions to users through a global permission list; Permission verification runtime phases: S4: After successful user login authentication, query the set of permissions granted to the user through the unified permission module, and store the queried permission information into the user session; S5: When a user request reaches a certain business microservice module, based on the mapping relationship between the request interface and the required data permissions established in S2, the required data permission set corresponding to the permission list of the module to which the request belongs is found according to the interface path of the request, and the set is matched with the permissions cached in the current user session in S4. S6: Determine whether to allow access based on the matching results.
2. The method according to claim 1, characterized in that, S1 includes: In the application code of each business microservice module, the first annotation defined on the controller class is used to declare the data field, and the second annotation defined on the request interface method is used to declare the specific operation scope and type of the data field; S2 includes: when each of the business microservice modules starts, scanning and parsing the first and second annotations in S1 through a permission manager to generate a list of all defined data permission strings in the microservice module; at the same time, establishing a mapping relationship between each request interface and one or more data permissions required to execute the interface through a permission matcher.
3. The method for building a user permission system for a microservice architecture according to claim 2, characterized in that, The first annotation @DomainPermission contains the following attributes: module: Used to declare the system module to which the data domain belongs; name: The identifier name used to declare the data field; description: Used to provide a descriptive description of the data field; The data access scope defined in the second annotation @OperationPermission includes personal data and all data; the defined data operation types include at least one of read, write, save, delete, update, query, download, and upload.
4. The method for building a user permission system for a microservice architecture according to claim 1, characterized in that, The user permission system is based on an improved RBAC data model. In S3, the unified permission module stores and manages global permissions based on this model. In S4 and S5, user permissions are queried and authenticated based on this model, which is represented by a nine-tuple: RBAC=(U,R,M,F,P,UR,MF,RF,FP) ,in, U Represents the system user set. R Represents the set of system roles. M Represents the system menu set. F This represents a set of menu functions. P Represents a set of data permissions, and P=D×DA×DO ,in D For system data sets, DA For the set of data access scopes, DO For data operation set, This indicates the allocation relationship between users and roles; This indicates the binding relationship between menu items and functions; This indicates the authorization relationship between roles and functions; This indicates the binding relationship between functionality and data permissions.
5. The method for building a user permission system for a microservice architecture according to claim 4, characterized in that, The set of menus owned by user u is defined by the following formula: ， The set of data permissions owned by user u is defined by the following formula: 。 6. The method for building a user permission system for a microservice architecture according to claim 1, characterized in that, S3 includes: The unified permission module periodically queries the data permission lists of each business microservice module through a scheduled task and updates the global permission list.
7. The method for building a user permission system for a microservice architecture according to claim 1, characterized in that, S3 includes: The unified permission module uses the Feign client to call the permission query interface provided by each business microservice module to complete the collection and synchronization of permissions.
8. The method for building a user permission system for microservice architecture according to claim 1, characterized in that, S6 include: If the required data permission set is empty, or if there is an intersection between the required data permission set and the permission set cached in the user session, then the match is considered successful and access is allowed. If the required data permission set is not empty and there is no intersection with the permission set cached in the user session, then the match is considered unsuccessful and access is denied.
9. The method for building a user permission system for a microservice architecture according to claim 1, characterized in that, The method also supports both reactive and non-reactive technology stacks. By detecting the running mode when the application starts, it automatically enables either a WebSession-based reactive authentication filter or an HttpSession-based non-reactive authentication filter.
10. A user permission management system for microservice architecture, used to implement the user permission system construction method for microservice architecture as described in any one of claims 1 to 9, characterized in that, include: Multiple business microservice modules, each deploying: The annotation declaration unit is used to declare the first annotation @DomainPermission on the controller class to define the data field, and to declare the second annotation @OperationPermission on the request interface method to define the data operation; The local permission processing unit includes: The permission manager is used to scan and parse the annotations when the module starts up, and generate a list of data permission strings for the module. The permission matcher is used to establish the mapping relationship between the requested interface and the required data permissions; A unified permission module, deployed as an independent microservice, communicates and connects with the multiple business microservice modules. The unified permission module includes: The permission collection and synchronization unit is used to collect and store data permission string lists from various business microservice modules, forming and maintaining a global permission list; The authentication execution unit is distributed in each business microservice module. When a user request arrives, it calls the permission matcher to obtain the required permission set and matches it with the permissions in the user session to determine whether access is allowed.