Algorithm for api authority control

Abstract

The invention discloses an algorithm for api authority control. The algorithm comprises the following steps: collecting user attributes in an API request; verifying the integrity and validity of the collected user attributes; matching the verified user attribute with a pre-stored access control policy to determine an applicable policy; based on the matched strategy, the access authority of the user to the requested API is evaluated, and a permission or rejection decision is generated; and executing the decision, and performing audit recording on the access attempt. Attribute-based access control is adopted to allow dynamic adjustment of access strategies according to wide conditions such as places and time, the method is more suitable for complex and dynamic environments, the algorithm provides clear strategy matching and authority evaluation processes, and a system administrator is helped to understand and manage access control rules more easily.

Description

Technical Field

[0001] The present invention relates to the field of information security, and in particular to an algorithm for API permission control. Background Art

[0002] With the rapid development of information technology, especially the popularity of cloud computing and mobile applications, a system that can effectively manage and control large-scale dynamic access requests is needed. Existing access control mechanisms usually rely on static permission lists or role definitions, which perform poorly when dealing with complex or highly changing access requirements.

[0003] In addition, traditional audit systems usually process events after they occur, which limits their effectiveness in preventing security risks and responding in a timely manner. Therefore, there is a need for technology that improves access control performance, flexibility, and audit capabilities. Summary of the invention

[0004] The purpose of the present invention is to provide an algorithm for API permission control to solve the problems raised in the above background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] An algorithm for API permission control includes the following steps:

[0007] Step S1, collecting user attributes in the API request;

[0008] Step S2, verifying the integrity and validity of the collected user attributes;

[0009] Step S3, matching the verified user attributes with the pre-stored access control policies to determine the applicable policy;

[0010] Step S4, based on the matched policy, evaluate the user's access rights to the requested API and make a decision of permission or rejection;

[0011] Step S5, execute the above decision and audit the access attempt.

[0012] Furthermore, in step S1, collecting user attributes in the API request further includes extracting timestamp and geographic location information from the API request as user attributes.

[0013] Furthermore, in step S2, the verification collection further includes confirming whether the user ID exists in the system.

[0014] Furthermore, in step S3, the policy matching uses a role-based access control (RBAC) model.

[0015] Furthermore, in step S4, the evaluation includes applying at least one logical rule to process the matched policy.

[0016] Furthermore, in step S4, the logic rule includes the principle of least privilege.

[0017] Furthermore, in step S5, the audit record includes recording the time, operator, operation type and result of the access decision.

[0018] A control system for an API permission control algorithm, including

[0019] An attribute collector, the attribute collector is used to collect user attributes from API requests;

[0020] An attribute verifier, the attribute verifier is used to verify the integrity and validity of the user attributes collected by the attribute verifier;

[0021] A policy matcher, the policy matcher is used to match the user attributes verified by the attribute verifier with a pre-stored access control policy;

[0022] A permission evaluator, the permission evaluator is used to evaluate and generate a decision on access rights based on the matched policy;

[0023] An executor is used to execute the access permission decision and record the audit log.

[0024] Furthermore, the attribute collector is further configured to extract the timestamp and geographic location information of the request.

[0025] Further, the permission evaluator applies the principle of least privilege to evaluate access rights.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] 1. The present invention adopts attribute-based access control to allow dynamic adjustment of access policies according to a wide range of conditions, such as location, time, etc., which is more adaptable to complex and dynamic environments. The algorithm provides a clear policy matching and permission evaluation process, helping system administrators to understand and manage access control rules more easily;

[0028] 2. The present invention reduces unnecessary data processing through efficient attribute collection and verification processes, thereby maintaining high performance when facing large-scale user access, real-time audit record generation and storage, and providing better monitoring and event response capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a schematic diagram of an algorithm flow of an API permission control of the present invention;

[0030] Figure 2 This is a schematic diagram of the control system structure of an API permission control according to the present invention. DETAILED DESCRIPTION

[0031] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0032] Embodiment 1

[0033] See also Figure 1 , the present invention provides a technical solution:

[0034] An algorithm for API permission control includes the following steps:

[0035] Step S1, collecting user attributes in the API request;

[0036] Preferably, collecting user attributes in the API request further includes extracting timestamp and geographic location information from the API request as user attributes.

[0037] In this step, the attribute collection function is used to collect user attributes from the API request:

[0038] Function expression:

[0039] collectAttributes(request)

[0040] The input parameter: request represents the API request object, which specifically includes the data submitted by the user and the request metadata;

[0041] Output: Returns a dictionary of attributes, including user ID, timestamp, and geographic location.

[0042] The operation logic is as follows:

[0043]

[0044]

[0045] Step S2, verifying the integrity and validity of the collected user attributes;

[0046] Preferably, verifying the collection further includes confirming whether the user ID exists in the system.

[0047] In this step, the attribute verification function is used to verify the integrity and validity of the collected user attributes;

[0048] Function expression:

[0049] validateAttributes(attributes)

[0050] Among them, the input parameter: attributes represents the attribute dictionary collected from the collectAttributes function.

[0051] Output: Boolean value, indicating whether the verification passed.

[0052] The operation logic is as follows:

[0053] valid=(attributes['user_id']is notNone and

[0054] attributes['timestamp']is notNone and

[0055] attributes['location']is notNone).

[0056] Step S3, matching the verified user attributes with the pre-stored access control policies to determine the applicable policy;

[0057] Preferably, the policy matching uses a role-based access control (RBAC) model.

[0058] In this step, the policy matching function is used to match the verified user attributes with the pre-stored access control policy;

[0059] Function expression:

[0060] matchPolicy(attributes,policies)

[0061] Among them, the input parameters: attributes represent the verified user attribute dictionary; policies represent the access control policy list predefined in the system.

[0062] Output: List of matched policies.

[0063] The operation logic is as follows:

[0064] matched_policies=[policy for policy in policies if policy['role']==attributes['user_id']].

[0065] Step S4, based on the matched policy, evaluate the user's access rights to the requested API and make a decision of permission or rejection;

[0066] Preferably, evaluating comprises applying at least one logic rule to process the matched policies.

[0067] Furthermore, the logic rules include the principle of least privilege.

[0068] In this step, the permission evaluation function is used to record the audit log of access attempts;

[0069] Function expression:

[0070] evaluateAccess(matched_policies)

[0071] The input parameter: matched_policies represents the matched policy list from the matchPolicy function.

[0072] Output: Access decision, either "allow" or "deny".

[0073] The operation logic is as follows:

[0074] decision="allow"if any(policy['access']=='allow'for policy inmatched_policies)else"deny".

[0075] Step S5, execute the above decision and audit the access attempt.

[0076] Preferably, in step S5, the audit record includes recording the time, operator, operation type and result of the access decision.

[0077] In this step, the audit record function is used to record the audit log of the access attempt;

[0078] Function expression:

[0079] auditAccess(decision,user_id,request)

[0080] Among them, the input parameters: decision represents the access decision from evaluateAccess, user_id represents the user ID, and request represents the API request object.

[0081] Output: No return value, but audit information will be written to the log system.

[0082] The operation logic is as follows:

[0083]

[0084] append_to_log(log).

[0085] like Figure 2 As shown, a control system of an API permission control algorithm includes:

[0086] An attribute collector, the attribute collector is used to collect user attributes from API requests;

[0087] Preferably, the attribute collector is further configured to extract timestamp and geographic location information of the request.

[0088] In this embodiment, the main function of the attribute collector is to extract the basic attributes of the user from the API request, including the user ID, timestamp and geographic location information;

[0089] Specifically, at runtime, the API request object is input and the attribute dictionary containing the user ID, timestamp, and geographic location is output. The necessary data is collected by directly accessing the attributes of the request object.

[0090] For example, for an HTTP request, this information can be extracted from the HTTP header or URL parameters;

[0091]

[0092] An attribute verifier, the attribute verifier is used to verify the integrity and validity of the user attributes collected by the attribute verifier;

[0093] In this embodiment, the attribute validator is used to check whether the collected user attributes are complete and valid, ensuring that each required attribute has been correctly collected and conforms to the expected format or value;

[0094] Specifically, at runtime, the attribute dictionary is input and a Boolean value is output, indicating whether the attribute is valid; basic non-null checks are performed, and further verifications can be made, such as whether the user ID exists in the database, whether the timestamp is within a reasonable time range, etc.

[0095]

[0096] A policy matcher, the policy matcher is used to match the user attributes verified by the attribute verifier with a pre-stored access control policy;

[0097] In this embodiment, the policy matcher matches the authenticated user attributes with the pre-stored access control policies to determine the applicable policy;

[0098] Specifically, at runtime, a verified user attribute dictionary and a list of access control policies predefined in the system are input, and a list of matched policies is output, using a role-based access control (RBAC) model to match the user's role with the role defined in the policy;

[0099] defmatchPolicy(attributes,policies):

[0100] matched_policies=[policy for policy in policies if policy['role']==attributes['user_id']]

[0101] return matched_policies

[0102] A permission evaluator, the permission evaluator is used to evaluate and generate a decision on access rights based on the matched policy;

[0103] Preferably, the permission evaluator applies the principle of least privilege to evaluate access rights;

[0104] In this embodiment, the permission evaluator evaluates and generates access rights decisions based on the matched policies, applying the principle of least privilege.

[0105] Specifically, at runtime, a list of matched policies is input and an access decision is output, which can be "allow" or "deny". If any of the matched policies allows access, then it is allowed, otherwise it is denied.

[0106] defevaluateAccess(matched_policies):

[0107] decision="allow"if any(policy['access']=='allow'for policy inmatched_policies)else"deny"

[0108] return decision

[0109] An executor is used to execute the access permission decision and record the audit log.

[0110] In this embodiment, the executor is used to execute the access permission decision and record the audit log.

[0111] Specifically, during runtime, the input is the access decision, user ID, and API request object. The output has no return value, but the audit information will be written to the log system; the result of the access attempt, user ID, timestamp, and requested resources are recorded in the log.

[0112]

[0113] append_to_log(log)

[0114] It can be understood that through the above control system, the permission control algorithm ensures that only users who meet the policy requirements can access specific API resources, while maintaining transparency and traceability of access attempts through auditing.

[0115] Based on the algorithm and control system of API permission control, the derivation process in the specific embodiment is as follows:

[0116] Suppose, a user sends an API request to obtain sensitive data. First, the control system collects the user attributes of this request.

[0117] Specifically, it extracts the user ID, request time, and geographic location from the API request, and then stores these values ​​in a dictionary and returns it.

[0118] The execution formula is as follows:

[0119]

[0120] After collecting user attributes, the next step is to verify the integrity and validity of these attributes.

[0121] Specifically, it checks whether user_id, timestamp, and location exist and are valid. If all attributes are valid, it returns True; otherwise, it returns False.

[0122] The execution formula is as follows:

[0123] valid=(attributes['user_id']is notNone and

[0124] attributes['timestamp']is notNone and

[0125] attributes['location']is notNone)

[0126] After verification, the user's attributes are matched with the access control policy.

[0127] Specifically, it searches for the corresponding access control policy based on the user's role (e.g., inferred from the user_id in the attributes), and then returns a list of matching policies.

[0128] The execution formula is as follows:

[0129] matched_policies=[policy for policy in policies if policy['role']==attributes['user_id']]

[0130] Evaluate whether the user has permission to access the requested resource based on the matched policy.

[0131] Specifically, it checks whether any of the matched policies allow access. If at least one policy allows access, the decision is "allow"; otherwise, it is "deny".

[0132] The execution formula is as follows:

[0133] decision="allow"if any(policy['access']=='allow'for policy inmatched_policies)else"deny"

[0134] Finally, we need to log the details of every access attempt, regardless of the outcome.

[0135] Specifically, a log record containing the user ID, decision result, timestamp, and requested resource is created and stored in the system log.

[0136] The execution formula is as follows:

[0137]

[0138] append_to_log(log).

[0139] Embodiment 2

[0140] Assume that access control is implemented in an online library management system. A user submits a book access request through the library website. The system needs to verify the user's permissions to confirm whether the user can view or borrow a specific book. The following is a specific implementation example:

[0141] Step 1: Collect attributes:

[0142] The user requests to read a book titled "Basics of Machine Learning". The library management system verifies whether the user has permission to read the book based on the API request sent by the user, which contains his ID and the requested book information.

[0143] Request data:

[0144] user_id: 123456;

[0145] book_title: "Foundations of Machine Learning";

[0146] Function call:

[0147]

[0148] Step 2: Verify the properties:

[0149] Checks that the requested attributes are complete.

[0150] Verification logic:

[0151] valid=attributes['user_id']is notNone and attributes['book_title']isnotNone

[0152] Step 3: Strategy matching

[0153] The policy stored in the system states that only students majoring in data science can access "Fundamentals of Machine Learning".

[0154] Storage strategy:

[0155] Role: "Data Science Student"

[0156] Allowed books: [“Foundations of Machine Learning”, “Statistical Learning Methods”, “Deep Learning”];

[0157] User Information:

[0158] user_id: 123456

[0159] Role: "Data Science Student"

[0160] Matching strategy:

[0161] user_role = "Data Science Student" # This is usually obtained from the database based on the user_id query

[0162] matched_policies=[policy for policy in policies ifpolicy['role']==user_role and attributes['book_title']in policy['allowed_books']]

[0163] Step 4: Permission assessment:

[0164] Based on the matched policy, determine whether the user has the right to access the book.

[0165] Decision logic:

[0166] Python

[0167] decision="allow"ifany(matched_policies)else"deny"

[0168] Step 5: Audit records:

[0169] Logs details of access attempts.

[0170] Audit records:

[0171]

[0172] append_to_log(log)

[0173] Result: If the decision is "allow", the system will allow the user to access "Foundations of Machine Learning"; if it is "deny", the user will not be able to access the book.

[0174] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0175] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. An algorithm for API permission control, characterized in that: The following steps are involved: Step S1, collecting user attributes in the API request; Step S2, verifying the integrity and validity of the collected user attributes; Step S3, matching the verified user attributes with the pre-stored access control policies to determine the applicable policy; Step S4, based on the matched policy, evaluate the user's access rights to the requested API and make a decision of permission or rejection; Step S5, execute the above decision and audit the access attempt.

2. According to claim 1, an API permission control algorithm is characterized by: In the step S1, collecting user attributes in the API request further includes extracting timestamp and geographic location information from the API request as user attributes.

3. According to the algorithm of an API permission control according to claim 1, it is characterized in that: In step S2, the verification collection further includes confirming whether the user ID exists in the system.

4. According to claim 1, an API permission control algorithm is characterized in that: In step S3, the policy matching uses the role-based access control (RBAC) model.

5. According to claim 1, an API permission control algorithm is characterized in that: In step S4, the evaluation includes applying at least one logical rule to process the matched policy.

6. According to claim 1, an API permission control algorithm is characterized by: In step S4, the logic rule includes the principle of least privilege.

7. The algorithm for API permission control according to claim 1 is characterized in that: In step S5, the audit record includes recording the time, operator, operation type and result of the access decision.

8. A control system for an API permission control algorithm according to claims 1-7, characterized in that: include An attribute collector, the attribute collector is used to collect user attributes from API requests; An attribute verifier, the attribute verifier is used to verify the integrity and validity of the user attributes collected by the attribute verifier; A policy matcher, the policy matcher is used to match the user attributes verified by the attribute verifier with a pre-stored access control policy; A permission evaluator, the permission evaluator is used to evaluate and generate a decision on access rights based on the matched policy; An executor is used to execute the access permission decision and record the audit log.

9. The control system of the algorithm for API permission control according to claim 8, characterized in that: The attribute collector is further configured to extract timestamp and geographic location information of the request.

10. The control system of the algorithm for API authority control according to claim 8, characterized in that: The permission evaluator applies the principle of least privilege to evaluate access rights.

Images