An adaptive loading method and system for access control rules

Abstract

This invention discloses an adaptive loading method and system for access control rules, relating to the field of data access control technology. The method includes maintaining a runtime profile database, using a combination of resource identifier and data level as the index key, recording access popularity, conflict summary, and temporal correlation features, and constructing an inverted index; dividing index items into hot, warm, and cold zones according to a comprehensive popularity score; upon initial access, selecting an index item, reading a candidate rule set, and storing it in the index-level cache; resolving conflicts and generating a deterministic rule subset, which is then stored in the request-level cache; new requests prioritize checking the request-level cache, and if a match is found, obtaining the rule subset; if no match is found, checking the index-level cache, filtering and resolving the match; if neither match is found, re-querying; updating the conflict summary when rules change; and preloading subsequent candidate rule sets into the index-level cache after the request is completed.

Description

Technical Field

[0001] This application relates to the field of data access control technology, and in particular to an adaptive loading method and system for access control rules. Background Technology

[0002] Attribute-Based Access Control (ABAC) has gradually become the mainstream authorization solution for enterprise-level digital asset management platforms because it can achieve fine-grained authorization through flexible combinations of user attributes, resource attributes, environment attributes, and operation types.

[0003] In a typical ABAC implementation, the administrator configures access control rules in the policy library. Each rule includes fields such as resource identifier, data level, operation type, subject condition set, additional environmental conditions, and decision result. When a user initiates an access request, the system loads the rule from the policy library and performs attribute matching evaluation. Based on the decision result of the matched rule, it returns either allow or deny.

[0004] As enterprises deepen their digital transformation, the number of access control rules has expanded from dozens in the early days to thousands or even tens of thousands, making the performance issues of rule loading and matching increasingly prominent.

[0005] To address this, several technologies have been explored in this field: decision tree algorithms are used to organize rules into a tree structure to reduce matching depth; multi-dimensional composite indexes are introduced to narrow the matching range by taking the intersection of candidate sets of each dimension during querying; inverted indexes have also been introduced into the field of access control, using user identifiers or user group identifiers as index terms to organize permission data; in terms of caching, historical evaluation results are cached according to the request dimension to avoid duplicate calculations; in terms of rule conflict handling, existing technologies mostly adopt offline full-scale conflict detection, statically scanning the rule base before rule deployment and allowing administrators to make manual decisions.

[0006] However, once existing index structures (whether decision trees, composite indexes, or inverted indexes) are built, their index dimensions, key-value combinations, and storage levels are relatively fixed, making them unable to respond to dynamic changes in access behavior. The access frequencies of different resource and data level combinations vary greatly, and hot resources will drift over time and as business focus shifts. Fixed index paths may not be optimal for hot resources, causing high-frequency requests to continuously suffer from suboptimal matching efficiency, while index data for low-frequency resources continues to occupy high-speed storage resources, resulting in waste.

[0007] Furthermore, enterprises face a dilemma in actual engineering: if the rules are made more detailed to ensure accuracy, the number of rules will inevitably increase, eventually leading to continuous performance degradation; if the granularity of the rules is controlled in order to maintain performance, the management precision of fine-grained authorization will be sacrificed.

[0008] Therefore, there is an urgent need for an access control rule loading scheme that can integrate rule storage management, index maintenance, rule loading, conflict handling, and cache scheduling into an adaptive closed-loop system. Summary of the Invention

[0009] The purpose of this invention is to provide an adaptive loading method and system for access control rules to solve the above-mentioned technical problems existing in the prior art.

[0010] The technical solution adopted in this invention is as follows: This invention provides an adaptive loading method for access control rules, comprising: Maintain a runtime profile library, which uses a combination of resource identifier and data level as the index key. For each index key, record access popularity characteristics, conflict summary characteristics, and time-series correlation characteristics. Construct an inverted index that executes the index based on the index key. Each index item in the inverted index corresponds to an index key and its associated list of rule identifiers. Based on the comprehensive popularity score in the access popularity feature, each index item in the inverted index is dynamically allocated to one of the storage levels in the hot zone, warm zone, and cold zone, and the upgrade or downgrade judgment of the storage level is triggered when the comprehensive popularity score of each index item changes. For the initial access request, the resource identifier, data level, operation type and subject attribute in the access request are parsed. An index key is generated based on the resource identifier and data level. The runtime profile library is queried. Based on the index key, the corresponding rule identifier list is read to obtain the candidate rule set, which is then stored in the index-level cache that executes the index with the index key. The candidate rule set is filtered by operation type and subject attribute to obtain a minimum necessary rule subset. The conflict summary feature of the index key corresponding to the minimum necessary rule subset is queried. After conflict resolution, a deterministic rule subset is generated and stored in the request-level cache with the second index key. The second index key is a combination of resource identifier, data level, operation type and subject attribute. Upon receiving a new access request, the resource identifier, data level, operation type, and subject attribute in the access request are parsed to obtain a second index key and an index key. The second index key is used to index the request-level cache. If the request-level cache is hit, a subset of the cache's deterministic rules is returned directly. If the request-level cache misses, the index-level cache is indexed using the index key. If the index-level cache hits, a candidate rule set is obtained, filtering and conflict resolution are performed, a deterministic rule subset is generated, and stored in the request-level cache indexed using the second index key. If neither the request-level cache nor the index-level cache is hit, then the step of querying the index of the runtime profile library is executed.

[0011] Through the above technical solution, the runtime profile library serves as a unified decision-making center, converging three types of features—access popularity, conflict summaries, and temporal correlation—into the same data structure. The elastic inverted index dynamically adjusts the storage level of each index item based on the popularity score and selects the index item with the lowest expected retrieval cost as the retrieval entry point through a cost evaluation model. The initial request goes through the complete indexing process and writes the candidate rule set into the index-level cache and the subset of deterministic rules into the request-level cache. Subsequent requests prioritize hitting the request-level cache to directly obtain the subset of deterministic rules, and secondly hit the index-level cache to skip the index location step, ensuring that high-frequency requests always execute along the optimal path, and the overall performance continuously and adaptively optimizes with the dynamic changes in access patterns.

[0012] The present invention also provides an access control rule adaptive loading system, comprising: a profile library maintenance module for maintaining a runtime profile library, wherein the runtime profile library uses a combination of resource identifier and data level as the index key, records access popularity characteristics, conflict summary characteristics and temporal correlation characteristics for each index key, and constructs an inverted index with the index key as the execution index, wherein each index item in the inverted index corresponds to an index key and its associated rule identifier list; The elastic inverted index module is used to dynamically allocate each index item in the inverted index to a storage level among the hot zone, warm zone, and cold zone based on the comprehensive popularity score in the access popularity feature, and to trigger the upgrade or downgrade judgment of the storage level when the comprehensive popularity score of each index item changes; and to read the corresponding rule identifier list according to the index key to obtain the candidate rule set. A multi-level caching module includes an index-level cache that performs indexing based on an index key and a request-level cache that performs indexing based on a second index key; the second index key is a combination of resource identifier, data level, operation type, and subject attribute; the index-level cache is used to store a set of candidate rules, and the request-level cache is used to store a subset of deterministic rules; The rule filtering module is used to filter the candidate rule set according to the operation type and the subject attribute to obtain the minimum necessary rule subset; the conflict detection and resolution module is used to query the conflict summary features of the index key corresponding to the minimum necessary rule subset, and generate a deterministic rule subset after performing conflict resolution. The request scheduling module receives access requests, parses the resource identifier, data level, operation type, and subject attribute to obtain the second index key and the index key. It prioritizes indexing the request-level cache with the second index key. If a match is found, it directly returns a subset of deterministic rules from the cache. If no match is found, it indexes the index-level cache with the index key. If a match is found, it obtains a set of candidate rules and passes them to the rule filtering module and conflict detection and resolution module for processing. If no match is found at either level, it calls the elastic inverted index module to execute the index query process.

[0013] Furthermore, the calculation method for the comprehensive popularity score is as follows: The sliding time window counting method is used to sum the access frequencies within each time window according to an exponential decay weight, and the weighted sum is normalized to a preset interval to obtain the comprehensive popularity score. The closer the time window is to the current moment, the higher its weight.

[0014] Using exponentially decaying weights allows recent access behavior to have a greater impact on popularity scores, enabling popularity scores to reflect the shifts in access hotspots in a timely manner and drive the dynamic upgrading and downgrading of index item storage levels.

[0015] Preferably, the running portrait library maintains a storage hierarchy state for each index key; When the overall popularity score of an index item exceeds the heat-up threshold and the current storage level is not a hot zone, the index item is upgraded to a hot zone, and its rule identifier list is converted into a bitmap compressed format and loaded into memory. When the overall popularity score of an index item is lower than the cooling threshold and the current storage level is not a cold zone, the index item is triggered to be downgraded to a cold zone, its data is serialized and written to disk and memory is released.

[0016] Specifically, the generation of the expected retrieval cost is achieved through a cost evaluation model. The expected retrieval cost calculated by the cost evaluation model for each index item in the inverted index consists of four components: the estimated number of candidate rules, the popularity weighting coefficient, the conflict penalty term, and the index switching overhead. The estimated number of candidate rules is the total number of rules in the rule identifier list associated with the index key. The more candidate rules there are, the higher the expected retrieval cost. The popularity weighting coefficient is calculated based on the comprehensive popularity score of the index key. The higher the comprehensive popularity score, the lower the popularity weighting coefficient, so as to reduce the expected retrieval cost. The conflict penalty term is determined based on the number of rule pairs marked as hard conflicts in the conflict summary feature of the index key. The more hard conflict rule pairs there are, the higher the expected retrieval cost will be. The index switching overhead is a fixed constant value included when selecting an index item that is not currently in use.

[0017] Furthermore, it also includes: after the initial access request is processed, querying the temporal correlation features corresponding to the current index key in the running profile library, obtaining a list of subsequent index keys with a conditional probability not lower than the preloading threshold, and taking the first few as preloading targets in descending order of conditional probability. For each preloaded target, the corresponding rule identifier list is read from the inverted index, and the rule identifier list is written as a candidate rule set into the index-level cache that executes the index with the subsequent index key.

[0018] In some embodiments, the preload accuracy is periodically calculated, and the statistical results are backfilled into the runtime profile library; When the preload accuracy is lower than a first accuracy threshold, the preload threshold is increased; when the preload accuracy is higher than a second accuracy threshold, the preload threshold is decreased; wherein the first accuracy threshold is lower than the second accuracy threshold.

[0019] Furthermore, it also includes: when access control rules are added, modified, or deleted, performing the following operations: updating the inverted index; Incremental conflict detection is performed on newly added rules, modified rules and all existing rules under the same index key. It is determined whether there is an intersection between the main condition scope of two rules. If there is an intersection, the operation type and decision result are further compared. The conflict relationship between the two rules is divided into hard conflict and soft conflict. The detection result is written into the conflict summary feature of the running state profile library. For deletion rules, all conflicting relationships associated with the deletion rule are removed from the conflict summary feature.

[0020] Incremental conflict detection is embedded in the index maintenance process, so that conflict status is detected and recorded when rules change, and subsequent rule loading can directly use conflict digests to resolve conflicts.

[0021] Specifically, the incremental conflict detection distinguishes the conflict relationship between two rules into hard conflict and soft conflict: when the main condition scopes of two rules overlap, and the operation types are the same or there is an inclusion relationship, and the decision results are opposite, it is determined to be a hard conflict, and the conflict resolution strategy of time priority or rejection priority is executed. When the scope of the main conditions of two rules overlaps, and the operation types overlap but are not completely inclusive, and the decision results are opposite, it is judged as a soft conflict and processed according to the priority order of the rules.

[0022] Due to the adoption of the above technical solution, the beneficial effects achieved by this invention are as follows: 1. By maintaining a runtime profile database, using a combination of resource identifier and data level as the index key, each index key records access frequency characteristics, conflict summary characteristics, and temporal correlation characteristics. An inverted index is then constructed based on this index key. Furthermore, based on the comprehensive popularity score from the access frequency characteristics, each index entry in the inverted index is dynamically allocated to one of the storage levels (hot, medium, or cold). Upgrading or downgrading the storage level is triggered when the comprehensive popularity score changes. Thus, index entries for popular resources are automatically upgraded to the memory hot zone for faster retrieval, while index entries for infrequently accessed resources are automatically downgraded to release memory resources. This ensures that high-frequency requests always execute along the optimal path, avoiding resource waste and performance degradation caused by mixed storage of hot and cold resources under a fixed index structure.

[0023] 2. During the initial access request processing, the candidate rule set read from the retrieval entry point is stored in the index-level cache that performs indexing with the index key. The minimum necessary rule subset obtained by filtering the candidate rule set by operation type and subject attribute is then used to query the conflict summary features of the corresponding index key and perform conflict resolution to generate a deterministic rule subset, which is then stored in the request-level cache that performs indexing with the second index key. The second index key is a combination of resource identifier, data level, operation type, and subject attribute.

[0024] This results in a two-level caching structure: the index-level cache uses the index key as the granularity of the candidate rules set, and the request-level cache uses the request dimension combination as the granularity of the deterministic rules subset after conflict resolution.

[0025] When a new access request is received, the request-level cache is first indexed using the second index key. If a match is found, the deterministic subset of rules in the cache is returned directly, completely skipping the entire process of index retrieval, filtering, and conflict resolution. If the request-level cache misses, the index-level cache is indexed using the index key. If a match is found, a candidate rule set is obtained. Only filtering and conflict resolution are needed to generate the deterministic subset of rules, skipping the index location step. This two-level caching structure forms a hierarchical acceleration system in the request processing path. The earlier the request is hit, the greater the benefit. At the same time, by prioritizing conflict resolution, the rule subset in the cache has direct availability, effectively avoiding the problem of duplicate calculations caused by residual invalid or unresolved rules in the cache.

[0026] 3. By using a runtime profile library to uniformly record access frequency characteristics, conflict summary characteristics, and temporal correlation characteristics for each index key, the system can dynamically respond to the shift in access hotspots by utilizing changes in these frequency characteristics during storage level upgrade / downgrade decisions. As a result, the system's rule loading efficiency can adaptively optimize as the rule set evolves, maintaining stable authentication performance even with continuously growing rule sizes, without manual intervention.

[0027] The adaptive loading mechanism constructed in this application, through dynamic allocation of storage levels driven by the runtime portrait library and the coordinated cooperation of two-level caches, enables the system to automatically guide high-frequency requests to the optimal cache level even when the number of rules continues to grow. This maintains the integrity of fine-grained authorization rules while ensuring efficient and stable rule loading performance, allowing the system to adaptively respond to dynamic changes in the rule set. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart illustrating the adaptive loading method for access control rules according to one embodiment of the present invention. Detailed Implementation

[0029] To more clearly illustrate the overall concept of the present invention, a detailed description will be provided below with reference to the accompanying drawings and examples.

[0030] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0031] like Figure 1 As shown, an adaptive loading method for access control rules includes: S1: Maintain a runtime profile library. The runtime profile library uses a combination of resource identifier and data level as the index key. For each index key, it records access popularity characteristics, conflict summary characteristics, and time-series correlation characteristics. It also constructs an inverted index that executes the index based on the index key. Each index item in the inverted index corresponds to an index key and its associated list of rule identifiers.

[0032] The purpose of S1 is to establish a unified state record structure with a combination of resource identifier and data level as the index key, so that subsequent index layering, retrieval entry selection, conflict resolution and cache management can all be based on the same data source, solving the problem of independent and scattered information in rule storage management, rule loading and rule conflict handling.

[0033] Each profile record in the runtime profile database corresponds to a unique index key, which is composed of the resource identifier (Resource) and the data level (Level). Each profile record includes the following three types of feature data.

[0034] Popularity features include cumulative access count (AccessCount), last access time (LastAccessTime), access count sequence within the sliding window (SlidingWindowCounts), and overall popularity score (HotScore).

[0035] The conflict summary features include an N-by-N conflict bitmap, where N is the total number of rules under the index key, bit[i][j] equal to 1 indicates that there is a conflict between rule i and rule j, and the conflict severity level of each rule, ConflictSeverity, with a value of 0 indicating no conflict, a value of 1 indicating a soft conflict, and a value of 2 indicating a hard conflict.

[0036] The temporal correlation features include the co-occurrence probability CoOccurrenceMatrix of the index key and other index keys, i.e., the conditional probability P(Key_j|Key_i).

[0037] The profile record also includes the version number (Version), storage tier (StorageTier), and last upgrade / downgrade time (LastUpgradeTime), without any restrictions.

[0038] In practical implementation, the conflict bitmap can be constructed using an SMT satisfiability modulo theorem solver. The principal condition of each rule is transformed into an SMT constraint expression, and the satisfiability of the constraint expressions corresponding to two rules is checked. For example, the principal condition that the department equals sales group one and the job level is greater than or equal to P4 is transformed into an SMT constraint expression for satisfiability checking.

[0039] The inverted index system contains an index key, which is a combination of resource identifier and data level, corresponding one-to-one with the ProfileRecord in the profile database, and is the default core entry point. All index entries maintain a version number, which increments automatically each time the rule list changes.

[0040] By unifying popularity features, conflict summary features, and time-series correlation features into a profile record with index key granularity, subsequent index layering, retrieval entry selection, conflict resolution, and cache management can all be based on the same data source, avoiding information inconsistency and decision lag caused by independent operation of each module.

[0041] S2: Based on the comprehensive popularity score in the access popularity feature, dynamically allocate each index item in the inverted index to one of the storage levels in the hot zone, warm zone, and cold zone, and trigger the upgrade / downgrade judgment of the storage level when the comprehensive popularity score of each index item changes.

[0042] The purpose of S2 is to dynamically allocate each index item in the inverted index to different storage levels based on the comprehensive popularity score in the access popularity characteristics. This allows frequently accessed index items to obtain faster memory access speeds, while infrequently accessed index items release scarce memory resources, thus solving the problem that fixed index structures cannot respond to access hotspot shifts.

[0043] The HotScore, the overall popularity score, is calculated using a sliding time window counting method. Storage levels are divided according to the HotScore value. Hot zones store index entries with a HotScore greater than or equal to 0.7. The rule identifier list for each hot zone index entry resides entirely in memory and is stored using bitmap compression encoding. This means the rule identifier list is encoded as a fixed-length bitmap, with each rule's global sequence number in the rule base corresponding to a single bit in the bitmap.

[0044] The advantage of bitmap storage is that the memory usage of a single rule is compressed from 8 bytes to 1 bit, with a compression ratio of 64 times, and the intersection, union, and complement operations of the set can be completed in constant time through bit operations.

[0045] The temperature zone stores index entries with a HotScore greater than or equal to 0.2 and less than 0.7. The metadata of the temperature zone index entries resides in memory, and the rule identifier list is stored on disk in a compressed format and is asynchronously loaded into the memory cache when accessed.

[0046] Cold storage contains index entries with a HotScore less than 0.2. The complete data of cold storage index entries is stored on disk, while only the key and rule count statistics are retained in memory.

[0047] By using dynamic storage hierarchy allocation based on comprehensive popularity scores, index entries for popular resources can be automatically upgraded to memory hot zones to achieve faster retrieval speeds, while index entries for unpopular resources are automatically downgraded to release memory resources. This ensures that high-frequency requests always execute along the optimal path, avoiding resource waste and performance degradation caused by mixed storage of hot and cold resources under a fixed index structure.

[0048] S3: For the initial access request, parse the resource identifier, data level, operation type and subject attribute in the access request, generate an index key based on the resource identifier and data level, query the runtime profile library, read the corresponding rule identifier list based on the index key, obtain the candidate rule set, and store it in the index-level cache that executes the index with the index key.

[0049] The purpose of S3 is to, for the first access request, use the combination of resource identifier and data level as the index key, read the corresponding rule identifier list from the inverted index to obtain the candidate rule set, and store it in the index-level cache that executes the index with the index key, so as to provide a data foundation for subsequent filtering and conflict resolution, and at the same time enable subsequent requests with the same index key to directly obtain the candidate rule set from the index-level cache, skipping the index location step.

[0050] The system parses the resource identifier, data level, and operation type from the user access request, and obtains the subject attributes, including department, job level, and validity period. An index key is generated based on the resource identifier and data level. The system queries the runtime profile database for the profile record corresponding to this index key, reads the rule identifier list associated with this index key, and obtains a candidate rule set. This candidate rule set is stored in the index-level cache where indexes are executed using the index key.

[0051] In the inverted index, the index key is a combination of resource identifier and data level, which corresponds one-to-one with the index items in the profile database.

[0052] It's important to note that the core objective of access control is resource protection. Using resource attribute entries as index keys, a list is created where rules define permissions for the same resource attribute. This rapidly reduces the actual number of rules to be evaluated without requiring an exact match.

[0053] Resources with different data levels typically have different management granularities in access control rules. Combining resource identifiers with data levels as index keys allows the rule base to be divided into several index items, facilitating the unified maintenance of popularity features, conflict summary features, and time-series correlation features.

[0054] The value space for operation types is relatively small, typically including only a limited number of values ​​such as read, write, and delete. If the operation type is used as the index key, a single operation type will be associated with rules from a large number of resources, resulting in an excessively long rule list for the index item, which cannot effectively reduce the size of the candidate rule set.

[0055] Furthermore, subject attributes involve combinations of multiple dimensions such as department, job level, and validity period, resulting in a much wider value range than the combination of resource identifier and data level. The number of possible subject attribute combinations also dynamically increases with changes in the company's organizational structure, making them unsuitable as stable index primary keys. Therefore, operation type and subject attributes are more suitable as filtering criteria in the subsequent filtering stage. That is, after obtaining the candidate rule set through indexing, filtering is performed step-by-step based on operation type and subject attributes.

[0056] By using a combination of resource identifier and data level as the index key for indexing and location, the system can quickly narrow down the rule retrieval scope after the access request is parsed, obtaining a set of candidate rules directly related to the accessed object. This set of candidate rules is stored in an index-level cache, allowing subsequent requests with the same index key to directly retrieve the candidate rule set, skipping the indexing and location step. The index key corresponds one-to-one with the image database index item, facilitating indexing and location.

[0057] S4: Filter the candidate rule set according to operation type and subject attribute to obtain the minimum necessary rule subset, query the conflict summary feature of the index key corresponding to the minimum necessary rule subset, perform conflict resolution to generate a deterministic rule subset, and store it in the request-level cache with the second index key; the second index key is a combination of resource identifier, data level, operation type and subject attribute.

[0058] The purpose of S4 is to perform filtering and conflict resolution on the candidate rule set, generate a deterministic rule subset and store it in the request-level cache, so that subsequent identical requests can directly obtain the available rule subset, and avoid complex conflict adjudication in the evaluation stage by resolving conflicts in advance.

[0059] The system sequentially performs operation type filtering and subject attribute filtering on the candidate rule set.

[0060] Operation type filtering involves selecting rules from the candidate rule set that match the operation type of the current request. Rules that do not match the operation type of the current request are removed at this stage.

[0061] Subject attribute filtering retrieves the real-time attributes of the accessing subject from the enterprise directory service and then selects rules from the rule set after operation filtering that satisfy all subject conditions. After operation type filtering and subject attribute filtering, a minimum necessary subset of rules is obtained.

[0062] A subset of deterministic rules is stored in a request-level cache indexed by a second index key, which is a combination of resource identifier, data level, operation type, and subject attribute.

[0063] It should be noted that conflict resolution answers which conflicting rules in the current subset of rules to be loaded or cached should be rejected. It needs to combine the current candidate subset, administrator policies, and conflict severity to generate the available subset of rules for this time.

[0064] By pre-emptively filtering and resolving conflicts, the subset of deterministic rules stored in the request-level cache is already a set of rules that has undergone conflict resolution and can be directly used for evaluation. When the same request arrives again, the system can directly return the cached subset of deterministic rules from the request-level cache, completely skipping the entire process of index retrieval, filtering, and conflict resolution. By moving conflict resolution from the evaluation stage to the cache write stage, the overhead of complex resolution after conflicting rules undergo ABAC evaluation is avoided.

[0065] S5: Receive a new access request, parse the resource identifier, data level, operation type and subject attribute in the access request to obtain the second index key and the index key, index the request-level cache with the second index key, and if the request-level cache is hit, directly return the subset of deterministic rules of the cache. If the request-level cache misses, the index-level cache is indexed using the index key. If the index-level cache hits, a candidate rule set is obtained, filtering and conflict resolution are performed, a deterministic rule subset is generated, and stored in the request-level cache indexed using the second index key. If neither the request-level cache nor the index-level cache is hit, then the step of querying the index of the runtime profile library is executed.

[0066] The purpose of S5 is to solve the problems of independent cache and index and lack of linkage between cache invalidation and rule change by using a hierarchical query mechanism of request-level cache and index-level cache.

[0067] The system receives a new access request, parses the resource identifier, data level, operation type, and subject attribute in the request, and obtains a second index key and an index key. The second index key is a combination of the resource identifier, data level, operation type, and subject attribute. The index key is a combination of the resource identifier and data level.

[0068] The system prioritizes indexing the request-level cache using the second index key. If the request-level cache is hit, it directly returns a subset of the cache's deterministic rules, completely skipping the index retrieval, filtering, and conflict resolution steps.

[0069] If the request-level cache misses, the system indexes the index-level cache using the index key. If the index-level cache hits, the system retrieves the candidate rule set, performs filtering and conflict resolution, generates a subset of deterministic rules, and stores it in the request-level cache indexed using the second index key.

[0070] If neither the request-level cache nor the index-level cache is hit, then the index step of querying the runtime profile library is executed, i.e., S3 and its subsequent steps.

[0071] Both request-level and index-level caches employ a dual expiration mechanism of TTL plus version number. The TTL for request-level cache is 5 minutes, and the TTL for index-level cache is 30 minutes. The cache automatically expires when the version number of the corresponding index item changes.

[0072] Request-level cache hits completely skip all filtering and evaluation steps, while index-level cache hits skip the index locating step. This hierarchical design ensures that earlier hits benefit more, while a version number linkage mechanism ensures consistency between cached data and index changes, avoiding cache pollution issues.

[0073] In a preferred embodiment of the present invention, the comprehensive popularity score is calculated as follows: The sliding time window counting method is used to sum the access frequencies within each time window according to an exponential decay weight, and the weighted sum is normalized to a preset interval to obtain the comprehensive popularity score. The closer the time window is to the current moment, the higher its weight.

[0074] The purpose of this preferred embodiment is to provide a quantitative scoring mechanism for each index key in the running profile library that can accurately reflect its recent access popularity and smooth out access volume fluctuations. This enables subsequent storage level upgrade / downgrade decisions, index entry cost assessments, and memory resource scheduling to be based on a unified and time-sensitive popularity index, thus solving the technical problem of delayed hotspot drift response caused by the lack of time decay characteristics of the popularity index.

[0075] The overall popularity score is calculated using a sliding time window counting method. The system maintains a fixed-length time window sequence, with each window lasting 5 minutes, and retains the most recent 60 windows. Within each window, the number of accesses to a specific index key within that time interval is recorded. When a new request arrives, the system adds the current request to the count of the current window and recalculates the weighted average access frequency over the most recent four windows. Windows closer to the current request have higher weights, using an exponentially decaying weight with a decay factor of 0.9.

[0076] The formula for calculating the overall popularity score, HotScore, is as follows: The access frequency of the current window is multiplied by 1.0, the access frequency of the previous window is multiplied by 0.7, the access frequency of the second-to-last window is multiplied by 0.4, and the access frequency of the third-to-last window is multiplied by 0.2, then normalized to the range of 0 to 1. The weighted sum of the most recent four windows is retained to eliminate the difference in absolute access frequency between different index keys.

[0077] It should be noted that the length of the time window can be adjusted, for example, using 1 minute, 10 minutes, or 15 minutes as the window length. The number of windows to retain can be set according to the system memory capacity and accuracy requirements, for example, retaining the most recent 30 or 120 windows.

[0078] In addition, the exponential decay weight can be replaced by other decay functions, such as linear decay functions, logarithmic decay functions, or power functions.

[0079] Normalization methods can include different approaches such as maximum value normalization, mean normalization, or quantile normalization.

[0080] The update frequency of the overall popularity score can be adjusted to update once every N requests processed, or to update periodically at fixed time intervals.

[0081] The comprehensive popularity score is calculated by combining a sliding time window counting method with exponentially decaying weights. This ensures that access behaviors more recent to the current time contribute more to the popularity score, allowing it to sensitively reflect the shifting trend of access hotspots. Normalization eliminates the impact of differences in absolute access volume between different index keys, enabling horizontal comparisons of popularity scores across different index keys. This provides a unified quantitative benchmark for subsequent storage tier upgrade / downgrade decisions and index entry cost assessments.

[0082] Based on this, the runtime profile library maintains the storage hierarchy state for each index key; When the overall popularity score of an index item exceeds the heat-up threshold and the current storage level is not a hot zone, the index item is upgraded to a hot zone, and its rule identifier list is loaded into memory. When the overall popularity score of an index item is lower than the cooling threshold and the current storage level is not a cold zone, the index item is triggered to be downgraded to a cold zone, and its data is serialized and written to disk.

[0083] The purpose of this embodiment is to dynamically adjust the storage level of each index item in the inverted index between the hot zone, the medium zone, and the cold zone according to the change of the comprehensive popularity score. This allows frequently accessed index items to automatically migrate to a faster memory level, and infrequently accessed index items to automatically release the memory resources they occupy. This solves the technical problem of low memory resource utilization and delayed response to hot requests caused by the inability of a fixed index structure to respond to hot spot drift.

[0084] The runtime profile library maintains the storage level state StorageTier for each index key, with a value that can be one of hot zone (HOT), warm zone (WARM), or cold zone (COLD).

[0085] When the overall popularity score of an index entry exceeds the warming threshold of 0.7 and the current storage level is not a hot zone, the index entry is upgraded to a hot zone.

[0086] The upgrade process involves reading the list of rule identifiers for the indexed items from the disk or temperature cache, converting it into a bitmap compressed format, loading it into the memory hotspot, and updating the StorageTier field.

[0087] The rule identifier list for hotspot index entries resides entirely in memory and is stored using bitmap compression encoding. This means the rule identifier list is encoded as a fixed-length bitmap, with each rule's global index in the rule base corresponding to a single bit in the bitmap. A value of 1 indicates that the rule belongs to that index entry. The advantage of bitmap storage is that the memory footprint of a single rule is compressed from 8 bytes to 1 bit, a compression ratio of 64 times, and set intersection, union, and complement operations can be completed in constant time using bitwise operations.

[0088] When the overall popularity score of an index item is lower than the cooling threshold of 0.2 and the current storage level is not a cold zone, the index item is triggered to be downgraded to a cold zone.

[0089] The degradation process involves removing index entries from the hot memory area, releasing the bitmap memory, serializing the data and writing it to disk, and updating the StorageTier field. Complete data for cold-zone index entries is stored on disk; only key and rule count statistics are retained in memory. When a cold-zone index entry is accessed, a synchronous disk read is triggered. After the read is complete, it is not cached in memory to avoid cold data polluting memory; it is directly used for filtering operations on the current request.

[0090] It should be noted that for other scenarios besides the two mentioned above, the storage hierarchy will not be adjusted.

[0091] Upgrade / downgrade operations are performed asynchronously in the background and do not affect ongoing access request processing. During the upgrade / downgrade process, the corresponding index entry is marked as migrating, and new access requests will automatically use the new storage tier after the migration is complete.

[0092] It should be noted that the heating and cooling thresholds can be adjusted according to the system memory capacity and performance requirements. For example, the heating threshold can be set to 0.6 or 0.8, and the cooling threshold to 0.15 or 0.25. The storage hierarchy can be expanded to four or more levels. For example, an ultra-hot zone can be added to store the most frequently accessed index entries, or an ultra-cold zone can be added to store archived data that has not been accessed for a long time. There are no restrictions on this.

[0093] Bitmap compressed storage can employ more efficient compressed data structures such as Roaring Bitmap to further improve memory utilization.

[0094] The triggering method for upgrades and downgrades can be set to periodic batch judgment, that is, the storage level of all index items is re-evaluated uniformly after each time window, rather than judging each item after each request.

[0095] By dynamically upgrading and downgrading storage tiers based on comprehensive popularity scores, index entries for popular resources can be automatically upgraded to memory hotspots and stored using bitmap compression. This ensures that high-frequency requests always execute along the optimal path, significantly reducing authentication response latency. Index entries for less popular resources are automatically downgraded to release memory resources, avoiding the memory waste caused by mixing hot and cold resources in a fixed index structure.

[0096] In a preferred embodiment of the present invention, the filtering based on operation type and subject attribute includes: The candidate rule set is filtered sequentially according to the operation type, and the rules that match the operation type field of the current request are selected to obtain the operation-filtered rule set; The rule set after operation filtering is filtered by subject attribute. The subject attribute of each rule is evaluated, and the rules that match the subject attribute field of the current request are selected to obtain the minimum necessary rule subset.

[0097] The purpose of this preferred embodiment is to perform two-level sequential filtering on the candidate rule set obtained by dynamic index entry location. First, rules that do not match the current request operation are quickly eliminated based on the basic dimension of operation type. Then, rules that satisfy all the subject conditions are selected from the rule set after operation filtering based on the refined dimension of subject attributes. This results in the minimum necessary rule subset that must be considered to complete the current access decision, solving the problem in the prior art where the candidate rule set is too large, leading to excessive computational overhead for subsequent conflict resolution and attribute evaluation.

[0098] The system sequentially performs operation type filtering and subject attribute filtering on the candidate rule set.

[0099] Operation type filtering involves selecting rules from the candidate rule set that match the operation type of the current request. Rules that do not match the current request's operation type are removed at this stage, resulting in the filtered rule set. Operation type matching includes cases where the operation types are the same, there is an inclusion relationship, or a wildcard match. Operation type filtering is the most basic filtering dimension, further narrowing down the size of the candidate set based on index entry point location.

[0100] Subject attribute filtering obtains the real-time attributes of the subject accessing the current session from the enterprise directory service, including department, job level, validity period, etc., and filters out rules that meet all subject conditions from the rule set after operation filtering. Rules that do not meet the subject conditions are removed at this stage.

[0101] The rule set obtained after operation type filtering and subject attribute filtering is the minimum necessary rule subset. Each rule in this subset has undergone three layers of filtering: resource and data level positioning, operation type matching, and subject condition matching. It represents the minimum set of rules that must be considered to complete this access decision. The size of this subset is determined by constraints in engineering practice; the number of rules under the same resource and data level is usually limited and is independent of the total size of the rule base. If the minimum necessary rule subset is empty, the system returns a default rejection result.

[0102] It should be noted that the order of operation type filtering and subject attribute filtering can be interchanged. Subject attribute filtering can employ a subject condition evaluation method based on the SMT satisfiability modular theory solver, transforming the subject condition of each rule into an SMT constraint expression, and then substituting the subject attribute values ​​of the current request into the expression to check if the constraint is satisfied. Subject attribute filtering can use a multi-level filtering approach, first filtering by coarse-grained attributes such as department, then by fine-grained attributes such as job level, gradually reducing the size of the rule set.

[0103] By executing operation type filtering and subject attribute filtering sequentially, the candidate rule set is progressively narrowed down to the minimum necessary rule subset before entering conflict resolution and ABAC evaluation. This ensures that subsequent conflict resolution only needs to be performed on this minimum subset, avoiding complex conflict adjudication on the complete candidate rule set. Operation type filtering, as a fundamental dimension, is executed before subject attribute filtering, enabling the rapid elimination of a large number of mismatched rules with lower computational cost. This reduces the number of rules to be evaluated in the subject attribute filtering stage, forming a progressive filtering structure from coarse to fine.

[0104] In a preferred embodiment of the present invention, the method further includes: After the initial access request is processed, the time-series correlation features corresponding to the current index key in the running profile library are queried to obtain the list of subsequent index keys with a conditional probability not lower than the preloading threshold. The first few are selected as preloading targets in descending order of conditional probability. For each preloaded target, the corresponding rule identifier list is read from the inverted index, and the rule identifier list is written as a candidate rule set into the index-level cache that executes the index with the subsequent index key.

[0105] The purpose of this preferred embodiment is to use the temporal correlation features recorded in the runtime profile library to predict the index key that the user may access later after the initial access request is processed, and to write the corresponding rule identifier list into the index-level cache in advance, so that subsequent requests can obtain the candidate rule set with fewer calculation steps. This solves the technical problem that there is no effective correlation model between the preloading mechanism and the historical access pattern, and that the preloading trigger lacks a basis.

[0106] After the initial access request is processed, the system queries the CoOccurrenceMatrix, the time-series correlation feature corresponding to the current index key in the runtime profile library, to obtain a list of subsequent index keys with a conditional probability not lower than the preload threshold.

[0107] The conditional probability is calculated as follows: using the same user or the same session as the statistical unit, within a preset time window, if a user first accesses the current index key and then subsequently accesses the target index key, this is recorded as a co-occurrence. Then, the conditional probability P(Key_j|Key_i) of subsequently accessing the target index key is obtained by dividing the number of co-occurrences of accessing the current index key followed by the number of times the current index key is accessed. It should be noted that time decay can also be introduced to give higher weight to recent co-occurrences.

[0108] The system sorts the subsequent index keys with conditional probabilities not lower than the preloading threshold (default 0.3) in descending order of conditional probability, and selects the top few (maximum 3 by default) as preloading targets. For each preloading target, the system reads the corresponding rule identifier list from the elastic inverted index, and writes the rule identifier list as a candidate rule set into the index-level cache of the subsequent index key execution index.

[0109] During the preloading process, if it is found that the target index key is currently in the cold zone (i.e., full disk storage), then this preloading will only preload the metadata of that index key to the warm zone, without loading the complete rule list, in order to avoid frequent disk reads crowding out the processing resources of the current request.

[0110] The statistical units for time-series correlation features can be extended to the user group or department level to make predictions using group access patterns when individual user historical data is insufficient.

[0111] The default value for the preloading threshold can be adjusted to 0.2 or 0.4, and the maximum number of preloaded targets can be adjusted to 5 or 10 without restriction. The co-occurrence probability matrix can use a sparse matrix storage structure to reduce memory usage.

[0112] By using predictive preloading based on temporal correlation features, the system can pre-write a list of rule identifiers corresponding to the index keys that may be accessed into the index-level cache before the user actually initiates an access. When the user subsequently accesses the index key, the system can directly retrieve the candidate rule set from the index-level cache, skipping the index location step, and only need to perform filtering and conflict resolution to generate a deterministic rule subset.

[0113] Preloading is triggered asynchronously after the initial request is processed, without blocking the response to the current request. This preferred implementation provides clear data support for preloading decisions, improving the effectiveness of preloading.

[0114] In one embodiment, the preload accuracy is periodically calculated, and the statistical results are backfilled into the runtime profile library; When the preload accuracy is lower than the first accuracy threshold, the preload threshold is increased; When the preload accuracy is higher than the second accuracy threshold, the preload threshold is reduced; wherein the first accuracy threshold is lower than the second accuracy threshold.

[0115] The purpose of this embodiment is to solve the technical problems of invalid preloading occupying cache resources when the accuracy drops and insufficient preloading coverage when the accuracy is high by statistically analyzing the preloading accuracy and backfilling it into the runtime profile library, and adaptively adjusting the preloading threshold according to the accuracy. This allows the preloading strategy to be automatically optimized as the actual access pattern changes, thus solving the technical problems of invalid preloading occupying cache resources when the accuracy drops due to a fixed preloading threshold setting and insufficient preloading coverage when the accuracy is high.

[0116] The system records the actual hit rate of each preload. If the subsequent index key of the preloaded key is actually accessed by the user within a preset time window (e.g., 10 minutes) after the preload is completed, it is recorded as a valid preload. Otherwise, it is recorded as an invalid preload. The system periodically (e.g., hourly) calculates the preload accuracy rate, which is the ratio of the number of valid preloads to the total number of preloads.

[0117] The system populates the runtime profile database with statistical results and adjusts the preloading threshold accordingly. When the preloading accuracy is lower than the first accuracy threshold (e.g., 30%), it indicates that the current preloading strategy has a low hit rate and there are many invalid preloads. The system automatically increases the preloading threshold (e.g., from 0.3 to 0.5) to reduce the number of preload targets and reduce the impact of invalid preloads on cache resources. When the preloading accuracy is higher than the second accuracy threshold (e.g., 70%), it indicates that the current preloading strategy has a high hit rate and the preloading targets are relatively accurate. The system appropriately lowers the preloading threshold to improve preloading coverage and include more potentially accessed index keys in the preloading scope. The preloading threshold has upper and lower limits, for example, a lower limit of 0.2 and an upper limit of 0.8.

[0118] The first and second accuracy thresholds can be adjusted based on system cache capacity and performance requirements. Preload accuracy can be calculated separately for each index key, with different preload thresholds applied to different index keys. Preload accuracy can also be linked to the weighting of co-occurrence probability calculations; when accuracy remains consistently low, the weight of the corresponding subsequent index key in the co-occurrence probability is reduced without restriction.

[0119] By adaptively adjusting the preloading threshold based on preloading accuracy feedback, the system can dynamically optimize the preloading strategy according to the actual preloading hit rate during operation. When the accuracy is low, the preloading threshold is increased to reduce the crowding of cache resources by invalid preloading and prevent invalid data from entering the index-level cache. When the accuracy is high, the preloading threshold is decreased to expand the preloading coverage, allowing more rule identifier lists corresponding to potentially accessed index keys to enter the cache in advance. The statistical results of preloading accuracy are populated back into the runtime profile library, providing feedback for subsequent preloading decisions and enabling the preloading strategy to automatically adjust according to changes in access patterns.

[0120] In a preferred embodiment of the present invention, when access control rules are added, modified, or deleted, the following operations are performed: Update the inverted index; Incremental conflict detection is performed on newly added rules, modified rules, and all existing rules under the same index key to determine whether the scope of the main condition of two rules overlaps. If there is an intersection, the operation type and decision result are further compared to distinguish the conflict relationship between the two rules into hard conflict and soft conflict, and the detection result is written into the conflict summary feature of the running state profile library. For deletion rules, all conflicting relationships associated with the deletion rule are removed from the conflict summary feature.

[0121] The purpose of this preferred implementation is to synchronously update the inverted index and perform incremental conflict detection on the changed rules when access control rules are added, modified, or deleted, and write the detection results into the conflict summary feature of the runtime profile library, thereby solving the technical problems that rule conflict detection is independent of the index maintenance process and that the conflict increment brought by the new rules cannot be perceived in real time.

[0122] When access control rules are added, modified, or deleted, the system performs the following operations.

[0123] Update the inverted index. When a rule is modified or deleted, if the rule is removed from the index key Key_old, remove the rule ID from the rule identifier list of that key, update the version number of the key, remove all conflicting edges related to the rule in the conflict bitmap of the image library, and set the corresponding row and column to zero in the bitmap.

[0124] When a new rule is added, if the rule is added under the index key Key_new, the rule ID is added to the end of the rule identifier list for that key, and the version number of that key is updated.

[0125] Incremental conflict detection is performed on newly added rules, modified rules, and all existing rules under the same index key. It determines whether the scope of the principal conditions of two rules overlaps. This is essentially a constraint satisfiability problem. In a preferred embodiment, a lightweight constraint propagation algorithm based on the SMT satisfiability modular theory solver is used to implement this, transforming the principal condition of each rule into an SMT constraint expression and detecting whether the constraint expressions corresponding to two rules can be satisfied simultaneously. Since the number of rules under the same index key is usually no more than 50, the computational cost of this detection is within an acceptable range.

[0126] If there is an intersection, the operation type and decision result are further compared to distinguish the conflict relationship between the two rules into hard conflict and soft conflict. The detection result is written into the conflict summary features ConflictBitmap and ConflictSeverity of the running portrait library.

[0127] The core of the conflict bitmap is an N-by-N bitmap, where N is the number of rules under the index key. Bit[i][j] equals 1, indicating that rule i and rule j conflict. Rule pairs with conflict levels 2 and 1 are both marked in the conflict bitmap. The difference between level 2 and level 1 lies in the additional marker bits in the bitmap, so that different resolution strategies can be adopted according to the severity of the conflict during the preloading and evaluation phases.

[0128] For deletion rules, remove all conflicting relationships associated with the deletion rule from the conflict summary feature.

[0129] All the above operations are completed within the same database transaction, ensuring data consistency among the rule store, index, and profile library. If any step fails, all operations are rolled back to the state before the operation.

[0130] It's important to note that the rule writing phase primarily involves conflict detection and conflict summary updates, not direct rewriting or deletion of all conflicting rules. The incremental conflict detection during the writing phase identifies which rules might conflict, creating a conflict bitmap and its severity, applicable to the entire set of rules under the index key, not a specific request. The actual resolution and adjudication based on the loading result primarily occur during the preloading and request-driven loading phases.

[0131] The incremental conflict detection can be set to execute automatically before rule changes are saved, and a warning message with conflict details will pop up when a conflict is detected. The conflict detection results can be used to calculate the rule merging priority using topological sorting of the directed acyclic graph. The SMT solver can be replaced with a conflict detection algorithm based on attribute decomposition or other constraint satisfiability detection algorithms; there are no restrictions on this.

[0132] By embedding conflict detection into the index maintenance process for incremental execution, conflict states are detected and recorded in the conflict summary features of the profile library as soon as rules change. Subsequent rule loading and preloading can directly utilize the conflict summary for pre-emptive resolution, eliminating the need for additional conflict adjudication during the evaluation phase. This incremental detection approach avoids the overhead of performing a static scan of the entire rule base after each rule change.

[0133] It should be noted that the incremental conflict detection distinguishes between hard conflicts and soft conflicts in the conflict relationship between two rules: When the scope of the main conditions of two rules overlaps, and the operation types are the same or there is an inclusion relationship, and the decision results are opposite, it is judged as a hard conflict, and the conflict resolution strategy of execution time priority or rejection priority is adopted. When the scope of the main conditions of two rules overlaps, and the operation types overlap but are not completely inclusive, and the decision results are opposite, it is determined to be a soft conflict, and a conflict resolution strategy that processes them according to the priority order of the rules is executed.

[0134] The purpose of this embodiment is to provide clear conflict type determination rules and corresponding resolution strategies for incremental conflict detection, so that the system can adopt differentiated processing methods according to the severity of the conflict, and solve the technical problem that the lack of classification of conflict detection results makes it difficult to adapt the resolution strategy.

[0135] Incremental conflict detection distinguishes between hard conflicts and soft conflicts in the conflict relationship between two rules.

[0136] When two rules have overlapping scopes, the same or inclusive operation types, and opposite decision outcomes, they are considered to have a hard conflict, marked as conflict level 2. For example, if rule Ri allows reading while rule Rj refuses reading, the two rules have the same operation type and opposite decision outcomes, thus constituting a hard conflict. For hard conflict rule pairs, a conflict resolution strategy of time priority or rejection priority is applied. Time priority uses the most recently modified rule, while rejection priority selects the rule that rejects the decision in the event of a conflict.

[0137] When two rules have overlapping scopes, overlapping but not completely inclusive operation types, and opposite decision results, they are considered a soft conflict and marked as conflict level 1. For example, rule Ri allows read and write operations while rule Rj allows read-only operations; the operation types of the two rules overlap but are not completely inclusive, and their decision results are opposite, thus constituting a soft conflict. For soft conflict rule pairs, they are processed according to rule priority to resolve the conflict. During ABAC evaluation, rules are evaluated sequentially according to priority, with the first rule to be hit receiving the decision, and an alarm log is generated to alert the administrator.

[0138] Other cases are marked as no conflict, with a conflict level of 0.

[0139] Both conflict level 2 and 1 rules are marked in the conflict bitmap. The difference between level 2 and level 1 lies in the additional marker bits in the bitmap, so that different resolution strategies can be adopted according to the severity of the conflict during the preloading and evaluation phases.

[0140] The priority order of soft conflicts can be determined based on the rule's creation time, modification time, or the priority specified by the administrator. Hard conflict resolution strategies can be configured according to system security policies; for example, in high-security scenarios, a denial-first approach is used by default.

[0141] By classifying conflicts into hard and soft conflicts and configuring differentiated resolution strategies for each, the system can avoid unnecessary rule rejections while ensuring security. Conflicts are resolved quickly through automatic adjudication, avoiding the overhead of complex adjudication after conflict rules enter ABAC evaluation. The additional flag bit in the bitmap indicating the severity of the conflict enables rapid identification of conflict types and corresponding handling methods during the preloading and evaluation phases.

[0142] A second aspect of the present invention provides an access control rule adaptive loading system, comprising: The profile library maintenance module is used to maintain the runtime profile library. The runtime profile library uses a combination of resource identifier and data level as the index key. For each index key, it records access popularity characteristics, conflict summary characteristics and time-series correlation characteristics, and constructs an inverted index with the index key as the execution index. Each index item in the inverted index corresponds to an index key and its associated list of rule identifiers. The elastic inverted index module is used to dynamically allocate each index item in the inverted index to a storage level among the hot zone, warm zone, and cold zone based on the comprehensive popularity score in the access popularity feature, and to trigger the upgrade or downgrade judgment of the storage level when the comprehensive popularity score of each index item changes; and to read the corresponding rule identifier list according to the index key to obtain the candidate rule set. A multi-level caching module includes an index-level cache that performs indexing based on an index key and a request-level cache that performs indexing based on a second index key; the second index key is a combination of resource identifier, data level, operation type, and subject attribute; the index-level cache is used to store a set of candidate rules, and the request-level cache is used to store a subset of deterministic rules; The rule filtering module is used to filter candidate rule sets by operation type and subject attribute to obtain the minimum necessary rule subset; The conflict detection and resolution module is used to query the conflict summary features of the index keys corresponding to the minimum necessary rule subset, and generate a deterministic rule subset after performing conflict resolution. The request scheduling module receives access requests, parses the resource identifier, data level, operation type, and subject attribute to obtain the second index key and the index key. It prioritizes indexing the request-level cache with the second index key. If a match is found, it directly returns a subset of deterministic rules from the cache. If no match is found, it indexes the index-level cache with the index key. If a match is found, it obtains a set of candidate rules and passes them to the rule filtering module and conflict detection and resolution module for processing. If no match is found at either level, it calls the elastic inverted index module to execute the index query process.

[0143] Therefore, it is possible to achieve any effect of an adaptive loading method for access control rules, which will not be elaborated here.

[0144] For any parts not mentioned in this invention, existing technologies can be used or referenced.

[0145] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0146] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. An adaptive loading method for access control rules, characterized in that, include: Maintain a runtime profile library, which uses a combination of resource identifier and data level as the index key. For each index key, record access popularity characteristics, conflict summary characteristics, and time-series correlation characteristics. Construct an inverted index that executes the index based on the index key. Each index item in the inverted index corresponds to an index key and its associated list of rule identifiers. Based on the comprehensive popularity score in the access popularity feature, each index item in the inverted index is dynamically allocated to one of the storage levels in the hot zone, warm zone, and cold zone, and the upgrade or downgrade judgment of the storage level is triggered when the comprehensive popularity score of each index item changes. For the initial access request, the resource identifier, data level, operation type and subject attribute in the access request are parsed. An index key is generated based on the resource identifier and data level. The runtime profile library is queried. Based on the index key, the corresponding rule identifier list is read to obtain the candidate rule set, which is then stored in the index-level cache that executes the index with the index key. The candidate rule set is filtered by operation type and subject attribute to obtain a minimum necessary rule subset. The conflict summary feature of the index key corresponding to the minimum necessary rule subset is queried. After conflict resolution, a deterministic rule subset is generated and stored in the request-level cache with the second index key. The second index key is a combination of resource identifier, data level, operation type and subject attribute. Upon receiving a new access request, the resource identifier, data level, operation type, and subject attribute in the access request are parsed to obtain a second index key and an index key. The second index key is used to index the request-level cache. If the request-level cache is hit, a subset of the cache's deterministic rules is returned directly. If the request-level cache misses, the index-level cache is indexed using the index key. If the index-level cache hits, a candidate rule set is obtained, filtering and conflict resolution are performed, a deterministic rule subset is generated, and stored in the request-level cache indexed using the second index key. If neither the request-level cache nor the index-level cache is hit, then the step of querying the index of the runtime profile library is executed.

2. The method according to claim 1, characterized in that, The calculation method for the comprehensive popularity score is as follows: The sliding time window counting method is used to sum the access frequencies within each time window according to an exponential decay weight, and the weighted sum is normalized to a preset interval to obtain the comprehensive popularity score. The closer the time window is to the current moment, the higher its weight.

3. The method according to claim 2, characterized in that, The runtime profile library maintains the storage hierarchy state for each index key; When the overall popularity score of an index item exceeds the heat-up threshold and the current storage level is not a hot zone, the index item is upgraded to a hot zone, and its rule identifier list is loaded into memory. When the overall popularity score of an index item is lower than the cooling threshold and the current storage level is not a cold zone, the index item is triggered to be downgraded to a cold zone, and its data is serialized and written to disk.

4. The method according to claim 1, characterized in that, The filtering based on operation type and subject attribute includes: The candidate rule set is filtered sequentially according to the operation type, and the rules that match the operation type field of the current request are selected to obtain the operation-filtered rule set; The rule set after operation filtering is filtered by subject attribute. The subject attribute of each rule is evaluated, and the rules that match the subject attribute field of the current request are selected to obtain the minimum necessary rule subset.

5. The method according to claim 1, characterized in that, Also includes: After the initial access request is processed, the time-series correlation features corresponding to the current index key in the running profile library are queried to obtain the list of subsequent index keys with a conditional probability not lower than the preloading threshold. The first few are selected as preloading targets in descending order of conditional probability. For each preloaded target, the corresponding rule identifier list is read from the inverted index, and the rule identifier list is written as a candidate rule set into the index-level cache that executes the index with the subsequent index key.

6. The method according to claim 5, characterized in that, Periodically calculate the preload accuracy and populate the results back into the runtime profile library; When the preload accuracy is lower than the first accuracy threshold, the preload threshold is increased; When the preload accuracy is higher than the second accuracy threshold, the preload threshold is reduced; wherein the first accuracy threshold is lower than the second accuracy threshold.

7. The method according to claim 1, characterized in that, When access control rules are added, modified, or deleted, perform the following operations: Update the inverted index; Incremental conflict detection is performed on newly added rules, modified rules, and all existing rules under the same index key to determine whether the scope of the main condition of two rules overlaps. If there is an intersection, the operation type and decision result are further compared to distinguish the conflict relationship between the two rules into hard conflict and soft conflict, and the detection result is written into the conflict summary feature of the running state profile library. For deletion rules, all conflicting relationships associated with the deletion rule are removed from the conflict summary feature.

8. The method according to claim 7, characterized in that, The incremental conflict detection distinguishes between hard conflicts and soft conflicts in the conflict relationship between two rules: When the scope of the main conditions of two rules overlaps, and the operation types are the same or there is an inclusion relationship, and the decision results are opposite, it is judged as a hard conflict, and the conflict resolution strategy of execution time priority or rejection priority is adopted. When the scope of the main conditions of two rules overlaps, and the operation types overlap but are not completely inclusive, and the decision results are opposite, it is judged as a soft conflict and processed according to the priority order of the rules.

9. An adaptive loading system for access control rules, characterized in that, include: The profile library maintenance module is used to maintain the runtime profile library. The runtime profile library uses a combination of resource identifier and data level as the index key. For each index key, it records access popularity characteristics, conflict summary characteristics and time-series correlation characteristics, and constructs an inverted index with the index key as the execution index. Each index item in the inverted index corresponds to an index key and its associated list of rule identifiers. The elastic inverted index module is used to dynamically allocate each index item in the inverted index to a storage level among the hot zone, warm zone and cold zone based on the comprehensive popularity score in the access popularity feature, and to trigger the upgrade or downgrade judgment of the storage level when the comprehensive popularity score of each index item changes. And based on the index key, read the corresponding rule identifier list to obtain the candidate rule set; A multi-level caching module, including an index-level cache that executes indexing based on an index key and a request-level cache that executes indexing based on a second index key; The second index key is a combination of resource identifier, data level, operation type, and subject attribute; the index-level cache is used to store candidate rule sets, and the request-level cache is used to store subsets of deterministic rules; The rule filtering module is used to filter candidate rule sets by operation type and subject attribute to obtain the minimum necessary rule subset; The conflict detection and resolution module is used to query the conflict summary features of the index keys corresponding to the minimum necessary rule subset, and generate a deterministic rule subset after performing conflict resolution. The request scheduling module is used to receive access requests, parse the resource identifier, data level, operation type and subject attribute to obtain the second index key and the index key. It prioritizes indexing the request-level cache with the second index key. If a hit occurs, it directly returns a subset of deterministic rules in the cache. If a miss occurs, it indexes the index-level cache with the index key. If a hit occurs, it obtains a set of candidate rules and passes them to the rule filtering module and the conflict detection and resolution module for processing. If neither level is matched, the elastic inverted index module is invoked to execute the index query process.

Images