Permission rule storage and retrieval method

Abstract

The invention relates to a permission rule storage and retrieval method which comprises an ordered index, a hash index and a directed acyclic graph index. The invention discloses an index-based authority rule management process, an addition process, a deletion process and a retrieval process. In the index-based authority rule management process, an index of a user range or an object range comprises two parts: an index information extractor for extracting index information from the user range or the object range; the index data manager is used for providing permission rule adding capability, permission rule deleting capability and permission rule query capability based on the index information extracted by the index information extractor; the two parts have a synergistic effect and jointly manage the authority rules, so that the problems of high time complexity and low efficiency of executing authority reasoning by a current authority rule storage and retrieval method are solved, and the method has lower retrieval delay and lower retrieval resource occupation.

Description

Technical Field

[0001] This invention relates to a permission management technology, and more particularly to a method for storing and retrieving permission rules. Background Technology

[0002] The authentication center is a core component of the data management platform for overall access control, managing the permissions of personnel in different departments and positions within the platform. To meet the needs of refined access control, the authentication center required the design of an efficient method for storing and retrieving access rules during its development. This method would enable the rapid retrieval of relevant rules from millions of access rules to complete the authorization process.

[0003] In current mainstream technical solutions, access control includes two steps: authentication and authorization. In the authentication step, the system typically needs to verify the user's identity information through various methods (including but not limited to username / password, API key, and two-factor authentication). In the authorization step, the system typically needs to retrieve and confirm the user's permissions and the scope of those permissions. This invention primarily addresses the authorization step, solving the problem of storing and retrieving access control rules. There are three main authorization models in the authorization step: 1. ACL (Access Control List): A permission control list containing three elements: user, object, and permission; for example, alice-read-book1 means that user alice has the permission to read object book1. 2. RBAC (role-based access control): Role-based access control includes four elements: user, role, object, and permission; for example, alice-editor-read-book1 means that user alice has the permission to read object book1 because she has the role editor; 3. ABAC (attribute-based access control): Attribute-based access control includes three elements: user scope, permission, and object scope. For example, prefix(user, a)-read-prefix(object, book) means that a user whose user scope starts with 'a' has the permission to read objects whose object scope starts with 'book'. The user scope and object scope are often expressions without a fixed structure. For details on the expressions, please refer to the description in the specific implementation. In terms of model capabilities, ABAC is generally considered to be superior to RBAC, which in turn is superior to ACL. In mainstream commercial products, ABAC and RBAC are often combined to form models such as...Figure 1 The illustrated permission rule includes four elements: user scope, role, permission, and object scope. For example, `prefix(user, 'a')-editor-read-prefix(object, 'book')` means that a user whose user scope starts with 'a' has the role 'editor' and therefore has the permission to read objects whose object scope starts with 'book'. In actual implementation, the role 'editor' may be bound to multiple user scopes and may have different permissions for objects in multiple different object scopes. More examples of this type of ABAC and RBAC combination can be found in the detailed implementation description. To more accurately describe the existing solution, we will assume the following permission rules need to be stored and retrieved: 1. User range: prefix(user, 'a'): users whose usernames begin with 'a'; prefix(user, 'b'): users whose usernames begin with 'b'; 2. Role: editor; 3. Permissions - Object Scope: read-prefix(object, 'book'): Has read permission for objects whose scope begins with 'book'; write-prefix(object, 'book'): Has write permission for objects whose scope begins with 'book'; read-prefix(object, 'diary'): Has read permission for objects whose scope begins with 'diary' (but no write permission). In common implementations, such as Casbin (an open-source access control framework), permission rules are stored according to the following logic: 1. Divide the permission rules into two parts: user scope-role and role-permission-object scope; 2. Store the rules for these two ranges separately in lists in memory; prefix(user, 'a')-editor; prefix(user, 'b')-editor; editor-read-prefix(object, 'book'); editor-write-prefix(object, 'book'); editor-read-prefix(object, 'diary'); At this point, to perform a permission retrieval request: "Check if alice has write permissions for book1", the existing method would execute it as follows: 1. Iterate through all user-role rules and verify that the prefix(user, 'a')-editor rule matches; 2. Iterate through all role-permission-object scope rules and verify that the editor-write-prefix(object, 'book') rule matches; Considering that the actual number of permission rules stored is related to the algorithm design and implementation, in order to avoid ambiguity in the description of the number of permission rules, the meaning of the number of permission rules is defined as follows: "1 permission rule" refers to "a permission rule with role as the core, including multiple user bindings, multiple object bindings and permissions". For example, the permission rule example here refers to "1" permission rule rather than "multiple" permission rules.

[0004] Under the existing related technologies, the following two problems exist in the more common implementations: 1. High retrieval latency: For a typical 8-core 8GB single-machine setup, the latency caused by 100,000 rules can reach approximately 0.2 seconds; 2. High resource consumption during retrieval: Each retrieval requires traversing all rules once, which consumes a lot of computing and memory resources; Matching and retrieving data by traversing rules theoretically has a time complexity of O(n) (where n is the number of rules). As the number of objects to be managed increases, the time required to verify the rules grows linearly, and authorization and authentication operations are often time-sensitive. Therefore, a more efficient data storage structure needs to be designed to avoid the time complexity of reasoning increasing linearly with the number of rules and to improve query efficiency. Summary of the Invention

[0005] To address the problem of high time complexity and low efficiency in the current methods for storing and retrieving permission rules, a new method for storing and retrieving permission rules is proposed.

[0006] The technical solution of this invention is: a method for storing and retrieving permission rules, including three types of indexes: ordered index, hash index, and directed acyclic graph index, and permission rule management process, addition process, deletion process, and retrieval process based on the indexes: Index-based permission rule management process: The user-scoped or object-scoped index consists of two parts: Index Information Extractor: extracts index information from the user-scoped or object-scoped scope; Index Data Manager: based on the index information extracted by the Index Information Extractor, it provides the ability to add, delete, and query permission rules; these two parts work together to manage permission rules. Permission rule addition process: Input a permission rule to be added, which includes multiple user scopes, one role, multiple permissions, and corresponding object scopes; Iterate through each user scope of the input permission rule. For each index built for a user scope, attempt to extract index information from the user scope using the index information extractor; If index information is extracted, add the permission rule to the index using the index data manager; If no index information is extracted, add the permission rule to the "User Scope Unindexable List"; Iterate through each object scope of the input permission rule. For each index built for an object scope, attempt to extract index information from the object scope using the index information extractor; If index information is extracted, add the permission rule to the index using the index data manager; If no index information is extracted, add the permission rule to the "Object Scope Unindexable List"; Permission rule deletion process: Input a permission rule to be deleted, which includes multiple user scopes, one role, multiple permissions, and corresponding object scopes; Iterate through each user scope of the input permission rule, and for each index built for the user scope, attempt to extract index information from the user scope using the index information extractor; If the index information is extracted, delete the permission rule from the index data manager; If the index information is not extracted, delete the permission rule from the "User Scope Unindexable List"; Iterate through each object scope of the input permission rule, and for each index built for the object scope, attempt to extract index information from the object scope using the index information extractor; If the index information is extracted, delete the permission rule from the index data manager; If the index information is not extracted, delete the permission rule from the "Object Scope Unindexable List"; In the permission rule retrieval process, permission judgment is performed as follows: Input user, object, and permission; For each user range index, the permission rules are obtained from the index data manager based on the index information, denoted as set X1; Traverse all permission rules in the "user range cannot be indexed list", evaluate each one through expression to obtain the user range and corresponding permission rules that meet the conditions, denoted as set X2; For each object range index, the permission rules are obtained from the index data manager based on the index information, denoted as set X3; Traverse all permission rules in the "object range cannot be indexed list", evaluate each one through expression to obtain the object range and corresponding permission rules that meet the conditions, denoted as set X4; Take the union of set X1 and set X2 to obtain permission rule set X5, take the union of set X3 and set X4 to obtain permission rule set X6, take the intersection of set X5 and set X6 to obtain permission rules that simultaneously satisfy both user range and object range, traverse this part of permission rules, if there is a permission rule that matches the input permission, it is judged as authorization passed, otherwise it is judged as authorization failed; In the permission rule retrieval process, permission acquisition is performed as follows: Input user; index each user range, and retrieve permission rules based on the index information in the index data manager, denoted as set Y1; traverse all permission rules in the "user range cannot be indexed list", evaluate each one through expression, and obtain the user range and corresponding permission rule that meet the conditions, denoted as set Y2; take the union of set Y1 and set Y2 to obtain permission rule set Y3, merge the object range and corresponding permissions of the permission rules in set Y3, and return the merged result.

[0007] Furthermore, the applicable scenarios and implementation methods of ordered indexes: Applicable scenarios: In the search of permission rules, if an atomic proposition within a user scope or object scope involves comparing the size of numbers or comparing the lexicographical order of strings, an ordered index can be built for that atomic proposition; Index information extractor implementation: The index information of an ordered index consists of two parts: the index key and the index range, for different forms of atomic propositions involving comparison of the size of numbers or lexicographical comparison of strings; The index data manager is implemented as follows: a red-black tree is used to store the index keys in the index information in order. The index value of each index key includes three sets of permission rules: "the set of permission rules with the index range greater than", "the set of permission rules with the index range equal to", and "the set of permission rules with the index range less than". The Index Data Manager implements permission rule addition, deletion, and querying as follows: Permission Rule Addition: Based on the extracted index information, the index key is added to the red-black tree, and the permission rule is added to the corresponding set in the index value. Permission Rule Deletion: Based on the extracted index information, if the index key itself is not in the red-black tree, the permission rule has not been added and does not need to be deleted. If the index key itself is in the red-black tree, the corresponding set in the index value is found based on the index range, and the permission rule is deleted from the set. Permission Rule Query: When a specific user or object is entered, the permission rule can be queried based on the entered user or object. The specific attribute values ​​of the object are extracted as index values, denoted as c. The red-black tree is searched as follows: For each index value with key c, extract the set of permission rules whose index range is equal to c, denoted as set c1; for each index value with key less than c, extract the set of permission rules whose index range is greater than c and take the union of these sets, denoted as set c2; for each index value with key greater than c, extract the set of permission rules whose index range is less than c and take the union of these sets, denoted as set c3; finally, the union of sets c1, c2, and c3 yields the final set of permission rules.

[0008] Furthermore, the applicable scenarios and implementation methods of hash indexes: Applicable scenario: In the search of permission rules, if an atomic proposition within a user scope or object scope involves a comparison of numerical equality, a hash index can be built for that atomic proposition; Index information extractor implementation: The index information of a hash index only contains a part - the index key, for atomic propositions involving numerical equality comparisons; The implementation of the hash index's index data manager involves using a hash table to store the index keys in the index information. Each index key's index value includes a set of permission rules. The hash index's index data manager implements permission rule addition, deletion, and querying as follows: Adding Permission Rules: Based on the extracted index information, add the index key to the hash table and add the permission rule to the permission rule set in the index value. Deleting Permission Rules: Based on the extracted index information, if the index key itself is not in the hash table, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, delete the permission rule from the permission rule set in the index value. Querying Permission Rules: When a specific user or object is input, the specific attribute value can be extracted as the index value based on the input user or object's attributes. The index value is set as 'a', and the hash table is searched in the following way: obtain the index value with index key 'a', and extract the permission rule set from the index value.

[0009] Furthermore, the applicable scenarios and implementation methods for directed acyclic graphs: Applicable scenario: In the search of permission rules, if an atomic proposition in a user scope or object scope involves nested relationships in a directed acyclic graph, a directed acyclic graph index can be built for that atomic proposition; Index information extractor implementation: The index information of a directed acyclic graph index only contains a part - the index key, for atomic propositions involving numerical equality comparisons; The index data manager is implemented by using a directed acyclic graph (DAG) to store the index keys in the index information in parent-child order. The index value of each index key includes a set of permission rules. The construction of the DAG index also requires the introduction of additional external information, including adding and deleting parent-child relationships between the index keys in the DAG. The Index Data Manager implements the following methods for adding, deleting, adding, deleting, and querying parent-child relationships of index keys: Adding Parent-Child Relationships: Input two index keys and add them as graph nodes to the directed acyclic graph (DAG), recording the connection information; Deleting Parent-Child Relationships: Input two index keys and search for their existence in the DAG. If they do not exist, the parent-child relationship has not been added and does not need to be deleted; if they exist, the parent-child relationship is deleted; Adding Permission Rules: Based on the extracted index information, add the index keys to the DAG and add the permission rules to the permission rule set in the index value; Deleting Permission Rules: Based on the extracted index information, if the index key itself... If a node is not in the directed acyclic graph, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, delete the permission rule from the permission rule set in the index value. Permission rule query: When a specific user or object is input, the specific attribute value can be extracted as the index value based on the attributes of the input user or object. Let the index value be b. Search in the red-black tree as follows: Get the index value with index key b, extract the permission rule set from it, and denote it as set b1; Traverse the entire directed acyclic graph, get the index values ​​of all child nodes with index key b, extract the permission rule set from these index values ​​and take the union, and denote it as set b2; Take the union of set b1 and set b2 to obtain the final permission rule set.

[0010] Preferably, the index is selected based on the actual data situation: For a user or object, there are a large number of different attributes, and only a portion of these attributes are used for permission judgment. Based on the analysis of the business, indexes are used for some attributes, and indexes are not needed for other attributes. Indexes are added gradually according to the data situation, and the system operation is optimized as the system is used. The index data structure is selected according to the data type and the common forms of atomic propositions. For example, when the data type is string and the atomic propositions are mostly prefix matching, a radix tree index is selected.

[0011] In the preferred implementation of the ordered index information extractor, for atomic propositions involving comparison of the size of numbers or lexicographical comparison of strings, the extracted index information is as follows: For the atomic proposition "variable value A is greater than or equal to value b", the extracted index key is "value b", and the index range is "greater than" or "equal to"; For the atomic proposition "variable value A is greater than value b", the extracted index key is "value b", and the index range is "greater than"; For the atomic proposition "variable value A is equal to value b", the extracted index key is "value b", and the index range is "equal to"; For the atomic proposition "variable value A is less than value b", the extracted index key is "value b", and the index range is "less than"; For the atomic proposition "variable value A is less than or equal to value b", the extracted index key is "value b", and the index range is "less than" or "equal to".

[0012] Preferably, in the implementation of the hash index information extractor, for atomic propositions involving numerical equality comparisons, the extracted index information is as follows: for the atomic proposition "variable value A is less than or equal to value b", the index key "value b" is extracted.

[0013] In the preferred implementation of the index information extractor for a directed acyclic graph index, for atomic propositions involving numerical equality comparisons, the extracted index information is as follows: for the atomic proposition "all child nodes of value b", the index key "value b" is extracted.

[0014] The beneficial effects of this invention are as follows: Compared to existing implementations of full-rule traversal, such as Casbin, the advantages of this invention are as follows: 1. The time and space complexity of permission rule retrieval itself is lower. When the index is hit, the complexity may drop to O(1) at most (when a hash index or a directed acyclic graph index is triggered), depending on the index situation. At least a constant level of complexity reduction can be achieved (when an ordered index is triggered). 2. Indexing permission rules is to some extent equivalent to pre-evaluating the expression when writing permission rules. Finding a rule by indexing is significantly faster and more cache-friendly in actual engineering implementations than evaluating the expression of the rule. Although it introduces higher write costs to some extent, it still significantly improves the performance of permission management, which is a read-heavy and write-light scenario. These advantages will enable the present invention to have lower retrieval latency and lower retrieval resource consumption. Attached Figure Description

[0015] Figure 1 Include content graphs in the existing permission rules; Figure 2 Flowchart for existing permission checks and execution; Figure 3 Obtain the execution flowchart for existing permissions; Figure 4 Add a flowchart to the permission rules of this invention; Figure 5 This is a flowchart of the permission rule deletion process of the present invention; Figure 6 This is a flowchart of the permission rule retrieval process (permission judgment) of the present invention; Figure 7 This is a flowchart of the permission rule retrieval process (permission acquisition) of the present invention; Figure 8 Example diagram of Alibaba Cloud RAM access control; Figure 9Example diagram for Huawei Cloud's Unified Identity Authentication Service (IAM); Detailed Implementation

[0016] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0017] While using the same storage medium (memory storage) as common permission management schemes, this invention designs a method for building an index of permission rules to improve retrieval efficiency based on the analysis of the permission search process and the analysis of expressions.

[0018] Analysis of the permission retrieval process: Through long-term engineering practice, this invention has found that the authentication center mainly calls the following two types of interfaces: 1. Permission verification and execution flow are as follows: Figure 2 As shown: Given a user, an object, and permissions, determine whether access is granted. The process is as follows: a) By inputting the user, obtain the permission rules that match the user range, and form permission rule set 1; b) By using the input object, obtain the permission rules that match the scope of the object, and form permission rule set 2; c) Take the intersection of set 1 and set 2 to obtain the set that simultaneously satisfies the permission rules. Iterate through this set of permission rules. If there is a permission rule that matches the input permission, determine that the authorization is successful; otherwise, determine that the authorization is unsuccessful. 2. Permission acquisition and execution flow are as follows: Figure 3 As shown: Given a user, retrieve the objects and permissions owned by that user; a) By inputting the user, obtain the permission rules that match the user range, and form permission rule set 1; b) Traverse the permission rule set 1, merge the object scope and permissions of all permission rules, and return the merged result; The core of permission rule search is to "obtain permission rules that match the corresponding user scope or object scope". In Casbin, this step is achieved by traversing all user scope expressions and object scope expressions in all permission rules, evaluating each expression one by one, and thus determining whether the relevant expression meets the requirements. This invention will adopt a more efficient implementation method, as detailed in "Expression Analysis" and "Index-based Permission Rule Management Process".

[0019] Expression analysis: In casbin, the reason why expressions need to be evaluated one by one is as follows: 1. In theory, the expressions for user scope and object scope can be constructed arbitrarily; 2. The actual evaluation process of an expression can generally only be performed when the parameters are given during the actual permission retrieval, and pre-evaluation caching is not possible; for example, prefix(user, 'a') can only be evaluated when user = 'alice' is given. The following permission expression is still used here as an example to illustrate permission rules. 1. User range: prefix(user, 'a'): users whose username starts with 'a' or prefix(user, 'b'): users whose username starts with 'b'; 2. Role: editor; 3. Permissions - Object Scope: read-prefix(object, 'book'): Has read permission for objects whose scope begins with 'book'; write-prefix(object, 'book'): Has write permission for objects whose scope begins with 'book'; read-prefix(object, 'diary'): Has read permission for objects whose scope begins with 'diary' (but no write permission). Algebraically, the expression for the user scope of a permission rule can be abstracted as a conjunctive compound proposition `prefix(user, 'a') || prefix(user, 'b')` consisting of multiple sub-propositions, meaning "users who satisfy these sub-propositions can apply this permission rule." As mentioned earlier, theoretically the expression is arbitrary and cannot be indexed. However, in engineering practice, this invention has found that in most cases, the sub-propositions within a permission rule are atomic propositions. When the user scope consists of multiple atomic propositions, an index can be built for these atomic propositions. For example, `prefix(user, 'a')` and `prefix(user, 'b')` mentioned in the example can implement a radix tree index (a type of ordered index) for `a` and `b`, using the values ​​'a' and 'b' in the expression as index keys to quickly find the corresponding permission rule.

[0020] In practical implementation, this invention addresses atomic propositions commonly encountered in engineering practice by designing the following three types of indexes: ordered index, hash index, and directed acyclic graph index. The following sections will explain the construction logic of each index and the index-based permission rule management process, including the addition, deletion, and retrieval processes.

[0021] Index-based permission rule management process: A user-scoped or object-scoped index consists of two parts: 1. Index Information Extractor: Extracts index information (if any) from the user scope or object scope; 2. Index Data Manager: Based on the index information extracted by the index information extractor, it provides the ability to add, delete, and query permission rules; These two parts work together to manage access rules. The detailed process is as follows: The process for adding permission rules is as follows: Figure 4 As shown: 1. Enter a permission rule to be added, which includes multiple user scopes, one role, multiple permissions, and the corresponding object scopes; 2. Iterate through each user scope of the input permission rules. For each index built for a user scope, attempt to extract index information from the user scope using the index information extractor. 3. If the index information is extracted, add the permission rules to the index through the index data manager; 4. If no index information is retrieved (because "the expression is too complex and is not in conjunctive normal form" or "the index built for the user scope does not cover the relevant expression"), add the permission rule to the "user scope cannot be indexed list"; 5. Traverse each object range of the input permission rules. For each index built for the object range, attempt to extract index information from the object range using the index information extractor. 6. If the index information is extracted, add the permission rules to the index through the index data manager; 7. If no index information is retrieved, add the permission rule to the "Object Range Cannot Be Indexed List"; The process for deleting permission rules is as follows: Figure 5 As shown: 1. Enter a permission rule to be deleted, which includes multiple user scopes, one role, multiple permissions, and the corresponding object scopes; 2. Iterate through each user scope of the input permission rules. For each index built for a user scope, attempt to extract index information from the user scope using the index information extractor. 3. If index information is extracted, delete the permission rules from the index data manager; 4. If no index information is retrieved, remove the permission rule from the "User-scoped Unindexable List"; 5. Traverse each object range of the input permission rules. For each index built for the object range, attempt to extract index information from the object range using the index information extractor. 6. If index information is extracted, delete the permission rules from the index data manager; 7. If no index information is retrieved, remove the permission rule from the "List of Objects That Cannot Be Indexed"; The permission rule retrieval process (permission judgment) is as follows: Figure 6 As shown: 1. Enter user, object, and permissions; 2. For each user-scoped index, retrieve the permission rules in the index data manager based on the index information, denoted as set 1; 3. Iterate through all permission rules in the "user scope cannot be indexed list", evaluate each rule by expression, and obtain the user scope and corresponding permission rule that meet the conditions, denoted as set 2; 4. For each object range index, retrieve the permission rules in the index data manager based on the index information, denoted as set 3; 5. Iterate through all the permission rules in the "List of Objects That Cannot Be Indexed", evaluate each one by the expression, and obtain the object ranges that meet the conditions and the corresponding permission rules, which are denoted as set 4; 6. Take the union of set 1 and set 2 to get the permission rule set 5. Take the union of set 3 and set 4 to get the permission rule set 6. Take the intersection of set 5 and set 6 to get the permission rules that satisfy both user scope and object scope. Traverse this part of the permission rules. If there is a permission rule that matches the input permission, it is determined that the authorization is approved. Otherwise, it is determined that the authorization is not approved. The permission rule retrieval process (permission acquisition) is as follows: Figure 7 As shown: 1. Enter user; 2. For each user-scoped index, retrieve the permission rules in the index data manager based on the index information, denoted as set 1; 3. Iterate through all permission rules in the "user scope cannot be indexed list", evaluate each rule by expression, and obtain the user scope and corresponding permission rule that meet the conditions, denoted as set 2; 4. Take the union of set 1 and set 2 to obtain permission rule set 3. Merge the object scope and corresponding permissions of the permission rules in set 3 and return the merged result. Applicable scenarios and implementation methods of ordered indexes: In the search of permission rules, you might find rules like "Users older than 35 can query information A," where the user range "older than 35" is an atomic proposition involving numerical comparison. If an atomic proposition within a user range or object range involves numerical comparison or lexicographical comparison of strings, an ordered index can be built for that atomic proposition.

[0022] Implementation of an index information extractor for ordered indexes: The index information of an ordered index consists of two parts: the index key and the index range. For different forms of atomic propositions involving comparisons of the size of numbers or lexicographical order of strings, the extracted index information is as follows: For the atomic proposition "the value of variable A is greater than or equal to the value b", extract the index key "value b" and the index range "greater than, equal to"; For the atomic proposition "the value of variable A is greater than the value of b", extract the index key "value of b" and the index range "greater than"; For the atomic proposition "the value of variable A is equal to the value b", extract the index key "value b" and the index range "equal to"; For the atomic proposition "the value of variable A is less than the value of b", extract the index key "value of b" and the index range "less than"; For the atomic proposition "the value of variable A is less than or equal to the value b", extract the index key "value b" and the index range "less than or equal to". The index data manager for an ordered index is implemented using a red-black tree (a typical implementation of an ordered table) to store the index keys in sequence. Each index key's index value includes three sets storing permission rules: "permission rules where the index range is greater than", "permission rules where the index range is equal to", and "permission rules where the index range is less than". The index data manager for an ordered index implements permission rule addition, deletion, and querying as follows: 1. Adding permission rules Based on the extracted index information, the index key is added to the red-black tree, and the permission rules are added to the corresponding set in the index value. For example, when the extracted index range is "greater than or equal to", this permission rule will be added to the "permission rule set with index range greater than" and the "permission rule set with index range equal to".

[0023] 2. Deletion of permission rules Based on the extracted index information, if the index key itself is not in the red-black tree, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the red-black tree, find the corresponding set of index values ​​based on the index range and delete the permission rule from the set. For example, if the extracted index range is "greater than" or "equal to", then try to delete the permission rule from the "permission rule set with index range greater than" and the "permission rule set with index range equal to".

[0024] 3. Permission rule query When a specific user or object is input, the specific attribute value can be extracted as an index value based on the attributes of the input user or object. Let's call it c. Then, search in the red-black tree in the following way: (1) Get the index value with index key c, and extract the "set of permission rules with index range equal to c", which is called set 1; (2) Get all index values ​​with index key less than c, and extract the "set of permission rules with index range greater than c" and take the union, which is called set 2; (3) Get all index values ​​with index key greater than c, and extract the "set of permission rules with index range less than c" and take the union, which is called set 3; take the union of set c1, set 2, and set 3 to get the final set of permission rules. Applicable scenarios and implementation methods of hash indexes: When searching for permission rules, rules like "User ID 1000213 can use function B" will appear. Here, the user scope "User ID 1000213" is an atomic proposition involving numerical equality comparison. If an atomic proposition within a user scope or object scope involves numerical equality comparison, a hash index can be built for that atomic proposition.

[0025] Hash index information extractor implementation: The hash index information only contains a part - the index key. For atomic propositions involving numerical equality comparison, the extracted index information is as follows: For the atomic proposition "variable value A is less than or equal to value b", the index key "value b" is extracted.

[0026] The hash index's index data manager is implemented as follows: A hash table is used to store the index keys in the index information. Each index key's index value consists of a set of permission rules. The hash index's index data manager implements permission rule addition, deletion, and querying as follows: 1. Adding permission rules Based on the extracted index information, the index key is added to the hash table, and the permission rules are added to the permission rule set in the index value.

[0027] 2. Deletion of permission rules Based on the extracted index information, if the index key itself is not in the hash table, it means that the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, the permission rule will be deleted from the permission rule set in the index value.

[0028] 3. Permission rule query When a specific user or object is input, the specific attribute value can be extracted as an index value based on the attributes of the input user or object. Let's say we set it as c. Then, search the hash table in the following way: get the index value with index key c, and extract the set of permission rules from the index value.

[0029] Applicable scenarios and construction process for indexing Directed Acyclic Graphs (DAGs): The following permission rules will appear when searching for permission rules: Searching for permission rules will yield rules like "All users in user group B can use function C," where the user scope of "user group B" is an atomic proposition involving a parent-child nested relationship. Similar nested relationships include, but are not limited to, "the relationship between folders and files in a Windows system" or "the relationship between departments and employees in a company's organizational structure tree." If an atomic proposition within a user scope or object scope involves nested relationships within a directed acyclic graph (DAG), a DAG index can be constructed for that atomic proposition.

[0030] Unlike ordered indexes and hash indexes, the construction of a directed acyclic graph index requires additional input of the parent-child relationships between nodes. The implementation of the index information extractor for a directed acyclic graph (DAG) index is as follows: The index information of a DAG index only contains a part - the index key. For atomic propositions involving numerical equality comparisons, the extracted index information is as follows: For the atomic proposition "all child nodes of the value b", the index key "value b" is extracted.

[0031] The implementation of the index data manager for a directed acyclic graph (DAG) index involves storing the index keys in parent-child order using a DAG. Each index key's index value consists of a set of permission rules. Unlike ordered and hash indexes, the construction of a DAG index requires introducing additional external information, including adding and deleting parent-child relationships between index keys in the DAG. The DAG index data manager implements the following methods for adding and deleting parent-child relationships, adding and deleting permission rules, and querying permission rules: 1. Adding parent-child relationships using index keys Enter two index keys and add them as graph nodes to the directed acyclic graph, recording the connection information (in actual engineering, it is necessary to check whether they form cycles to ensure the validity of the directed acyclic graph).

[0032] 2. Deleting parent-child relationships by index key Enter two index keys and search for whether they exist in the directed acyclic graph. If they do not exist, it means that the parent-child relationship has not been added and does not need to be deleted. If they exist, delete the parent-child relationship.

[0033] 3. Adding permission rules Based on the extracted index information, the index key is added to the directed acyclic graph, and the permission rules are added to the permission rule set in the index value.

[0034] 4. Deletion of permission rules Based on the extracted index information, if the index key itself is not in the directed acyclic graph, it means that the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, the permission rule will be deleted from the permission rule set in the index value.

[0035] 5. Permission rule query When a specific user or object is input, the specific attribute value can be extracted as an index value based on the attributes of the input user or object. Let's say it's c. Then, search in the red-black tree in the following way: (1) Get the index value with index key c, extract the set of permission rules from it, and call it set 1; (2) Traverse the entire directed acyclic graph, get the index values ​​of all child nodes with index key c, extract the set of permission rules from these index values ​​and take the union, and call it set 2; take the union of set 1 and set 2 to get the final set of permission rules. Select the index based on the actual data: In the index construction method proposed in this invention, the actual index construction is highly correlated with the actual permission rule data. In reality, a user or object often has a large number of different attributes, and only a portion of these attributes are used for permission judgment. For example, a user may have the following attributes: ID, department, age, and date of employment. However, in practice, most permission rules only use ID and department for permission judgment. Therefore, based on business analysis, a directed acyclic graph index can be used for ID and department, and indexes do not need to be built for other attributes.

[0036] In addition, if necessary, other index types not mentioned in this method can be used to build indexes. For example, if there are many atomic propositions with prefix matching in the data, a radix tree index can be designed and built.

[0037] In actual engineering practice, indexes can be added gradually based on the data situation, and the system operation can be optimized as the system is used.

[0038] Optimization from other engineering perspectives: If we're not limited to the algorithm itself, from an engineering perspective, we can alleviate the high latency issue in permission rule retrieval and improve the concurrency of permission rule searches from other angles, including but not limited to: 1. Use multiple machine instances to hold all permission rules and jointly handle permission search requests (requires handling more complex engineering issues). 2. Divide the permission rules into segments according to business logic, with each instance only responsible for a portion of the rules (this solution is strongly bound to the business and lacks universality). 3. Utilize the multi-core nature of the machine to concurrently evaluate the expression of the permission rules (this is difficult to implement in practice). It should be noted that the present invention can also benefit from these engineering optimizations.

[0039] Example of using ABAC and RABC in combination: 1. Alibaba Cloud – RAM access control, such as Figure 8 As shown: Permission policy: Corresponds to the role + permission + object scope in this invention; Authorized entity: the user scope corresponding to this invention; 2. Huawei Cloud – Unified Identity Authentication Service (IAM), such as Figure 9 As shown: Permissions: Corresponding to role + permissions + object scope in this article; Authorizing entity: Corresponding to the user scope in this document; Expression explanation: An expression is a string composed of variables, constants, and operators. Generally speaking, for permission rules, both user-scoped and object-scoped expressions are compound propositions that include variables and ultimately evaluate to true or false. Below are some common user-scoped and object-scoped expressions in the field of permission management: 1. User scope: age>30: users are over 30 years old; register_time<'2025-01-01': users registered before January 1, 2025; username == 'alice': users' username is alice; 2. Object scope: tag == 'A' Objects with the tag 'A'; type != 'server' Objects whose type is not 'server'; Expressions can be nested using Boolean operations: for example, age>30&®ister_time<'2025-01-01' represents an expression for someone who is over 30 years old and whose registration date was before January 1, 2025.

[0040] A radix tree, also known as a compressed prefix tree, is a space-saving prefix tree structure primarily used for building associative arrays, IP routing, and inverted indexes in information retrieval. It uses binary bit strings as keys and employs a multi-branch tree structure. Intermediate nodes contain arrays of pointers to their child nodes, while leaf nodes store object pointers. Space compression is achieved by merging single child nodes with their parent nodes.

[0041] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention should be determined by the appended claims.

Claims

1. A method for storing and retrieving permission rules, characterized in that, It includes three types of indexes: ordered indexes, hash indexes, and directed acyclic graph indexes. The process for managing access permissions, adding items, deleting items, and retrieving items based on these indexes is as follows: Index-based permission rule management process: The index for user scope or object scope consists of two parts: Index information extractor: extracts index information from user scope or object scope; Index Data Manager: Based on the index information extracted by the index information extractor, it provides the ability to add, delete, and query permission rules; These two parts work together to jointly manage the access control rules; Permission rule addition process: Input a permission rule to be added, which includes multiple user scopes, one role, multiple permissions, and corresponding object scopes; Iterate through each user scope of the input permission rule, and for each index built for the user scope, attempt to extract index information from the user scope using the index information extractor; If index information is extracted, the permission rules are added to the index through the index data manager; if index information is not extracted, the permission rules are added to the "user scope cannot be indexed list"; iterate through each object scope of the input permission rules, and for each index built for the object scope, try to extract the index information from the object scope through the index information extractor. If the index information is extracted, the permission rules are added to the index through the index data manager; If no index information is retrieved, add the permission rule to the "Object Range Cannot Be Indexed List"; Permission rule deletion process: Input a permission rule to be deleted, which includes multiple user scopes, one role, multiple permissions, and corresponding object scopes; traverse each user scope of the input permission rule, and for each index built for the user scope, attempt to extract index information from the user scope using the index information extractor; If index information is extracted, the permission rule is removed from the index data manager; if no index information is extracted, the permission rule is removed from the "user scope cannot be indexed list"; iterate through each object scope of the input permission rule, and for each index built for the object scope, attempt to extract the index information from the object scope using the index information extractor. If the index information is extracted, the permission rule is deleted from the index data manager; if the index information is not extracted, the permission rule is deleted from the "Object Range Cannot Be Indexed List". In the permission rule retrieval process, permission judgment is performed as follows: Input user, object, permission; For each user scope index, the permission rules are obtained in the index data manager based on the index information, denoted as set X1; Traverse all permission rules in the "user scope cannot be indexed list", evaluate each one through expression to obtain the user scope and corresponding permission rules that meet the conditions, denoted as set X2; For each object scope index, the permission rules are obtained in the index data manager based on the index information, denoted as set X3; Traverse all permission rules in the "object scope cannot be indexed list", evaluate each one through expression to obtain the object scope and corresponding permission rules that meet the conditions, denoted as set X4; Take the union of set X1 and set X2 to obtain permission rule set X5, take the union of set X3 and set X4 to obtain permission rule set X6, take the intersection of set X5 and set X6 to obtain permission rules that simultaneously meet both user scope and object scope requirements, traverse this part of permission rules, if there is a permission rule that matches the input permission, it is judged as authorization passed, otherwise it is judged as authorization failed; In the permission rule retrieval process, permission acquisition is performed as follows: Input user; index each user range, and retrieve permission rules based on the index information in the index data manager, denoted as set Y1; traverse all permission rules in the "user range cannot be indexed list", evaluate each one through expression, and obtain the user range and corresponding permission rule that meet the conditions, denoted as set Y2; take the union of set Y1 and set Y2 to obtain the permission rule set Y3, merge the object range and corresponding permissions of the permission rules in set Y3, and return the merged result.

2. The method for storing and retrieving permission rules according to claim 1, characterized in that, Applicable scenarios and implementation methods of ordered indexes: Applicable scenarios: In the search of permission rules, if an atomic proposition within a user scope or object scope involves comparing the size of numbers or comparing the lexicographical order of strings, an ordered index can be built for that atomic proposition; Index information extractor implementation: The index information of an ordered index consists of two parts: the index key and the index range, for different forms of atomic propositions involving comparison of the size of numbers or lexicographical comparison of strings; The index data manager is implemented as follows: a red-black tree is used to store the index keys in the index information in order. The index value of each index key includes three sets of permission rules: "the set of permission rules with the index range greater than", "the set of permission rules with the index range equal to", and "the set of permission rules with the index range less than". The Index Data Manager implements permission rule addition, deletion, and query as follows: Permission rule addition: Based on the extracted index information, the index key is added to the red-black tree, and the permission rule is added to the corresponding set in the index value; Permission rule deletion: Based on the extracted index information, if the index key itself is not in the red-black tree, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the red-black tree, find the corresponding set of index values ​​based on the index range and delete the permission rule from the set. Permission rule query: When a specific user or object is input, the specific attribute value can be extracted as the index value based on the input user or object's attributes. The index value is set as c, and the red-black tree is searched in the following way: Get the index value with index key c, and extract the "permission rule set with index range equal to c", denoted as set c1; Get all index values ​​with index key less than c, and extract the "permission rule set with index range greater than c" and take the union, denoted as set c2; Get all index values ​​with index key greater than c, and extract the "permission rule set with index range less than c" and take the union, denoted as set c3; Take the union of sets c1, c2, and c3 to obtain the final permission rule set.

3. The method for storing and retrieving permission rules according to claim 1, characterized in that, Applicable scenarios and implementation methods of hash indexes: Applicable scenario: In the search of permission rules, if an atomic proposition within a user scope or object scope involves a comparison of numerical equality, a hash index can be built for that atomic proposition; Index information extractor implementation: The index information of a hash index only contains a part - the index key, for atomic propositions involving numerical equality comparisons; The implementation of the hash index's index data manager involves using a hash table to store the index keys in the index information. Each index key's index value includes a set of permission rules. The hash index's index data manager implements permission rule addition, deletion, and querying as follows: Adding permission rules: Based on the extracted index information, add the index key to the hash table and add the permission rules to the permission rule set in the index value; Permission rule deletion: Based on the extracted index information, if the index key itself is not in the hash table, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, the permission rule is deleted from the permission rule set in the index value. Permission rule query: When a specific user or object is entered, the specific attribute value can be extracted as the index value based on the attributes of the entered user or object. The index value is set as 'a', and the hash table is searched in the following way: the index value with index key 'a' is obtained, and the permission rule set is extracted from the index value.

4. The method for storing and retrieving permission rules according to claim 1, characterized in that, Applicable scenarios and implementation methods for directed acyclic graphs: Applicable scenario: In the search of permission rules, if an atomic proposition in a user scope or object scope involves nested relationships in a directed acyclic graph, a directed acyclic graph index can be built for that atomic proposition; Index information extractor implementation: The index information of a directed acyclic graph index only contains a part - the index key, for atomic propositions involving numerical equality comparisons; The index data manager is implemented by using a directed acyclic graph (DAG) to store the index keys in the index information in parent-child order. The index value of each index key includes a set of permission rules. The construction of the DAG index also requires the introduction of additional external information, including adding and deleting parent-child relationships between the index keys in the DAG. The Index Data Manager implements the following methods for adding, deleting, adding, deleting, and querying parent-child relationships of index keys: Adding a parent-child relationship: Input two index keys and add them as graph nodes to the directed acyclic graph, recording the connection information; Deleting a parent-child relationship: Input two index keys and search for their existence in the directed acyclic graph. If they do not exist, the parent-child relationship has not been added and does not need to be deleted; if they exist, the parent-child relationship is deleted; Adding a permission rule: Based on the extracted index information, add the index keys to the directed acyclic graph and add the permission rules to the permission rule set in the index value. Permission rule deletion: Based on the extracted index information, if the index key itself is not in the directed acyclic graph, it means the permission rule has not been added and does not need to be deleted. If the index key itself is in the hash table, the permission rule is deleted from the permission rule set in the index value. Permission rule query: When a specific user or object is input, the specific attribute value can be extracted as the index value based on the attributes of the input user or object. The index value is set as b, and the red-black tree is searched in the following way: Get the index value with index key b, extract the permission rule set from it, and denot it as set b1; Traverse the entire directed acyclic graph, get the index values ​​of all child nodes with index key b, extract the permission rule set from these index values ​​and take the union, denoted as set b2; Take the union of set b1 and set b2 to obtain the final permission rule set.

5. The method for storing and retrieving permission rules according to claim 1, characterized in that, Select indexes based on actual data conditions: For a user or object, there are many different attributes, and only some of these attributes are used for permission judgment. Based on the analysis of business, use indexes for some attributes and do not need to build indexes for others; add indexes gradually according to the data conditions, without completing the index configuration all at once, but gradually completing the index configuration as the system is used; select indexes based on data format and atomic proposition form.

6. The method for storing and retrieving permission rules according to claim 2, characterized in that, In the implementation of the ordered index information extractor, for atomic propositions involving comparison of the size of numbers or lexicographical comparison of strings, the extracted index information is as follows: For the atomic proposition "variable value A is greater than or equal to value b", the extracted index key is "value b", and the index range is "greater than" or "equal to"; For the atomic proposition "variable value A is greater than value b", the extracted index key is "value b", and the index range is "greater than"; For the atomic proposition "variable value A is equal to value b", the extracted index key is "value b", and the index range is "equal to"; For the atomic proposition "variable value A is less than value b", the extracted index key is "value b", and the index range is "less than"; For the atomic proposition "variable value A is less than or equal to value b", the extracted index key is "value b", and the index range is "less than" or "equal to".

7. The method for storing and retrieving permission rules according to claim 3, characterized in that, In the implementation of the hash index information extractor, for atomic propositions involving numerical equality comparisons, the extracted index information is as follows: for the atomic proposition "variable value A is less than or equal to value b", the index key "value b" is extracted.

8. The method for storing and retrieving permission rules according to claim 4, characterized in that, In the implementation of the index information extractor for directed acyclic graph indexes, for atomic propositions involving numerical equality comparisons, the extracted index information is as follows: for the atomic proposition "all child nodes of value b", the index key "value b" is extracted.

Images