A permission system-oriented mutual exclusion rule conflict detection method and system

Abstract

The present application belongs to the technical field of enterprise information security and permission management, and particularly relates to a mutual exclusion rule conflict detection method and system for a permission system. A database change log component is used to listen to the database binary log, the detection trigger mode is changed to event real-time driving, and millisecond or second-level conflict detection after permission change is realized. Local graph traversal is performed from the changed permission subject, and only the mutual exclusion rule subset affected by the change event is calculated. Graph traversal is performed from the left and right permission sets of the mutual exclusion rule, and the conflict users holding the permissions at both ends of the mutual exclusion rule are accurately locked through set intersection operation. Compared with the traditional user-by-user comparison method, the present application has higher calculation efficiency and lower false positive rate. The generated warning records provide a standardized data basis for subsequent audit tracing, compliance forensics and visual display, and solve the defects of the traditional scheme of only outputting Boolean results or simple user lists.

Description

Technical Field

[0001] This invention belongs to the field of enterprise information security and access control technology, specifically relating to a method and system for detecting conflicts in mutually exclusive rules for access control systems, applicable to access control compliance management scenarios for large-scale instant retail and fresh food e-commerce enterprises. Background Technology

[0002] As an on-demand retail company, Pupu Supermarket's business encompasses multiple core segments, including fresh produce procurement, warehouse management, store operations, delivery scheduling, supplier management, product pricing, and marketing activities. The company's internal access control system involves tens of thousands of employees (including headquarters staff, regional managers, store managers and clerks, procurement personnel, warehouse staff, and delivery personnel), millions of access permissions, and complex permission relationships transmitted through multiple paths based on organizational structure, job roles, and store affiliation. In this context, Separation of Duty (SoD) is a core requirement for the company's internal control and compliance management.

[0003] Taking the procurement and settlement process as an example: A single procurement officer must not simultaneously hold both "Purchase Order Creation" and "Purchase Order Approval" permissions; otherwise, the officer could create and approve purchase orders independently, posing a significant risk of fabricating procurement transactions and misappropriating company funds. Similarly, in warehouse management: a single warehouse manager must not simultaneously hold both "Inbound Slip Entry" and "Inventory Adjustment" permissions; otherwise, they could conceal missing goods by falsifying inbound entries and then adjusting inventory. Likewise, in supplier management: a single supplier administrator must not simultaneously hold both "Supplier Information Maintenance" and "Supplier Settlement Confirmation" permissions; otherwise, there is a risk of fabricating suppliers and fraudulently obtaining settlement funds.

[0004] Existing permission conflict detection technologies have the following shortcomings:

[0005] First, mainstream solutions rely on scheduled tasks to perform batch scans of all user permissions, with detection cycles typically lasting several hours or even once a day. For fast-paced, instant retail businesses like Pupu Supermarket, the detection of conflicts after permission changes lags significantly behind the actual effective time of the permissions. For example, if a purchasing agent is temporarily granted purchasing approval permissions during the day, but the scheduled detection task only runs at night, the agent already has the conditions for fraudulent operations during the daytime, which the system cannot detect and intercept in time, resulting in a significant compliance risk exposure. Furthermore, this type of solution cannot detect incremental changes—each detection requires rescanning all data, making it impossible to identify "which changes actually affect which mutually exclusive rules," leading to a severe waste of computing resources.

[0006] Second, the access control diagram of Pupu Supermarket encompasses tens of thousands of employees, hundreds of stores and forward warehouses, multiple regional management levels, and dozens of job roles, resulting in a complex and intricate network of relationships. Existing solutions typically have a computational complexity of O(n^2) in a full traversal scenario. 2 This involves performing a full Cartesian product comparison on tens of thousands or even hundreds of thousands of relational records. In large retail enterprises, this type of computation is extremely expensive, with a single detection potentially taking tens of minutes or even hours, making it difficult to implement in engineering and unable to meet the response time requirements for real-time detection.

[0007] Third, existing solutions typically only output a Boolean result indicating whether a conflict exists, or simply provide a list of conflicting users. When a conflict occurs, compliance auditors cannot determine through which permission granting path (organizational structure, job role, or store entity permission granting) the conflicting user obtained left-hand permissions, and through which path they obtained right-hand permissions. The lack of structured information such as conflict paths, conflict levels, and detection timestamps means that the warning results cannot support the needs of internal control audit tracing and compliance evidence collection, and also fail to provide clear rectification guidance for corporate management. Summary of the Invention

[0008] Therefore, a method for detecting mutual exclusion rule conflicts in a permission system is needed, including the following steps:

[0009] Step S1: Capture change events of the permission relationship table in real time using the database change log component;

[0010] Step S2: Perform partition routing based on the permission subject identifier of the change event, and deliver the change event to the corresponding task queue;

[0011] Step S3: Consume the change events in the task queue, starting from the subject of the change, traverse the permission relationship graph to determine the set of mutual exclusion rule relationships affected by the change events;

[0012] Step S4: For each mutual exclusion rule in the set of mutual exclusion rules, starting from the left-end permission set and the right-end permission set of the mutual exclusion rule, traverse the permission relationship graph to obtain the left-end reachable user set and the right-end reachable user set.

[0013] Step S5: Find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it is determined that there are conflicting users, and a structured warning record is generated.

[0014] Unlike existing technologies, the above technical solution has the following beneficial effects:

[0015] A complete closed-loop system for detecting mutual exclusion rule conflicts is constructed through five sequentially executed steps: real-time capture of change events (S1), partitioned route delivery (S2), task queue consumption and graph traversal delimitation (S3), two-way BFS traversal to obtain the set of reachable users (S4), and set intersection determination to identify conflicts and generate structured alerts (S5). The specific technical effects are as follows:

[0016] First, by listening to the database binary log through the database change log component (Canal), the detection triggering method is changed from the traditional scheduled full scan to event-driven real-time detection, realizing millisecond-level or second-level conflict detection after permission changes. This completely eliminates the detection window of several hours that exists in the traditional scheduled detection mode, meeting the rigid requirements of enterprise internal control compliance for real-time monitoring.

[0017] Second, starting from the subject of the changed permissions, a partial graph traversal is performed, calculating only the subset of mutual exclusion rules affected by this change event. This avoids indiscriminate and repeated calculations of all mutual exclusion rules and all permission relationship data, significantly reducing computational redundancy and system resource consumption.

[0018] Third, a graph traversal is performed starting from the left and right permission sets of the mutual exclusion rule to obtain two independent sets of reachable users. Then, the intersection operation of these sets is used to accurately identify conflicting users who simultaneously hold permissions at both ends of the mutual exclusion rule. Compared with the traditional user-by-user comparison method, this mathematical determination method has higher computational efficiency and a lower false alarm rate, and can identify all conflicting users at once.

[0019] Fourth, the generated warning records are structured data containing fields such as rule identifier, conflicting user, conflict path, and detection timestamp, providing a standardized data foundation for subsequent audit tracing, compliance evidence collection, and visualization, and solving the shortcomings of traditional solutions that only output boolean results or simple user lists.

[0020] Furthermore, the permission relationship table includes a user-user group relationship table, a user group-permission group relationship table, a permission group-permission item relationship table, an entity permission-user relationship table, a user-permission item direct authorization table, a mutual exclusion rule table, and a mutual exclusion rule relationship table.

[0021] Furthermore, in step S3, the step of starting from the changed permission subject, traversing the permission relationship graph, and determining the set of mutually exclusive rule relationships affected by the change event specifically includes:

[0022] Based on the permission relationship table type corresponding to the change event, extract the corresponding permission subject identifier;

[0023] Starting with the permission subject identifier as the starting node, and following the associated edges in the permission relationship graph, the recursive inheritance mode and the superior inheritance mode are used to traverse the superior and inferior nodes that have an inheritance relationship with the starting node, and obtain all mutually exclusive rule relationship records containing the starting node or any of the superior and inferior nodes, thus forming the mutually exclusive rule relationship set.

[0024] Furthermore, in step S4, traversing the permission relationship graph specifically includes:

[0025] A breadth-first search algorithm is used to perform multi-level path traversal on each permission item in the left-end permission set and the right-end permission set according to the permission inheritance hierarchy from user group, permission group, entity permission to user, to obtain all directly granted users and indirectly granted users who hold each permission item through the inheritance hierarchy.

[0026] Furthermore, in step S5, generating structured early warning records specifically includes:

[0027] The intersection of the left-end reachable user set and the right-end reachable user set is calculated layer by layer according to the permission inheritance hierarchy to determine the left-end conflict path and right-end conflict path corresponding to the conflicting user at each permission inheritance hierarchy.

[0028] The mutual exclusion rule identifier, conflicting user identifier, the left-end conflict path and the right-end conflict path of each permission inheritance level, the detection timestamp, and the application identifier corresponding to the change event are associated and stored to form the structured early warning record.

[0029] Furthermore, the traversal process in step S4 also includes an adaptive step for increasing the number of steps:

[0030] Obtain the actual inheritance depth of the permission relationship graph, and dynamically set the upper limit of the traversal steps based on the actual inheritance depth;

[0031] When the first-level directly authorized users of the current traversal node have covered all users, terminate the multi-level recursive traversal of the current traversal path.

[0032] Furthermore, following step S1, a local cache filtering step is also included:

[0033] Extract the application identifier corresponding to the change event, and query the local cache to see if there is a mutual exclusion rule enable flag corresponding to the application identifier;

[0034] If the enable flag is not present in the local cache or the enable flag indicates that the mutual exclusion rule is not enabled, the change event is filtered out and discarded, and subsequent steps are terminated.

[0035] Furthermore, in step S2, the step of performing partition routing based on the permission subject identifier of the change event specifically includes:

[0036] Based on the permission relationship table type corresponding to the change event, extract the corresponding partition key from the change event. The partition key is a user group identifier, permission module identifier, or entity permission identifier.

[0037] Perform a hash operation on the partition key, and deliver the change event to the corresponding partition of the message queue based on the hash operation result;

[0038] In step S3, the consumer terminal calls the processor corresponding to the permission relationship table type corresponding to the change event, parses the change record, and extracts the permission subject identifier.

[0039] Furthermore, it also includes an incremental compensation recalculation step:

[0040] By using a scheduled task, historical change event records generated within the current time window are retrieved at preset time intervals, and steps S3 to S5 are re-executed to compensate for undetected conflict events caused by message consumption delays.

[0041] A mutual exclusion rule conflict detection system oriented towards a permission system includes:

[0042] The event capture module is used to capture change events of the permission relationship table in real time through the database change log component;

[0043] The routing and distribution module is used to perform partition routing based on the permission subject identifier of the change event and deliver the change event to the corresponding task queue;

[0044] The event handling module is used to consume the change events in the task queue, starting from the changed permission subject, traversing the permission relationship graph to determine the set of mutual exclusion rule relationships affected by the change events;

[0045] The graph traversal calculation module is used to traverse the permission relationship graph for each mutual exclusion rule in the mutual exclusion rule relationship set, starting from the left permission set and the right permission set of the mutual exclusion rule respectively, to obtain the left reachable user set and the right reachable user set.

[0046] The conflict determination and early warning module is used to find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it is determined that there are conflicting users and a structured early warning record is generated.

[0047] Unlike existing technologies, the above technical solution has the following beneficial effects:

[0048] By modularizing the corresponding functions of the method into an event capture module, a routing and distribution module, an event handling module, a graph traversal and calculation module, and a conflict determination and early warning module, a highly cohesive and loosely coupled permission compliance detection system was constructed. The functional boundaries of each module are clearly defined: the capture module is responsible for accessing heterogeneous data sources; the routing and distribution module ensures orderly data flow and filters irrelevant events; the event handling module is responsible for differentiated parsing and rule delimitation; the graph calculation module carries the core traversal and optimization algorithms; and the early warning module is responsible for hierarchical judgment and structured output. These modules are sequentially connected to form a complete data pipeline: data flows in from the capture module, is distributed by the routing and distribution module, enters the event handling module for parsing and delimitation, then undergoes a two-way search by the graph traversal and calculation module, and finally, the conflict determination and early warning module outputs structured early warning results, creating a complete closed logical chain. The system as a whole inherits all the technical effects of the method (real-time performance, accuracy, high performance, auditability, and multi-tenancy support). At the same time, each module can be deployed on the same server or in a distributed manner, supporting horizontal scaling to adapt to the permission management needs of enterprises of different sizes. It has good maintainability and scalability, and is easy to deploy and integrate in a modular manner within the existing enterprise permission middleware architecture. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating the steps of a mutual exclusion rule conflict detection method for a permission system in this embodiment.

[0050] Figure 2 This is a structural block diagram of a mutual exclusion rule conflict detection system oriented towards a permission system, as described in this embodiment.

[0051] Label Explanation:

[0052] 10. Event Capture Module;

[0053] 20. Routing and distribution module;

[0054] 30. Event handling module;

[0055] 40. Graph traversal calculation module;

[0056] 50. Conflict detection and early warning module. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0058] See Figure 1This embodiment provides a method for detecting mutual exclusion rule conflicts in a permission system, comprising the following steps:

[0059] Step S1: Capture change events of the permission relationship table in real time using the database change log component;

[0060] The aforementioned database change log component refers to a software component capable of connecting to a database and parsing data change operations in real time from the database's binary log or transaction log. In this embodiment, the Canal component is used to implement this function. Canal is an open-source database incremental log parsing component that can simulate the interaction protocol of database slave nodes and parse data change logs from the database's master-slave replication stream. The aforementioned permission relationship table refers to a table in the database used to store the mapping relationships between various entities in the permission system. In this embodiment, the permission relationship table includes seven types of tables. The aforementioned change event refers to a data change record triggered by an insert, update, or delete operation performed on the permission relationship table. Each change event includes the change operation type, the change timestamp, the data row content before and after the change, and the name of the table involved in the change.

[0061] Step S2: Perform partition routing based on the permission subject identifier of the change event, and deliver the change event to the corresponding task queue;

[0062] The partition routing described above refers to the process of distributing change events to different partitions of a message queue according to specific rules. In this embodiment, Apache Kafka is used as the message queue middleware. The task queue mentioned above refers to the message queue used to temporarily store change events awaiting processing. Kafka divides the same topic into multiple partitions, and each partition is an ordered, immutable sequence of messages.

[0063] Step S3: Consume the change events in the task queue, starting from the subject of the change, traverse the permission relationship graph to determine the set of mutual exclusion rule relationships affected by the change events;

[0064] In the context of message queue technology, the aforementioned consumption specifically refers to the action of retrieving messages from a queue and performing business processing, encompassing the complete chain of retrieval, business calculation, and result confirmation. The aforementioned permission subject identifier refers to the unique identifier of the core permission entity involved in the change event within the system, including but not limited to job identifiers, department identifiers, store identifiers, or employee identifiers. The aforementioned permission relationship diagram is a directed graph structure constructed using various entities in the permission system as nodes and the granting, inclusion, and subordinate relationships between entities as edges. The aforementioned mutual exclusion rule is defined as a constraint that the left-end permission set L and the right-end permission set R cannot be simultaneously granted to the same employee. If the same employee simultaneously holds any permission in L and any permission in R, a conflict occurs.

[0065] Step S4: For each mutual exclusion rule in the set of mutual exclusion rules, starting from the left-end permission set and the right-end permission set of the mutual exclusion rule, traverse the permission relationship graph to obtain the left-end reachable user set and the right-end reachable user set.

[0066] The aforementioned set of mutually exclusive rules refers to the set of all mutually exclusive rule records related to the starting node or its associated nodes, found after traversing the graph starting from the changed permission subject. The left-end permission set and right-end permission set are two components of a mutually exclusive rule. Taking the "separation of procurement application and approval responsibilities" rule as an example, the left-end permission set includes "purchase order creation," and the right-end permission set includes "purchase order approval." The aforementioned set of reachable users refers to the set of all employees reachable by traversing the inheritance edges of the permission relationship graph starting from a given permission set. Each employee in the set holds at least one permission item in that permission set.

[0067] Step S5: Find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it is determined that there are conflicting users, and a structured warning record is generated.

[0068] The intersection mentioned above is a fundamental operation in set theory—the set of all elements that simultaneously belong to two sets. Here, the intersection is the set of employees who simultaneously hold permissions on both the left and right sides of a mutual exclusion rule. The structured alert record mentioned above refers to a standardized data record containing predefined fields such as mutual exclusion rule identifier, conflicting employee identifier, conflict path, detection timestamp, and application identifier.

[0069] The following is a specific implementation method of this embodiment, as detailed below:

[0070] Step S1: The access control database of Pupu Supermarket stores all employees, positions, access groups, access items, and their mapping relationships. The system continuously monitors the binary log of this database through the Canal component. When the HR system transfers employee Zhang San to the purchasing approval position, an insert operation occurs in the employee-position relationship table. The Canal component captures this change event within milliseconds and extracts the change record: Zhang San (employee ID P001) is associated with the "purchasing approval position" (position identifier ROLE_BUY_APPROVE).

[0071] Step S2: The system determines that the change event belongs to the employee-position relationship table type, with the partition key being the position identifier ROLE_BUY_APPROVE. The system performs a hash operation on this position identifier and delivers the change event to the corresponding partition of the Kafka message queue, ensuring that all permission change events for this position are consumed sequentially within the same partition, avoiding data corruption caused by concurrent processing.

[0072] Step S3: The consumer pulls the change event from the corresponding partition in Kafka. Starting with "Purchase Approval Position", it traverses along the association edges in the permission relationship graph to find all mutual exclusion rules associated with this position. The traversal reveals that "Purchase Approval Position" holds "Purchase Order Approval" permission through "Approver Permission Group", and this permission belongs to the right-hand permission set of mutual exclusion rule R001. Therefore, R001 is determined to be the affected mutual exclusion rule.

[0073] Step S4: The system iterates through both ends of the mutual exclusion rule R001. Starting from the left-hand permission set ("Purchase Order Creation"), it iterates along the path "Permission Item → Permission Group → Position → Employee". It finds that Zhang San holds this permission through the "Purchase Specialist Position", and the reachable user set on the left is {P001, P005}. Starting from the right-hand permission set ("Purchase Order Approval"), it performs a symmetrical traversal and finds that Zhang San also holds this permission through the newly added "Purchase Approval Position", and the reachable user set on the right is {L001, P001}.

[0074] Step S5: The system finds the intersection of the left-end reachable user set {P001, P005} and the right-end reachable user set {L001, P001}, obtaining {P001}. This indicates that Zhang San simultaneously holds permissions at both ends of the mutual exclusion rule, thus determining a conflict. The system generates a structured warning record: Mutual exclusion rule R001, conflicting employee Zhang San (P001), left-end conflict path "Purchase order creation → Purchasing specialist permission group → Purchasing specialist position → Purchasing department → Zhang San", right-end conflict path "Purchase order approval → Approver permission group → Purchasing approval position → Zhang San", detection timestamp 2026-07-18 10:23:08, application identifier: Purchasing Management System.

[0075] Based on the above technical solution, a complete closed loop for mutual exclusion rule conflict detection is constructed through five sequentially executed steps: real-time capture of change events, partitioned routing delivery, task queue consumption and graph traversal delimitation, two-way BFS traversal to obtain the reachable user set, and set intersection determination to identify conflicts and generate structured alerts. The specific technical effects are as follows: First, by listening to the database binary log through the database change log component, the detection triggering method is transformed from the traditional timed full scan to event-driven real-time detection, achieving millisecond or second-level conflict detection after permission changes, completely eliminating the several-hour detection window that exists in the traditional timed detection mode. Second, starting from the subject of the changed permission, a partial graph traversal is performed, calculating only the subset of mutual exclusion rules affected by this change event, avoiding indiscriminate repetitive calculations on the entire dataset. Third, two independent reachable user sets are obtained from the left and right ends of the mutual exclusion rules respectively, and the conflicting users are accurately identified through set intersection operations, finding all conflicting employees at once. Fourth, the generated alert records contain fields such as rule identifier, conflicting user, conflict path, and detection timestamp, providing a standardized data foundation for audit traceability.

[0076] As one implementation of this embodiment, the permission relationship table includes a user-user group relationship table, a user group-permission group relationship table, a permission group-permission item relationship table, an entity permission-user relationship table, a user-permission item direct authorization table, a mutual exclusion rule table, and a mutual exclusion rule relationship table.

[0077] The user-user group relationship table described above records the subordinate relationships between employees and positions. In Pupu Supermarket, user groups correspond to positions (such as purchasing specialist, warehouse supervisor, store manager), and this table records that an employee inherits all the permissions of that position after being appointed to it.

[0078] The user group-permission group relationship table mentioned above records the association between job positions and permission groups. That is, after a job position is granted a permission group, all employees on duty in that job position inherit the permissions contained in that permission group.

[0079] The aforementioned permission group-permission item relationship table records the inclusion relationship between permission groups and specific permission items. For example, the "Procurement Management Permission Group" includes permission items such as "Purchase Order Creation," "Purchase Order Modification," and "Purchase Order Inquiry," but does not include the "Purchase Order Approval" permission item, in order to achieve pre-control of separation of responsibilities.

[0080] The aforementioned entity-user relationship table records the direct granting relationships between entity-level permissions and employees. In Pupu Supermarket, entity permissions are typically isolated by store, region, or supplier. For example, a purchasing agent might be directly granted purchasing permissions for suppliers in the "Fuzhou region," but not for suppliers in the "Xiamen region."

[0081] The aforementioned user-permission direct authorization table records records of granting a certain permission to an employee directly without going through any intermediate layer of job position or permission group. It is usually used for special scenarios or temporary authorization.

[0082] The aforementioned mutual exclusion rule table records the basic definition information of mutual exclusion rules, including rule identifier, rule name (such as "Separation of Purchasing Application and Approval Responsibilities", "Separation of Warehousing and Inventory Adjustment Responsibilities", "Separation of Supplier Maintenance and Settlement Responsibilities"), left-side permission set, right-side permission set, and the application identifier to which the rule belongs.

[0083] The aforementioned mutual exclusion rule relationship table records the mapping relationship between mutual exclusion rules and specific permission items, which is used to quickly find the mutual exclusion rule associated with a certain permission item in subsequent graph traversal.

[0084] In the actual operation of Pupu Supermarket, employees' permissions come from diverse and complex sources: Zhang San, as a purchasing specialist, obtained purchasing-related permission groups through the "purchasing specialist" position (position inheritance); Zhang San was temporarily granted purchasing permissions for suppliers in the "Fuzhou area" (entity permission granting); Zhang San was temporarily added to the "purchasing approval position" (part-time position authorization). The above seven types of permission relationship tables fully cover all possible permission granting paths and mutual exclusion rule definitions.

[0085] When the HR system transfers Zhang San to the procurement approval position, the employee-position relationship table changes; when the permissions administrator adds the "Purchase Order Approval" permission to the "Approver Permission Group," the permission group-permission item relationship table changes; when the mutual exclusion rules administrator adds a "Separation of Procurement Application and Approval Responsibilities" rule, both the mutual exclusion rules table and the mutual exclusion rules relationship table change simultaneously. The system monitors all seven types of tables to ensure that any changes to the permission granting path are captured without omission.

[0086] By employing the aforementioned technical solutions, the seven core permission mapping tables are clearly identified, ensuring that any source of change in the Pupu Supermarket permission system that could potentially trigger permission transfer or changes in the status of mutual exclusion rules is monitored without omission. Whether it's HR organizational restructuring (employee transfer-in / transfer-out), changes to job permission templates, redistribution of entity permissions (isolated by store / region / supplier), or changes to the definition of the mutual exclusion rules themselves, any change in the permission granting path can be accurately captured, fundamentally eliminating blind spots in conflict detection caused by incomplete monitoring scope.

[0087] As one implementation of this embodiment, step S3, which involves traversing the permission relationship graph from the changed permission subject to determine the set of mutually exclusive rule relationships affected by the change event, specifically includes:

[0088] Based on the permission relationship table type corresponding to the change event, extract the corresponding permission subject identifier;

[0089] Starting with the permission subject identifier as the starting node, and following the associated edges in the permission relationship graph, the recursive inheritance mode and the superior inheritance mode are used to traverse the superior and inferior nodes that have an inheritance relationship with the starting node, and obtain all mutual exclusion rule relationship records that include the starting node or any of the associated nodes, thus forming the mutual exclusion rule relationship set.

[0090] The aforementioned permission subject identifier refers to the unique identifier of the core permission entity involved in the change event in the system. It varies depending on the type of permission relationship table corresponding to the change event—the change of the employee-position relationship table corresponds to the position identifier, the change of the permission group-permission item relationship table corresponds to the permission module identifier, and the change of the entity permission-employee relationship table corresponds to the entity permission identifier.

[0091] The starting node mentioned above is the node corresponding to the permission subject identifier in the permission relationship graph, and it is the starting point for graph traversal.

[0092] The aforementioned associated edges are directed edges connecting two nodes in the permission relationship graph, representing granting, inclusion, or dependency relationships between entities.

[0093] The recursive inheritance pattern described above refers to a pattern that starts from the initial node and recursively traverses both downstream and upstream along the edges of the permission relationship graph. Downstream traversal extends from the permission module to the permission group, from the permission group to the job position, and from the job position to the employee; upstream traversal traces back from the employee to the job position, from the job position to the permission group, and from the permission group to the permission module.

[0094] The aforementioned superior inheritance pattern refers to a traversal pattern that focuses on the "from superior to subordinate" transmission path of permissions. In the permission system of Pupu Supermarket, the permissions possessed by superior entities (such as permission modules and regional management levels) can be inherited by subordinate entities (such as positions and stores). The superior inheritance pattern ensures that the system can traverse all inheritance chains along the "from superior to subordinate" direction.

[0095] Suppose that the administrator of Pupu Supermarket modifies the permission items contained in the "Purchase Management Permission Group" by adding the "Purchase Order Approval" permission to this permission group. The permission relationship table type corresponding to this change event is a permission group-permission item relationship table, and the system extracts the permission subject identifier as the permission module identifier "Purchase Management Module".

[0096] The system starts with the "Procurement Management Module" as the initial node and employs a recursive inheritance pattern to traverse downstream to find all permission groups under this module (including "Procurement Management Permission Group," "Procurement Specialist Permission Group," etc.), then downstream to find all positions that have been granted these permission groups (including "Procurement Specialist Position," "Procurement Supervisor Position," etc.), and finally downstream to find all employees in these positions. Simultaneously, a hierarchical inheritance pattern is used to ensure that changes to this permission module are completely propagated along the chain of "Permission Module → Permission Group → Position → Employee." Through this traversal, the system collects all mutually exclusive rule relationship records containing the "Procurement Management Module" or any of its associated nodes—for example, in the "Separation of Procurement Application and Approval Responsibilities" rule, the "Purchase Order Approval" permission item is associated with this module through the "Procurement Management Permission Group"—forming a set of affected mutually exclusive rule relationships.

[0097] Through the above technical solution, the system starts from the changed permission subject and traverses only a local area of ​​the permission relationship graph to accurately identify the affected mutual exclusion rules, avoiding the computational overhead of a full scan. Using recursive and hierarchical inheritance patterns, even if the change only occurs at an intermediate level node—such as a modification to the permission group configuration of a position, a change in the permission template of a regional management team, or an adjustment to the entity permission allocation of a store—the system can still perform bidirectional deep mining along the inheritance chain, accurately locating all mutual exclusion rules indirectly affected by hierarchical transmission. This completely solves the limitation of traditional solutions that can only detect direct authorization conflicts.

[0098] As one implementation of this embodiment, step S4, traversing the permission relationship graph, specifically includes:

[0099] A breadth-first search algorithm is used to perform multi-level path traversal on each permission item in the left-end permission set and the right-end permission set according to the permission inheritance hierarchy from user group, permission group, entity permission to user, to obtain all directly granted users and indirectly granted users who hold each permission item through the inheritance hierarchy.

[0100] The breadth-first search algorithm described above is a graph traversal algorithm. Its core feature is "layer-by-layer diffusion"—starting from the starting node, it first visits all nodes in the current layer, then visits all nodes in the next layer, ensuring that all nodes in each layer are completely collected before moving to a deeper layer.

[0101] The above-mentioned permission inheritance hierarchy follows the hierarchical structure of ACCESS_MODULE (permission module) → ACCESS_GROUP (permission group) → USER_GROUP (position / department) → PERMISSION_ENTITY (entity permission) → USER (employee) for permission transfer.

[0102] The aforementioned direct granting to users refers to employees who directly obtain a certain permission item through the user-permission item direct authorization table, without going through any intermediate inheritance levels.

[0103] The aforementioned indirectly granted user refers to an employee who indirectly obtains a certain permission item through an inheritance chain such as "permission item → permission group → position → employee" or "permission item → entity permission → employee".

[0104] Taking the mutual exclusion rule of "separation of procurement application and approval responsibilities" of Pupu Supermarket as an example, the system performs multi-level path traversal from both the left and right ends.

[0105] Left-end traversal: Starting from the left-end permission item "Purchase Order Creation". First level: Search which permission groups contain this permission item; the "Purchase Specialist Permission Group" is found to contain it. Second level: Search which positions have been granted this permission group; the "Purchase Specialist" and "Purchase Supervisor" positions have been granted this permission group. Third level: Search which employees belong to these positions; Zhang San (P001) and Wang Wu (P005) in the Purchasing Department belong to the "Purchase Specialist" position, and Zhao Liu (P006) belongs to the "Purchase Supervisor" position. Simultaneously, the system also checks the user-permission item direct authorization table to see if any employees have been directly granted this permission item; Qian Qi (P007) has been directly granted the "Purchase Order Creation" permission (temporary authorization scenario).

[0106] After traversing the above multi-level paths, the set of users reachable on the left is {P001, P005, P006, P007}, where P001, P005, and P006 are indirectly granted users, and P007 is a directly granted user.

[0107] The above technical solution employs a breadth-first search algorithm and strictly follows the permission inheritance hierarchy for layer-by-layer diffusion traversal. This ensures that all employees at each level are fully collected before proceeding to the next level, guaranteeing the completeness and orderliness of the traversal at the algorithmic level. Through multi-level path traversal, it systematically exhaustively enumerates all directly granted users and indirectly granted users through multi-level nested inheritance of specific permission items, ensuring the data integrity and accuracy of the reachable user set. It fully covers various inheritance paths in the Pupu Supermarket permission system—job title inheritance, organizational structure inheritance, and entity permission inheritance—effectively avoiding conflicts and missed detections caused by incomplete traversal paths.

[0108] As one implementation of this embodiment, step S5, generating the structured early warning record, specifically includes:

[0109] The intersection of the left-end reachable user set and the right-end reachable user set is calculated layer by layer according to the permission inheritance hierarchy to determine the left-end conflict path and right-end conflict path corresponding to the conflicting user at each permission inheritance hierarchy.

[0110] The mutual exclusion rule identifier, conflicting user identifier, the left-end conflict path and the right-end conflict path of each permission inheritance level, the detection timestamp, and the application identifier corresponding to the change event are associated and stored to form the structured early warning record.

[0111] The aforementioned layer-by-layer intersection calculation refers to calculating the intersection of the left-end reachable user set and the right-end reachable user set at each permission inheritance level. For example, calculating the intersection at the USER_GROUP level can identify employees who appear on both the left and right ends at the job level.

[0112] The aforementioned left-end conflict path refers to the complete chain of authorization for conflicting employees holding left-end permissions. For example, purchase order creation → purchasing specialist permission group → purchasing specialist position → purchasing department → Zhang San. The aforementioned right-end conflict path refers to the complete chain of authorization for conflicting employees holding right-end permissions. For example, purchase order approval → approver permission group → purchasing approval position → Zhang San.

[0113] The aforementioned detection timestamp refers to the point in time when conflict detection was performed. The aforementioned application identifier is a unique identifier used to distinguish different business subsystems of Pupu Supermarket, such as "Procurement Management System," "Warehouse Management System," and "Store Operation System."

[0114] Following the previous example, the system has obtained the set of reachable users on the left end {P001, P005, P006, P007} and the set of reachable users on the right end {L001, P001, P008}. The system finds the intersection at the USER level and obtains {P001}, confirming that Zhang San is the conflicting employee.

[0115] The system further calculated the intersection at the USER_GROUP (position) level and found that Zhang San appeared in both the reachable user sets of the "Purchasing Specialist" and "Purchasing Approval" positions—indicating that the conflict stemmed from Zhang San being granted permissions for both positions simultaneously. The system then calculated the intersection at the ACCESS_MODULE level and found that Zhang San appeared in both the reachable user sets of the "Purchasing Management Module" and "Approval Management Module."

[0116] The system then determined the complete conflict path:

[0117] Conflict path on the left: Purchase order creation → Purchasing specialist permission group → Purchasing specialist position → Purchasing department → Zhang San;

[0118] Conflict path on the right: Purchase order approval → Approver authority group → Purchase approval post → Zhang San (granted through part-time appointment);

[0119] The system associates and stores the mutual exclusion rule identifier R001, the conflicting employee identifier P001, the conflict paths on the left and right ends mentioned above, the detection timestamp 2026-07-18 10:23:08, and the application identifier "Procurement Management System" as a structured early warning record.

[0120] Based on the above technical solution, by finding the intersection at each level of permission inheritance, the system can accurately pinpoint the specific link in the permission granting chain where the conflict occurs, rather than simply stopping at the final employee level. The structured warning record contains the complete conflict path from both the left and right ends, and, combined with the detection timestamp and application identifier, provides internal control auditors with a traceable and reproducible chain of evidence. By associating the stored application identifier, logical isolation of warning data is achieved between different business subsystems such as the procurement management system, warehouse management system, and store operation system.

[0121] As one implementation of this embodiment, the traversal process in step S4 further includes a step-adaptive optimization step:

[0122] Obtain the actual inheritance depth of the permission relationship graph, and dynamically set the upper limit of the traversal steps based on the actual inheritance depth;

[0123] When the first-level directly authorized users of the current traversal node have covered all users, terminate the multi-level recursive traversal of the current traversal path.

[0124] The actual inheritance depth mentioned above refers to the longest path length from the top-level permission module node to the bottom-level employee node in the permission relationship graph. In Pupu Supermarket, the procurement management module may have three layers (permission item → permission group → position → employee), and the warehouse management module may have six layers (permission item → permission group → regional permission group → region → department → position → store → employee).

[0125] The aforementioned upper limit on the number of traversal steps refers to the maximum number of edges that the breadth-first search algorithm is allowed to traverse in a single traversal. Traversal stops once this upper limit is reached. The aforementioned first-level directly authorized users refer to employees who directly hold the current permission item without any intermediate inheritance hierarchy (granted through the user-permission item direct authorization table). The aforementioned full user scenario refers to the entire set of users holding the current permission item. When the number of first-level directly authorized users equals the total number of users holding that permission item, it indicates that there are no indirect users who can only hold that permission item through multi-level inheritance.

[0126] The system first scans the topology of the permission relationship graph of Pupu Supermarket and calculates the longest path length from each permission module node to the employee node. The maximum inheritance depth of the procurement management module is four levels (permission item → permission group → position → department → employee), so the system sets the upper limit of the number of steps for traversing related modules to four.

[0127] During the traversal on the left, the system performs a breadth-first search starting from the permission item "Purchase Order Creation". The first step reaches the permission group "Purchase Specialist Permission Group", the second step reaches the position "Purchase Specialist Position", the third step reaches the department "Purchase Department", and the fourth step reaches employees Zhang San (P001) and Wang Wu (P005). The traversal stops at the fourth step, not exceeding the step limit.

[0128] Suppose that another permission item, "Store Checkout Permission," is only granted to a few employees through direct authorization. The system has already covered all users holding this permission item during the first-level direct authorization user traversal. The system determines that the current traversal path does not need to continue with multi-level recursive traversal, and directly terminates the further expansion of this traversal path, skipping all deeper-level traversal operations.

[0129] Through the above technical solution, the system dynamically calculates the upper limit of traversal steps based on the actual inheritance depth of the permission relationship graph, reducing the worst-case traversal time complexity from O(n^2) to O(n^2). 2 The time complexity is significantly reduced to O(n·k), where k is the upper limit of the number of steps, which is much smaller than the total number of nodes n. By determining whether a single-level authorized user covers the entire scenario, the system automatically skips multi-level deep recursive traversal, avoiding unnecessary deep searches in scenarios where multi-level inheritance is not required. Through the above adaptive optimization mechanism, the average response time of a single conflict detection can be controlled at the level of hundreds of milliseconds, fully meeting the performance requirements of Pupu Supermarket for real-time compliance monitoring.

[0130] As one implementation of this embodiment, after step S1, a local cache filtering step is further included:

[0131] Extract the application identifier corresponding to the change event, and query the local cache to see if there is a mutual exclusion rule enable flag corresponding to the application identifier;

[0132] If the enable flag is not present in the local cache or the enable flag indicates that the mutual exclusion rule is not enabled, the change event is filtered out and discarded, and subsequent steps are terminated.

[0133] The aforementioned application identifier is a unique identifier used to distinguish the different business subsystems of Pupu Supermarket. Pupu Supermarket's information system includes multiple business subsystems: procurement management system, warehouse management system, store operation system, delivery scheduling system, supplier management system, etc.

[0134] The aforementioned local cache refers to a high-speed data storage area deployed within the application process. In this embodiment, the Caffeine local cache library is used, which features fast access speed (microsecond level) and low memory overhead. Caffeine is a high-performance Java local cache library that supports time-based expiration policies and size-based eviction policies.

[0135] The aforementioned mutual exclusion rule enable flag is a Boolean flag used to indicate whether an application has configured and enabled at least one mutual exclusion rule.

[0136] TTL (Time To Live) is the lifespan of a cached entry. In this embodiment, it is set to 30 seconds. After this time, the cached entry will automatically expire, and the system will reload the latest enabled status from the database and update the cache.

[0137] The aforementioned filtering and discarding refers to directly discarding change events, preventing them from entering subsequent partition routing, queue consumption, and graph traversal calculation stages.

[0138] Pupu Supermarket's procurement management system and warehouse management system have implemented separation of duties and mutual exclusion compliance checks, but the store POS system and delivery scheduling system have not yet been configured with mutual exclusion rules.

[0139] When a permission change event occurs in the procurement management system, the system extracts the application identifier "procurement management system", queries the Caffeine local cache, and finds that the cache contains a mutual exclusion rule enabled flag with a value of "enabled". The event is then filtered and proceeds to the next processing stage.

[0140] When a permission change event occurs in the store POS system (such as a cashier job adjustment), the system extracts the application identifier "Store POS System", queries the Caffeine local cache, and if the cache does not contain the corresponding enable flag (or the enable flag indicates that it is not enabled), the system directly filters and discards the change event, terminating subsequent steps. This event does not consume Kafka queue resources or graph traversal computation resources.

[0141] The TTL of Caffeine cache is set to 30 seconds. When an administrator enables a new mutual exclusion rule in the procurement management system, the rule takes effect within 30 seconds. After 30 seconds, the cached entry automatically expires and is reloaded from the database, and the new rule takes effect.

[0142] Through the above technical solution, this local cache filtering mechanism acts as a highly efficient flow control valve, intercepting the vast majority of irrelevant change events in the system and significantly reducing the load on the core computing engine. Using Caffeine local caching instead of distributed caching for prediction avoids the overhead of initiating network requests for every change event, enabling filtering and judgment to be completed within microseconds and ensuring low latency across the entire event processing chain. The short TTL (30 seconds) design ensures data freshness while avoiding frequent database queries.

[0143] As one implementation of this embodiment, step S2, which involves performing partition routing based on the permission subject identifier of the change event, specifically includes:

[0144] Based on the permission relationship table type corresponding to the change event, extract the corresponding partition key from the change event. The partition key is a user group identifier, permission module identifier, or entity permission identifier.

[0145] Perform a hash operation on the partition key, and deliver the change event to the corresponding partition of the message queue based on the hash operation result;

[0146] In step S3, the consumer terminal calls the processor corresponding to the permission relationship table type corresponding to the change event, parses the change record, and extracts the permission subject identifier.

[0147] The partition key mentioned above is a key field used for hash routing. The system determines which field to use as the partition key based on the permission relationship table type corresponding to the change event—different types of tables have different business primary key or foreign key fields.

[0148] The hash operation described above is a mathematical operation that maps an input of arbitrary length to an output of fixed length. The system performs a hash operation on the partition key to obtain a hash value, and then takes the modulo of the total number of partitions in the message queue to obtain the target partition number.

[0149] The message queue partitions described above are the basic unit of message storage in Kafka. A single topic is divided into multiple partitions, each representing an ordered, immutable sequence of messages. Kafka guarantees that messages within the same partition are retrieved by the consumer in the order they were sent by the producer.

[0150] The aforementioned processors refer to change event handling components designed for specific permission relationship table types. The system implements independent processor classes for each of the seven types of permission relationship tables, and the internal logic of each processor is customized for the specific table's data structure.

[0151] The above-described parsing of change records refers to the process of extracting structured fields from change events. For insert operations, key fields are extracted from the new row; for update operations, the old and new rows are extracted and compared; and for delete operations, key fields are extracted from the old row.

[0152] When a change event occurs in the employee-position relationship table (e.g., Zhang San is transferred to the purchasing approval position), the system determines the partition key as the position identifier ROLE_BUY_APPROVE based on the table type. The system performs a hash operation on "ROLE_BUY_APPROVE" and delivers the event to Kafka's third partition. All permission change events for this position (including subsequent personnel transfers in and out) are delivered to the third partition and consumed sequentially within the same partition.

[0153] The consumer pulls events from Kafka's third partition and calls the corresponding employee-position relationship processor based on the table type "Employee-Position Relationship Table". This processor performs precise parsing of the unique data structure of the employee-position relationship table (including fields such as employee ID, position identifier, effective date, and expiration date) to extract the permission subject identifier as the position identifier ROLE_BUY_APPROVE.

[0154] Suppose another change event occurs in the permission group-permission item relationship table (modifying a permission item contained in a permission group). The system determines the partition key as the permission module identifier based on the table type and delivers the event to another partition in Kafka. The consumer calls the permission group-permission item relationship processor based on the table type. This processor parses the unique data structure of the permission group-permission item relationship table (fields such as permission group identifier, permission item identifier, and permission module identifier) ​​and extracts the permission subject identifier as the permission module identifier.

[0155] Based on the above technical solution, by hashing the partition key, events with the same partition key are delivered to a fixed Kafka partition. This ensures that all change events for the same permission subject are processed strictly in chronological order on the consumer side, fundamentally avoiding data inconsistency issues caused by concurrent computation. The consumer side calls the corresponding processor based on different permission relationship table types, enabling precise parsing of change records and extraction of permission subject identifiers based on the unique data structure and field semantics of each table, ensuring the accuracy and flexibility of the data transformation process.

[0156] As one implementation of this embodiment, an incremental compensation recalculation step is also included:

[0157] By using a scheduled task, historical change event records generated within the current time window are retrieved at preset time intervals, and steps S3 to S5 are re-executed to compensate for undetected conflict events caused by message consumption delays.

[0158] The aforementioned scheduled tasks refer to tasks that are automatically triggered at fixed time intervals. In this embodiment, scheduled tasks are configured using the XXL-JOB distributed task scheduling platform. XXL-JOB is an open-source distributed task scheduling framework that supports scheduled task triggering, distributed execution, and execution status monitoring.

[0159] The aforementioned preset time period refers to the trigger interval of the scheduled task. In this embodiment, it is set to 5 minutes. The aforementioned time window refers to the time period from the end time of the previous compensation task to the start time of the current compensation task.

[0160] The aforementioned historical change event records refer to change event records that have been consumed by the message queue and persistently stored, and have the same data format and content as the change events captured in real time in step S1.

[0161] The aforementioned compensation detection refers to re-executing the complete conflict detection process (steps S3 to S5) on historical change events to discover conflicts that were not detected during the real-time processing phase.

[0162] During promotional events at Pupu Supermarket, the frequency of permission changes may increase dramatically—a large number of temporary employee onboarding, job adjustments, and temporary permission grants may occur simultaneously. This could lead to significant backlog risks in the Kafka message queue.

[0163] Suppose that the event of Zhang San being transferred to the procurement approval position at 10:23 AM on May 18, 2026, was not processed in time due to message backlog. At 10:25 AM that day, the XXL-JOB scheduled task was triggered. The system determined the current time window to be from 10:20 AM to 10:25 AM, and within this window, it queried historical change event records and found the change event of Zhang San being transferred to the procurement approval position. The system re-executed steps S3 to S5 for this event—traversing from "procurement approval position" to determine that R001 is affected, using a double-ended BFS traversal to obtain the sets of reachable users on both sides, finding the intersection to determine the conflict—detecting the conflict for Zhang San and generating an alert record. Deduplication checks found that the alert did not exist (it was not generated during the real-time processing stage), and it was inserted into the alert database. The above deduplication means that the system performs a duplicate check when inserting the alert record. If an alert record with the same mutual exclusion rule identifier, the same conflicting employee identifier, and the detection timestamp is within the current compensation window range already exists in the database, it will not be inserted again.

[0164] Assuming the real-time processing link has returned to normal, the event has been processed normally and an early warning record has been generated during the real-time phase. When the compensation task processes the event again, the deduplication check finds that an early warning record with the same rule identifier R001, the same conflicting employee P001, and a detection timestamp between 10:20 and 10:25 already exists in the database. Therefore, it will not be inserted again.

[0165] Through the above technical solution, even if message backlog, consumption failure, or brief downtime occurs in the real-time link, the compensation task can automatically repair the missed conflicting data within the subsequent 5-minute cycle. This mechanism ensures that all permission changes generated the previous day have been detected before the start of business the next day, eliminating compliance detection blind spots caused by real-time link anomalies. Deduplication checks prevent duplicate alerts, ensuring the accuracy and cleanliness of alert data.

[0166] See Figure 2 This embodiment also provides a mutual exclusion rule conflict detection system oriented towards a permission system, including:

[0167] Event capture module 10 is used to capture change events of the permission relationship table in real time through the database change log component. Specifically, event capture module 10 is the system's front-end entry point, responsible for establishing a connection with the database and continuously monitoring changes. This module deploys the Canal component, which continuously monitors data manipulation language operations of the seven types of permission relationship tables, encapsulates the captured change events into a standard format, and outputs them to subsequent modules.

[0168] The routing distribution module 20 is used to perform partitioned routing based on the permission subject identifier of the change event and deliver the change event to the corresponding task queue. Specifically, the routing distribution module 20 is responsible for performing partitioned routing based on the permission subject identifier of the change event and delivering the change event to the corresponding task queue. This module includes hash routing logic and local cache filtering logic.

[0169] The event handling module 30 is used to consume the change events in the task queue. Starting from the changed permission subject, it traverses the permission relationship graph to determine the set of mutual exclusion rules affected by the change event. Specifically, the event handling module 30 is responsible for consuming the change events in the task queue and includes independent processors for seven types of permission relationship tables. Each processor is called according to the table type, parses the change record and extracts the permission subject identifier, and performs the initial traversal of the permission relationship graph to determine the set of affected mutual exclusion rules.

[0170] The graph traversal calculation module 40 is used to traverse the permission relationship graph for each mutually exclusive rule in the set of mutually exclusive rules, starting from the left-hand permission set and the right-hand permission set of the mutually exclusive rule, to obtain the left-hand reachable user set and the right-hand reachable user set. Specifically, the graph traversal calculation module 40 is the core calculation engine of the system. It is responsible for performing multi-level path traversal according to the permission inheritance hierarchy using a breadth-first search algorithm for each mutually exclusive rule, starting from the left-hand permission set and the right-hand permission set, to obtain the left-hand reachable user set and the right-hand reachable user set. This module integrates a step-adaptive optimization unit.

[0171] The conflict determination and early warning module 50 is used to find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it determines that there are conflicting users and generates a structured early warning record. Specifically, the conflict determination and early warning module 50 is responsible for finding the intersection of the left-end reachable user set and the right-end reachable user set, performing the intersection calculation layer by layer according to the permission inheritance level, determining the conflict path of the conflicting user at each permission inheritance level, and storing the mutual exclusion rule identifier, conflicting user identifier, conflict path, detection timestamp, and application identifier as a structured early warning record.

[0172] The modules are connected sequentially to form a complete data pipeline, and the modules communicate with each other through message queues or remote procedure calls.

[0173] Take Zhang San's transfer to the procurement approval position as an example:

[0174] The event capture module (Canal) listens for insertion events in the employee-job relationship table, captures the change records, encapsulates them into a standard event format, and outputs them to the routing and distribution module.

[0175] The routing and distribution module extracts the application identifier "Procurement Management System" from the event, queries the Caffeine local cache to confirm that the application has enabled mutual exclusion rules, determines that the partition key is the job identifier ROLE_BUY_APPROVE and performs a hash operation, and delivers the event to the 3rd partition of Kafka.

[0176] The event handling module pulls events from partition 3, calls the corresponding handler based on the table type "Employee-Job Relationship Table", parses the change records, and extracts the permission subject identifier as ROLE_BUY_APPROVE. Then, it traverses the permission relationship graph with ROLE_BUY_APPROVE as the starting node to determine the affected mutual exclusion rule R001.

[0177] The graph traversal calculation module performs a breadth-first search traversal for R001, starting from the left-end permission set and the right-end permission set respectively. Under the step-adaptive optimization mechanism, it obtains the left-end reachable user set {P001, P005} and the right-end reachable user set {L001, P001}.

[0178] The conflict determination and early warning module finds the intersection of the two sets to obtain {P001}, determines the conflict path layer by layer according to the permission inheritance hierarchy, generates structured early warning records, and persists them to the early warning database.

[0179] The above modules can be deployed on the same server or distributed across multiple servers according to the actual load, supporting horizontal scaling to adapt to the needs of Pupu Supermarket at different stages of its development.

[0180] Through the above technical solutions, a highly cohesive and loosely coupled access control compliance detection system was constructed. The functional boundaries of each module are clearly defined, and the logical chain is completely closed. The system as a whole inherits the technical effects of all the aforementioned method claims—real-time performance, accuracy, high performance, auditability, and multi-tenant support. Each module supports horizontal scaling, adapting to the different development stages and scale needs of Pupu Supermarket, and possesses good maintainability and scalability, facilitating modular deployment and integration within the existing enterprise access control platform architecture.

[0181] Although the above embodiments have been described, those skilled in the art, once they understand the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the above descriptions are merely embodiments of the present invention and do not limit the scope of patent protection of the present invention. Any equivalent structural or procedural transformations made using the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for detecting mutual exclusion rule conflicts in a permission-based system, characterized in that, Includes the following steps: Step S1: Capture change events of the permission relationship table in real time using the database change log component; Step S2: Perform partition routing based on the permission subject identifier of the change event, and deliver the change event to the corresponding task queue; Step S3: Consume the change events in the task queue, starting from the subject of the change, traverse the permission relationship graph to determine the set of mutual exclusion rule relationships affected by the change events; Step S4: For each mutual exclusion rule in the set of mutual exclusion rules, starting from the left-end permission set and the right-end permission set of the mutual exclusion rule, traverse the permission relationship graph to obtain the left-end reachable user set and the right-end reachable user set. Step S5: Find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it is determined that there are conflicting users, and a structured warning record is generated.

2. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, The permission relationship tables include user-user group relationship tables, user group-permission group relationship tables, permission group-permission item relationship tables, entity permission-user relationship tables, user-permission item direct authorization tables, mutual exclusion rule tables, and mutual exclusion rule relationship tables.

3. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, In step S3, the step of starting from the changed permission subject, traversing the permission relationship graph, and determining the set of mutually exclusive rule relationships affected by the change event specifically includes: Based on the permission relationship table type corresponding to the change event, extract the corresponding permission subject identifier; Starting with the permission subject identifier as the starting node, and following the associated edges in the permission relationship graph, the recursive inheritance mode and the superior inheritance mode are used to traverse the superior and inferior nodes that have an inheritance relationship with the starting node, and obtain all mutually exclusive rule relationship records containing the starting node or any of the superior and inferior nodes, thus forming the mutually exclusive rule relationship set.

4. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, In step S4, traversing the permission relationship graph specifically includes: A breadth-first search algorithm is used to perform multi-level path traversal on each permission item in the left-end permission set and the right-end permission set according to the permission inheritance hierarchy from user group, permission group, entity permission to user, to obtain all directly granted users and indirectly granted users who hold each permission item through the inheritance hierarchy.

5. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, In step S5, generating the structured early warning record specifically includes: The intersection of the left-end reachable user set and the right-end reachable user set is calculated layer by layer according to the permission inheritance hierarchy to determine the left-end conflict path and right-end conflict path corresponding to the conflicting user at each permission inheritance hierarchy. The mutual exclusion rule identifier, conflicting user identifier, the left-end conflict path and the right-end conflict path of each permission inheritance level, the detection timestamp, and the application identifier corresponding to the change event are associated and stored to form the structured early warning record.

6. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, The traversal process in step S4 also includes a step-adaptive optimization step: Obtain the actual inheritance depth of the permission relationship graph, and dynamically set the upper limit of the traversal steps based on the actual inheritance depth; When the first-level directly authorized users of the current traversal node have covered all users, terminate the multi-level recursive traversal of the current traversal path.

7. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, Following step S1, a local cache filtering step is also included: Extract the application identifier corresponding to the change event, and query the local cache to see if there is a mutual exclusion rule enable flag corresponding to the application identifier; If the enable flag is not present in the local cache or the enable flag indicates that the mutual exclusion rule is not enabled, the change event is filtered out and discarded, and subsequent steps are terminated.

8. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, In step S2, the step of performing partition routing based on the permission subject identifier of the change event specifically includes: Based on the permission relationship table type corresponding to the change event, extract the corresponding partition key from the change event. The partition key is a user group identifier, permission module identifier, or entity permission identifier. Perform a hash operation on the partition key, and deliver the change event to the corresponding partition of the message queue based on the hash operation result; In step S3, the consumer terminal calls the processor corresponding to the permission relationship table type corresponding to the change event, parses the change record, and extracts the permission subject identifier.

9. The method for detecting mutual exclusion rule conflicts in a permission-based system according to claim 1, characterized in that, It also includes the incremental compensation recalculation step: By using a scheduled task, historical change event records generated within the current time window are retrieved at preset time intervals, and steps S3 to S5 are re-executed to compensate for undetected conflict events caused by message consumption delays.

10. A mutual exclusion rule conflict detection system oriented towards a permission system, characterized in that, include: The event capture module is used to capture change events of the permission relationship table in real time through the database change log component; The routing and distribution module is used to perform partition routing based on the permission subject identifier of the change event and deliver the change event to the corresponding task queue; The event handling module is used to consume the change events in the task queue, starting from the changed permission subject, traversing the permission relationship graph to determine the set of mutual exclusion rule relationships affected by the change events; The graph traversal calculation module is used to traverse the permission relationship graph for each mutual exclusion rule in the mutual exclusion rule relationship set, starting from the left permission set and the right permission set of the mutual exclusion rule respectively, to obtain the left reachable user set and the right reachable user set. The conflict determination and early warning module is used to find the intersection of the left-end reachable user set and the right-end reachable user set. If the intersection is not empty, it is determined that there are conflicting users and a structured early warning record is generated.

Images