Dynamic permission control api execution method, device and storage medium

Abstract

The present disclosure relates to an API execution method, device and storage medium for dynamic permission control, the API execution method comprising: receiving an API request sent by a user, and performing permission verification on the API request; in response to the permission verification failing, evaluating the risk of the API request; in response to the evaluation result of the risk meeting a threshold, issuing a dynamic temporary permission; and completing the API request according to the dynamic temporary permission.

Description

Technical Field

[0001] This disclosure relates to the field of data management, and in particular to a method, apparatus, electronic device, storage medium, and program product for executing an application programming interface (API) with dynamic access control. Background Technology

[0002] An Application Programming Interface (API) is a tool for enabling functional collaboration and data exchange between different programs or databases. Through API interface definitions, developers and users can easily call or read functions or data from other programs or databases, reducing the overall complexity of the system and thus lowering development difficulty and costs.

[0003] To ensure the security of interactions between programs or databases, it's necessary to restrict the specific content that each request can access or modify. This is known as API access control, ensuring that each access is limited to the content that the requested object is allowed to access. Currently, API request authorization and execution are often achieved by granting appropriate permissions to each requested object. Summary of the Invention

[0004] A brief overview of this disclosure is given below to provide a basic understanding of some aspects of it. However, it should be understood that this overview is not an exhaustive summary of this disclosure. It is not intended to identify key or essential parts of this disclosure, nor is it intended to limit the scope of this disclosure. Its purpose is merely to present certain concepts of this disclosure in a simplified form as a prelude to the more detailed description that follows.

[0005] According to a first aspect of this disclosure, a method for executing an application programming interface (API) with dynamic access control is provided, comprising: receiving an API request sent by a user and performing access control on the API request; assessing the risk of the API request in response to the access control failing; granting dynamic temporary access in response to the risk assessment result meeting a threshold; and completing the API request based on the dynamic temporary access control.

[0006] In some embodiments, assessing the risk of an API request includes integrating a mechanism for risk strategy assessment, behavioral analysis and judgment, and state management control to generate assessment results.

[0007] In some embodiments, risk policy assessment includes: configuring a policy rule base for permission risks to score API requests for risk, wherein the rule base includes at least one of the following: API request operation sensitivity, field sensitivity, time window, access geolocation anomaly, and user's system and role matching degree.

[0008] In some embodiments, the rule base is context-aware and maintains the real-time nature of risk policy rules through dynamic loading and updating.

[0009] In some embodiments, the behavior analysis judgment includes: constructing a behavior profile based on the user's past behavior; and using behavior consistency calculation to determine whether the API request conforms to the behavior profile.

[0010] In some embodiments, determining whether an API request conforms to a behavioral profile includes: in response to an API request not conforming to a behavioral profile, displaying an increased risk level in the assessment results.

[0011] In some embodiments, state management control includes generating a unique ID for an API request and entering it into a state machine to control the lifecycle of the API request.

[0012] In some embodiments, lifecycle control includes ensuring consistency of results when an operation corresponding to an API request is retried, through idempotency flags and execution path records.

[0013] In some embodiments, in response to the risk assessment result meeting the threshold, granting dynamic temporary permissions includes: determining the authorization duration and scope of the dynamic temporary permissions based on the principle of least privilege.

[0014] In some embodiments, completing an API request based on dynamic temporary permissions includes: generating a temporary authorization token based on the dynamic temporary permissions; and automatically retrying the API request using the temporary authorization token.

[0015] In some embodiments, generating a unique ID for an API request and automatically retrying the API request includes: checking whether the API request is being processed repeatedly based on the unique ID; and automatically retrying the API request in response to the absence of repeated processing.

[0016] In some embodiments, using a state machine to monitor API requests and caching the context of API requests, checking whether an API request is being processed repeatedly includes determining whether an API request is being processed repeatedly based on a unique ID, the state machine, and the context.

[0017] In some embodiments, a maximum number of retries and a time interval are preset for automatic retries.

[0018] In some embodiments, completing an API request based on dynamic temporary permissions further includes: converting the API request into an operation instruction for the database.

[0019] According to a second aspect of this disclosure, an application programming interface (API) server apparatus with dynamic access control is provided, comprising: a network interface module configured to receive API requests sent by a user; a verification module configured to perform access control verification on the API requests; a dynamic authorization module configured to assess the risk of the API request in response to a failed access control verification, and to issue dynamic temporary access control in response to a risk assessment result meeting a threshold; and an operation module configured to complete the API request based on the dynamic temporary access control.

[0020] In some embodiments, the dynamic authorization module includes a risk assessment module, a behavior pattern assessment module, and a status management module.

[0021] According to a third aspect of this disclosure, a computing device is provided, comprising: a memory; and a processor coupled to the memory, configured to execute the API execution method of any of the foregoing embodiments based on a computer program stored in the memory.

[0022] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided, including computer program instructions, wherein the computer program instructions, when executed by a processor, implement the API execution method of any of the foregoing embodiments.

[0023] According to a fifth aspect of this disclosure, a computer program product is provided, including computer program instructions that, when executed by a processor, implement the API execution method of any of the foregoing embodiments.

[0024] Other features and advantages of this disclosure will become clearer from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0025] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the specification, serve to explain the principles of this disclosure.

[0026] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein:

[0027] Figure 1 A flowchart of an API execution method with dynamic permission control according to an embodiment of the present disclosure is shown;

[0028] Figure 2 A schematic diagram of an API execution method with dynamic permission control according to an embodiment of the present disclosure is shown;

[0029] Figure 3 An example block diagram of an API server apparatus for dynamic permission control according to an embodiment of the present disclosure is shown;

[0030] Figure 4 A schematic diagram of the data flow of an API server apparatus for dynamic permission control according to an embodiment of the present disclosure is shown;

[0031] Figure 5 An exemplary block diagram is shown that can implement a computing device according to embodiments of the present disclosure;

[0032] Figure 6 An exemplary configuration of a computing device that can implement embodiments of the present disclosure is shown.

[0033] Note that in the embodiments described below, the same reference numerals are sometimes used across different figures to denote the same parts or parts having the same function, and repeated descriptions are omitted. In this specification, similar reference numerals and letters are used to denote similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0034] For ease of understanding, the positions, dimensions, and extents of the structures shown in the accompanying drawings and other materials may not represent actual positions, dimensions, and extents. Therefore, the disclosed invention is not limited to the positions, dimensions, and extents disclosed in the accompanying drawings and other materials. Furthermore, the drawings are not necessarily drawn to scale, and some features may be enlarged to show details of specific components. Detailed Implementation

[0035] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0036] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use. Those skilled in the art will understand that they merely illustrate exemplary ways that can be used to implement this disclosure, and are not exhaustive.

[0037] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0038] The inventors noted that current API request authorization mechanisms are typically static. APIs operate based on pre-defined permission settings, and when additional permission requests are added temporarily, these requests can only be rejected, requiring administrators to manually update them. Similarly, if permission verification fails, the current task must be terminated, and the user must resubmit the request. This results in a waste of time and resources.

[0039] To address the aforementioned issues, this disclosure proposes a dynamic permission control method for API execution.

[0040] In exemplary embodiments of this disclosure, such as Figure 1 As shown, the API execution method with dynamic permission control may include: in step S100, receiving an API request sent by a user and performing permission verification on the API request; in step S110, in response to the permission verification failing, assessing the risk of the API request; in step S120, in response to the risk assessment result meeting the threshold, issuing dynamic temporary permission; and in step S130, completing the API request based on the dynamic temporary permission.

[0041] In some embodiments, upon receiving an API request from a user, information such as the user's identity token, calling system ID, target database identifier, operation type, request parameters, source IP, and operation history can be extracted. Specifically, the target database identifier can include any object in the database that is being accessed, such as tables, views, columns, indexes, triggers, procedures, constraints, and rules. The operation type can include actions such as create, add, delete, modify, query, and read. Request parameters can include path parameters and query parameters. After receiving the API request, permissions can be verified using this data.

[0042] In some specific embodiments, the legitimacy of the user and the request itself can be verified in step S100 to prevent unauthorized access and abuse. In a non-limiting embodiment, unauthorized access includes, but is not limited to, requests for non-existent data; or clearly malicious access, such as using an IP address associated with a Trojan program or using a distributed denial-of-service attack. Abuse includes repeatedly submitting access requests, which can directly return an error message without proceeding to subsequent steps.

[0043] In some specific embodiments, API permission verification and authorization can be performed using a multi-dimensional rule-based calculation. These multi-dimensional rules can include both attribute-based (ABAC) rules and role-based (RBAC) rules. RBAC uses predefined roles, each carrying a set of permissions associated with its role; different roles can have different access levels and types. ABAC, on the other hand, comprehensively judges permissions based on a combination of conditions from one or more attributes in the request submission method or content. For example, in some specific embodiments, the dimensions of the multi-dimensional rules can include user dimension, role dimension, system dimension, request context dimension, database dimension, database object dimension, operation type dimension, etc.

[0044] In specific embodiments, the user dimension may include user ID, organization ID, and department code. Rules governing the user dimension can determine user identity and organizational affiliation, enabling hierarchical access control for users. For example, if the organization ID and department code are "Finance Department," then finance-related data in the database can be accessed, and therefore, authorization can be granted when the requested content is financial data.

[0045] In specific embodiments, the role dimension may include role identifiers, permission groups, role hierarchy and inheritance relationships, role permission mapping rules, etc. Through the rules of the role dimension, authorization strategies can be matched based on roles, combined with role inheritance or mapping control functions and resource access boundaries. For example, if the role identifier or permission group is administrator, lower-level permissions can be granted, allowing the administrator to operate on the underlying data.

[0046] In specific embodiments, the system dimension may include system code, call source ID, etc. Rules at the system dimension can control the legitimacy of the system source for interface calls, preventing unauthorized cross-system calls. For example, for a request from an administrator from a task scheduling system to retrieve underlying data from the financial system, although the administrator role has permission to access the underlying data, administrator-level permissions may not be granted in systems outside their own jurisdiction to ensure data security.

[0047] In specific embodiments, the request context dimension may include time windows, IP address ranges, device types, etc. By using rules at the context dimension, the spatiotemporal environment and terminal characteristics of the request can be limited, enhancing dynamic access control capabilities. For example, for requests submitted outside of working hours, or using networks outside the company, or from unfamiliar devices, due to the lower security of the time range or request source, only lower-level permissions can be granted to ensure the security of important data.

[0048] In specific embodiments, the database dimension may include database type, instance ID, target address, etc. Rules at the database dimension can specify the target database type and specific address, enabling cross-database type access control. For example, confidential and non-confidential databases may have different permission requirements; authorization can be granted only to non-confidential databases.

[0049] In specific embodiments, the data object dimension can include database names, table names, field names, etc. Rules governing the data object dimension can control access permissions to specific database objects, achieving fine-grained authorization at the object level. For example, even within the same database, different types of data may have different security levels; authorization can be granted only to more publicly accessible data, while sensitive data can be left unauthorized.

[0050] In specific embodiments, the operation type dimension can include Structured Query Language (SQL) operation types, such as Data Manipulation Language (DML), Data Definition Language (DDL), Data Control Language (DCL), and Data Query Language (DQL), with core commands such as SELECT, UPDATE, and CREATE TABLE. Rules governing the operation type dimension can control the types of database operations a user can perform, distinguishing between data read / write, structural changes, and access control. For example, access permissions and data creation / deletion permissions may have different requirements, allowing ordinary users to have only access permissions but not the ability to create or delete data.

[0051] It should be understood that, based on the preset verification conditions, for API requests that have passed the permission verification, the corresponding data processing or operation request can be completed directly based on the part or all of the API request that has passed the permission verification.

[0052] In step S110, in response to the failure of the permission verification, the risk of the API request is assessed.

[0053] In some embodiments, mechanisms for risk strategy assessment, behavioral analysis and judgment, and state management control can be integrated to generate assessment results for API requests.

[0054] In some embodiments, risk policy assessment may include configuring a policy rule base for permission risks to score API requests, wherein the rule base includes at least one of the following: API request operation sensitivity, field sensitivity, time window, access geolocation anomaly, and user's system and role matching degree. Through the policy rule base, the risk of specific API requests can be assessed to obtain a risk score, making it less likely that higher-risk API requests will be authorized.

[0055] Specifically, regarding operational sensitivity, accessing data can be considered less sensitive than adding or deleting data, thus being assessed as having lower risk. Regarding field sensitivity, accessing internal confidential data (such as personal identification information, financial fields, etc.) can be considered more sensitive than accessing publicly available data, thus being assessed as having higher risk. Regarding time windows, periods of normal business operations can be defined as lower-risk periods, while periods outside of normal business operations can be defined as higher-risk periods. Regarding the anomaly of access location, areas geographically close to the business location can be considered lower-risk areas, while areas geographically far from the business location can be considered higher-risk areas. Regarding the matching degree between the user's system and role, if the data the user requests belongs to their own system or is closely matched to their role, it is considered lower-risk. For example, a request from a human resources system to access the identity information of all employees is a matching request and therefore has lower risk.

[0056] In some embodiments, the rule base can also be context-aware and maintain the real-time nature of risk policy rules through dynamic loading and updating. Specifically, if a user's behavior before and after the current API request includes other actions that increase permission reliability or has corresponding logic, the user's request can be considered more reasonable, thus judging the risk to be low. For example, if context analysis of user behavior shows that the user previously successfully logged into an internal system, or queried low-risk content directly related to the current request, the API request can be judged to have a low risk.

[0057] Additionally, since database management changes in real time, dynamically loading and updating the rule base can address changing permission requirements. For example, in a non-limiting embodiment, data that was originally considered trade secrets may no longer be important, or some newly added data may require additional confidentiality. Changes in these data rules and their parameters can be reflected in the rule base through dynamic loading and updating, thereby maintaining the real-time nature of the rules and preventing the leakage of data with high permission requirements and / or difficulties in accessing data with low permission requirements. At least one of the above-mentioned policy sets is used to assess the user's API requests to obtain a preliminary risk score.

[0058] Furthermore, in some embodiments, behavioral analysis and judgment may include: constructing a behavioral profile based on the user's past behavior; and employing behavioral consistency calculation to determine whether the API request conforms to the behavioral profile. In a non-limiting embodiment, it can be determined whether the user has submitted related, identical, or similar requests multiple times within a past period (e.g., 30 days). If such requests have been submitted, it indicates that the user has relevant data access needs, and the current request conforms to their behavioral profile. Specifically, behavioral consistency calculation methods such as K-nearest neighbor clustering and sliding window evaluation can be used to determine whether the current request conforms to the behavioral profile. If the current API request does not conform to the behavioral profile, the risk level can be increased in the evaluation results to reduce the likelihood of authorization. Through behavioral analysis and judgment, authorization decisions not only rely on the aforementioned static rules but can also adapt to the user's specific behavioral patterns.

[0059] In some embodiments, state management control may include generating a unique ID for the API request and entering it into a state machine to control the API request's lifecycle. In a non-limiting embodiment, the state machine for the API request may include the following flow: initial state → waiting for evaluation → temporary authorization → automatic retry → completion / failure. Thus, the corresponding API request can be located based on the unique ID, and the current state of the API request and whether it has been evaluated can be queried based on the state machine. This avoids repeated judgments for the same API request and reduces computational pressure. In some specific embodiments, lifecycle control may include ensuring consistency of results when the operation corresponding to the API request is retried through idempotency flags and execution path records.

[0060] Specifically, a state machine can be used to maintain the lifecycle of the current request and cache the context of the original request. Before retrying, the system checks the state; for changes in business data, unique database indexes or business logic checks can be used to prevent duplicate processing. Unrestrictedly, the automatic retry process can use distributed locks or atomic operations to ensure idempotency. By checking for the existence of an idempotency flag or whether the execution path record contains the same core parameters, it can be determined whether the API request corresponding to the retry process has already been executed. Based on this, past execution processes can be directly used, saving resources and time. Especially in high-concurrency or distributed environments, this ensures concurrency safety and consistency during retries, avoids concurrency conflicts and data inconsistencies, and further improves business reliability.

[0061] In step S120, in response to the risk assessment result meeting the threshold, the issuance of dynamic temporary permissions includes: integrating the calculation results of the aforementioned risk strategy assessment, behavioral analysis judgment, and state management control to form a final comprehensive risk score and strategy recommendation. Through the collaboration of these three, the dynamic rationality and controllability of API requests with insufficient permissions are determined, thereby ensuring business continuity.

[0062] Additionally, the validity period and scope of dynamic temporary permissions can be determined based on the principle of least privilege. Specifically, temporary permissions with specific validity periods and scopes can be issued to avoid the risk of abuse. For example, permissions lasting only 10 to 30 minutes can be issued to avoid the risk of prolonged authorization. Additionally or alternatively, permissions limited to the current API, current table, current field, or specific operation can be issued to prevent the incorrect authorization of permissions exceeding the risk assessment results.

[0063] In step S130, completing the API request based on dynamic temporary permissions may include: generating a temporary authorization token based on the dynamic temporary permissions; and automatically retrying the API request using the temporary authorization token. In some specific embodiments, to automatically retry the API, a unique ID generated in a previous step can be generated or read, and based on this unique ID, the API request can be checked for duplicate processing; and in response to the absence of duplicate processing, the API request can be automatically retried. Specifically, a state machine can be used to monitor the API request and cache the context of the API request, thereby determining whether the API request has been processed repeatedly based on the unique ID, the state machine, and the context. When temporary permissions are granted, the API request can be retried to invoke the access object that is permitted by the permissions, avoiding repeated submissions of the API request by the user, making the whole process more seamless, improving user experience, and enhancing system robustness.

[0064] In some embodiments, a maximum number of retries and a time interval can be preset for automatic retries. This can prevent frequent occurrences of failed retry requests, improving system security and stability. It is understood that the retry strategy can be adjusted based on the aforementioned risk strategy assessment, and a reasonable maximum number of retries and time interval can be set based on factors such as the environmental characteristics of data access, thereby ensuring database security and stability.

[0065] In some embodiments, API requests can be translated into database operation instructions. This standardizes the API authorization and operation process, reducing the difficulty of interaction between different API request languages ​​and different target databases, alleviating the burden of using and developing interfaces, and improving development efficiency.

[0066] In some specific embodiments, structured and traceable log recording can also be performed on the entire process. The logs include API request content and receiving status, identity verification results, specific determination paths for permission calculations, triggering status of dynamic authorization, evaluation results of dynamic authorization, temporary permission content of dynamic authorization, and final database operation results. This allows for querying and auditing analysis from different aspects, improving the security of the entire process and making it standardized and controllable.

[0067] Figure 2 A schematic diagram of an API execution method with dynamic permission control according to an embodiment of the present disclosure is shown.

[0068] Specifically, Figure 2 After the API execution method shown begins, in step S200, the target and user identity information of the API request sent by the user are obtained to verify the user's identity and request content, including but not limited to token verification, IP verification, and frequency control verification. Next, in step S202, the verification result of step S200 is judged to determine whether the user's identity and request are legitimate. If the verification result is failure (step S202 judges "No"), the identity and request are determined to be illegitimate, and the process proceeds to step S204 to return an error message and end the current request process. Alternatively, if the verification result is success (step S202 judges "Yes"), the identity and request are determined to be legitimate, and the process proceeds to step S206 to perform dynamic permission calculation. In step S206, based on the multi-dimensional rules including ABAC and RBAC described in the aforementioned embodiment, the permissions required for the API request content and the permissions possessed by the user who issued the API request are comprehensively calculated to proceed to step S208. It can be understood that the above steps S200 to S208 are for... Figure 1 The refinement of step S100.

[0069] Further, in step S208, the two permissions calculated in step S206 are compared to determine whether the permissions meet the rule requirements. If the user's permissions meet the permissions required for the requested content (step S208 determines "yes"), proceed to step S216 to complete the API request. Alternatively, if the user's permissions do not meet the permissions required for the requested content (step S208 determines "no"), proceed to step S210 to assess the risk of the request. In step S210, the API request is assessed according to the method described in the foregoing embodiments to proceed to step S212, thereby judging the risk assessment result calculated in step S210. If the risk is determined to be higher than the threshold (step S212 determines "no"), proceed to step S214 to return an error message and end the current request process; if the risk meets the threshold (step S212 determines "yes"), a dynamic temporary permission can be issued to proceed to step S216. It can be understood that steps S210 to S216 are for... Figure 1 The steps S110 and S120 are further refined, wherein the process of proceeding from step S208 to step S216 corresponds to the API request that passes the permission verification, and the process of proceeding from step S212 to step S216 corresponds to the API request that is granted temporary dynamic permissions as described in this disclosure.

[0070] Specifically, in step S216, data operations are performed based on the user's permissions as determined in S208 (meeting the permission requirements of the requested information) or the dynamic temporary permissions granted in S212. This includes converting the API request into scalable data operation instructions adaptable to multiple databases and data sources. Then, in step S218, corresponding operations are performed on the database based on the operation instructions obtained in step S216. It can be understood that steps S216 to S218 are for... Figure 1 The refinement of step S130.

[0071] Furthermore, in step S220, the corresponding permissions can be re-verified upon completion of the database operation to prevent requests requiring higher permissions that arise during the operation from being completed by users without the appropriate permissions. If the permissions required for the corresponding database operation exceed the user's existing permissions or the scope of the granted temporary permissions, the process returns to step S210 to recalculate the corresponding permissions and determine whether to grant the appropriate operation permissions. It can be understood that step S220 and... Figure 1 This corresponds to step S130.

[0072] Additionally, the entire process may include step S222, which records an audit log. In step S222, the entire process from step S200 to step S220 is logged to provide a basis for subsequent monitoring and adjustment of the API execution process.

[0073] In the API execution method for dynamic permission control disclosed herein, an API request sent by a user can be received and permission verification can be performed on the API request; then, in response to the permission verification failing, the risk of the API request is assessed; then, in response to the risk assessment result meeting the threshold, dynamic temporary permission is granted; and the API request is completed based on the dynamic temporary permission. This allows business operations to continue without interrupting the process of low-risk but unauthorized API requests, avoiding business interruption, improving user experience, and enhancing the robustness of the data management system under high-pressure scenarios.

[0074] According to another aspect of this disclosure, an application programming interface (API) server apparatus with dynamic access control is also provided. For example... Figure 3 As shown, the application programming interface (API) server device 300 with dynamic access control may include: a network interface module 320, a verification module 340, a dynamic authorization module 360, and an operation module 380.

[0075] In some embodiments, the network interface module 320 is configured to receive API requests sent by users. As the entry point of the unified API gateway, the network interface module 320 is responsible for receiving API requests from various business systems at high concurrency and performing preliminary network layer verification.

[0076] In some embodiments, the verification module 340 is configured to perform permission verification on API requests. The permission verification by the verification module 340 may include parsing and verifying the user's identity token, verifying the request source IP, and limiting access frequency based on the user or API. Specifically, the verification module 340 incorporates a permission calculation engine based on the authorization verification method described in the foregoing embodiments, serving as the core permission decision unit. This engine includes a permission rule parser, an efficient decision engine, and a multi-dimensional context collector. In a non-limiting embodiment, the engine obtains multi-dimensional permission rules (including rules from the ABAC / RBAC hybrid model) from the permission rule base and, in conjunction with the request context, efficiently processes rule matching to determine operation permissions. The engine's design ensures millisecond-level response times, supports dynamic loading and hot updates of massive amounts of rules, and is suitable for high-availability environments.

[0077] In some embodiments, the dynamic authorization module 360 ​​is configured to assess the risk of an API request in response to a failed permission verification, and to issue dynamic temporary permissions if the risk assessment result meets a threshold. The dynamic authorization module 360 ​​dynamically assesses and generates an authorization token based on the context. Internally, it includes a risk assessment module 362 based on risk policy assessment, a behavior pattern assessment module 364 based on behavior analysis models, and a state management module 366 based on state management control. These sub-modules work collaboratively: the risk assessment module 362 assesses risk through risk rules, the behavior pattern assessment module 364 calculates the deviation of the user behavior profile, and the state management module 366 maintains state transitions and idempotency flags during request execution. It can be understood that the dynamic authorization module 360 ​​supports dynamically loading authorization policies, adapting to different business scenarios and data object security levels, ensuring both flexibility and security.

[0078] In some embodiments, the operation module 380 is configured to complete API requests based on dynamic temporary permissions. The operation module 380 incorporates various database adapters (such as MySQL adapter, SQL Server adapter, Oracle adapter, DM database adapter, etc.) to achieve seamless interaction with different database types. This ensures the secure execution of SQL actions such as DML, DDL, and DCL. It is responsible for converting unified API requests into corresponding database dialects or driver instructions, ensuring the effective transfer and execution of permissions, and encrypting sensitive data operations.

[0079] The API server device 300 with dynamic access control can be configured to perform the methods described in any of the foregoing embodiments of this disclosure.

[0080] Please refer to the following. Figure 4 , Figure 4 A schematic diagram of the data flow of an API server apparatus for dynamic access control according to an embodiment of the present disclosure is shown. (The diagram is for reference only.) Figure 3 The API server device includes a network interface module 320, a verification module 340 including an authentication module 342 and a dynamic permission calculation module 344, a dynamic authorization module 360, and an operation module 380 including a data operation module 382 and a multi-database instance module 384, etc. The network interface module 320, the dynamic authorization module 360, and the operation module 380 are connected to... Figure 3The functions of the corresponding modules are similar and will not be elaborated here. The authentication module 342 is configured to perform preliminary authentication by parsing the user's identity token and verifying the IP source of the request. The dynamic permission calculation module 344 is configured to obtain multi-dimensional permission rules and calculate a dynamic permission score based on the request context. The data operation module 382 is configured to perform data operations on the API request based on the calculation results of the dynamic permissions. The multi-database instance module 384 is configured to call adapters for multiple databases to convert the API request into operation instructions in the corresponding database language. Additionally, the API server device may include a permission rule base module 368 and a risk strategy / behavior analysis configuration module 370. It is readily understood that the permission rule base module 368 and the risk strategy / behavior analysis configuration module 370 can be integrated into the dynamic authorization module 360 ​​so that the dynamic authorization module 360 ​​can directly assess the risk of the API request. The permission rule base module 368 and the risk strategy / behavior analysis configuration module 370 can also be... Figure 4 As shown, it is set up separately, controlled by the management console module 392, and interacts with the dynamic licensing module 360 ​​to enable the dynamic licensing module 360 ​​to assess the risk of API requests.

[0081] Specifically, the API server device may also include an audit log module 390 and a management console module 392. In some embodiments, the audit log module 390 is configured to structurally record all critical events throughout the system's operation, particularly API requests, authentication results, permission determination results, intelligent dynamic authorization behavior (including evaluation results and temporary permission details), and final database operation logs. The audit log module 390 supports pushing data to external log and security analysis platforms, can aggregate and analyze unified audit information from different database operations, and provides a granular query interface.

[0082] Additionally, in some embodiments, the management console module 392 is configured to provide a user-friendly interface for unified configuration and management of multi-dimensional permission rules, interface registration and publishing, dynamic authorization policies, and parameters of risk policies and behavioral analysis models; it provides real-time permission monitoring, audit log query and report generation functions, and supports centralized management and visualization of permissions across databases. The management console module 392 can interact with the risk policy / behavioral analysis configuration module 370 to update risk policy settings and behavioral analysis methods. The management console module 392 can also interact with the verification module 340 and the permission rule base module 368 to obtain and update authentication policies. Specifically, the management console module 392 can also provide the function of converting temporary authorization behaviors that meet specific conditions, such as granting access authorization multiple times after successful execution without a security incident, into permanent permission rules or policies through a clear approval process or automated rule triggering mechanism, while ensuring the principle of minimizing permissions during rule formulation, to achieve continuous optimization and automated evolution of the permission system.

[0083] Furthermore, the data flow during API execution is as follows: Figure 4 As shown. After the requester sends API request data, it is received by the network interface module 320. The network interface module 320 sends the received API request data to the authentication module 342 for authentication and to the audit log module 390 for logging. If authentication fails, the authentication module 342 returns an error message to the requester; if authentication succeeds, it sends the request data to the dynamic permission calculation module 344 and sends the authentication process and result to the audit log module 390 for logging. The dynamic permission calculation module 344 performs permission calculation on the received request data. If the permissions are sufficient, it sends the request data to the data operation module 382; if the permissions are insufficient, it sends the request data to the dynamic authorization module 360 ​​and sends the permission calculation process and result to the audit log module 390 for logging.

[0084] Additionally, the dynamic authorization module 360 ​​interacts with the risk strategy / behavior analysis configuration module 370 to obtain the currently configured risk strategy and behavior analysis, and interacts with the permission rule base module 368 to obtain the permission rule base corresponding to the request data. It then performs dynamic authorization calculation by combining the configuration of the risk strategy and behavior analysis with the permission rule base. If dynamic authorization is rejected, an error message is returned to the requester. If dynamic authorization is successful, the request data and the dynamic temporary permission are sent to the dynamic permission calculation module 344 to complete the request using the temporary permission. The authorization evaluation result and the details of the issued temporary permission are sent to the audit log module 390 for logging.

[0085] Additionally, the data operation module 382 sends the requested data to the multi-database instance module 384, executes the operation instructions returned by the multi-database instance module 384, and sends the result back to the requester to complete the request. It also sends the result to the audit log module 390 for logging. The multi-database instance module 384 converts the requested data into operation instructions in the corresponding database language and returns the instructions to the data operation module 382. If insufficient permissions occur during data operation, it determines that the current operation has failed and sends the corresponding instructions back to the dynamic authorization module 360 ​​for dynamic authorization calculation. The management console module 392 reads the audit log module 390, the permission rule base module 368, and the risk strategy / behavior analysis configuration module 370 for monitoring and management, and updates the permission rule base module 368 and the risk strategy / behavior analysis configuration module 370.

[0086] like Figure 5 As shown, this disclosure also provides a computing device 400, which may include one or more processors 402 and a memory 404 storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the methods described according to any of the foregoing embodiments of this disclosure. The one or more processors 402 may, for example, be a central processing unit (CPU) of the computing device 400. The one or more processors 402 may be any type of general-purpose processor or may be a processor specifically designed for API execution, such as an application-specific integrated circuit (“ASIC”). The memory 404 may include various computer-readable media accessible by the one or more processors 402. In various embodiments, the memory 404 described herein may include volatile and non-volatile media, removable and non-removable media. For example, the memory 404 may include any combination of: random access memory (“RAM”), dynamic RAM (“DRAM”), static RAM (“SRAM”), read-only memory (“ROM”), flash memory, cache memory, and / or any other type of non-transitory computer-readable media. The memory 404 may store instructions that, when executed by the processor 402, cause the processor 402 to execute the method described according to any of the foregoing embodiments of this disclosure.

[0087] This disclosure also provides a computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by a computer, cause the computer to perform the method described in any of the foregoing embodiments of this disclosure. When the program runs on a server processor, it can drive the server to execute a unified API access control method according to the above steps, realizing functions such as dynamic access control, database adaptation operations, and behavior auditing, and is suitable for multi-system, multi-database scenarios. The storage medium can be a variety of non-volatile storage media, such as hard disks, solid-state drives, flash memory, optical disks, etc., ensuring the wide applicability of the implementation scheme.

[0088] This disclosure also provides a computer program product that may include instructions that, when executed by a processor, can implement the methods described according to any of the foregoing embodiments of this disclosure. The instructions may be any set of instructions that will be executed directly by one or more processors, such as machine code, or any set of instructions that will be executed indirectly, such as a script. The instructions may be stored in an object code format for direct processing by one or more processors, or stored in any other computer language, including scripts or sets of independent source code modules that are interpreted on demand or compiled in advance.

[0089] Figure 6 Block diagrams of an electronic device according to other embodiments of the present disclosure are shown.

[0090] Figure 6 The electronic device 600 shown can be a computer system with a dedicated hardware structure, which can perform corresponding functions when the relevant application is installed.

[0091] like Figure 6 As shown, the Central Processing Unit (CPU) 601 performs various processes based on a program stored in the Read-Only Memory (ROM) 602 or a program loaded from the storage section 608 into the Random Access Memory (RAM) 603. The RAM 603 stores data required as needed when the CPU 601 performs various processes, etc. The CPU is merely exemplary and could be other types of processors. The ROM 602, RAM 603, and storage section 608 can be various forms of computer-readable storage media. It should be noted that although... Figure 6 The diagram shows ROM 602, RAM 603 and storage section 608, but one or more of them may be combined or located in the same or different memory or storage modules.

[0092] CPU 601, ROM 602 and RAM 603 are interconnected via bus 604. Input / output interface 605 is also connected to bus 604.

[0093] The following components are connected to the input / output interface 605: input section 606, such as a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output section 607, including displays such as cathode ray tube (CRT), liquid crystal display (LCD), speakers, vibrators, etc.; storage section 608, including hard disk, magnetic tape, etc.; and communication section 609, including network interface cards such as LAN cards, modems, etc. Communication section 609 allows communication processing via a network such as the Internet. It is easy to understand that, although... Figure 6 The electronic device 600 shown communicates via bus 604, but it may also communicate via a network or other means, wherein the network may include a wireless network, a wired network, and / or any combination of wireless and wired networks.

[0094] As needed, drive 610 is also connected to input / output interface 605. Removable media 611, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 610 as needed, so that computer programs read from them can be installed into storage section 608 as needed.

[0095] When the above series of processes are implemented through software, the program constituting the software can be installed from a network such as the Internet or a storage medium such as removable medium 611.

[0096] According to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product that, when run on a computer, causes the computer to perform the methods described in any of the foregoing embodiments. The computer program product includes computer instructions carried on a computer-readable medium, containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer instructions can be downloaded and installed from a network via communication section 609, or installed from storage section 608, or installed from ROM 602. When the computer program is executed by CPU 601, the methods of the embodiments of this disclosure are performed.

[0097] It should be noted that, in the context of this disclosure, a computer-readable medium can be a tangible medium that may contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0098] The foregoing has described one or more exemplary embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0099] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this disclosure does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a game console, a tablet computer, a wearable device, or any combination thereof.

[0100] The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first" or "second" to denote names does not indicate any particular order.

[0101] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more embodiments of this disclosure, the functions of each module can be implemented in one or more software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0102] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0104] Those skilled in the art will understand that one or more embodiments of this disclosure may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0105] One or more embodiments of this disclosure can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0106] The same or similar parts between the various embodiments of this disclosure can be referred to mutually, and each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. In the description of this disclosure, the reference to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," "exemplary," etc., means that the specific feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of this disclosure. In this disclosure, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this disclosure and the features of different embodiments or examples.

[0107] Additionally, when used in this disclosure, the terms “here,” “above,” “below,” “below,” “in the following,” “overall,” and similar terms should refer to the entirety of this disclosure and not any particular part thereof. Furthermore, unless expressly stated otherwise or otherwise understood in the context in which they are used, conditional language used herein, such as “may,” “possibly,” “for example,” “like,” etc., is generally intended to express that certain embodiments include, while other embodiments do not, certain features, elements, and / or states. Therefore, such conditional language is not generally intended to imply that one or more embodiments require features, elements, and / or states in any way, or whether such features, elements, and / or states are included or performed in any particular embodiment.

[0108] The above description is merely an embodiment of one or more embodiments of this disclosure and is not intended to limit the scope of the one or more embodiments of this disclosure. Various modifications and variations can be made to the one or more embodiments of this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims.

Claims

1. A method for executing an application programming interface (API) with dynamic access control, comprising: Receive API requests sent by users and generate a unique ID for the API request; Perform permission verification on the API request; In response to the successful permission verification, the API request is completed based on the portion or all of the successful permission verification. In response to the failure of the permission verification, assess the risk of the API requests that failed the permission verification. If the risk assessment result of the API request meets the threshold, a first dynamic temporary permission is granted; as well as Completing the API request based on the first dynamic temporary permission includes: generating a first temporary authorization token based on the first dynamic temporary permission, and automatically retrying the API request using the first temporary authorization token; The process of completing the API request based on partial or full authorization verification and automatically retrying the API request includes: Translate the API request into database operation instructions. In response to insufficient permissions for the operation instruction, a dynamic authorization calculation is performed on the operation instruction. In response to the successful dynamic authorization, a second dynamic temporary permission is granted, and a second temporary authorization token is generated based on the second dynamic temporary permission. Based on the unique ID, check whether the API request is processed repeatedly, and In response to the absence of duplicate processing, the API request is automatically retried using the second temporary authorization token.

2. The API execution method according to claim 1, wherein, Assessing the risk of the API request includes integrating risk strategy assessment, behavioral analysis and judgment, and state management control mechanisms to generate the assessment results.

3. The API execution method of claim 2, wherein, The risk strategy assessment includes: Configure a policy rule base for permission risks to perform risk scoring on the API requests. The rule base includes at least one of the following: the operation sensitivity of the API request, the field sensitivity, the time window, the abnormality of the access geolocation, and the matching degree of the user's system and role.

4. The API execution method of claim 3, wherein, The rule base has context awareness capabilities and maintains the real-time nature of risk strategy rules through dynamic loading and updating.

5. The API execution method of claim 2, wherein, The behavioral analysis and judgment include: Build a behavioral profile based on the user's past behavior; and Behavioral consistency calculations are used to determine whether the API request conforms to the behavioral profile.

6. The API execution method of claim 5, wherein, Determining whether the API request matches the behavioral profile includes: If the API request does not match the behavioral profile, the risk level is increased in the assessment results.

7. The API execution method of claim 2, wherein, The state management control includes: A unique ID is generated for the API request and entered into the state machine to control the lifecycle of the API request.

8. The API execution method of claim 7, wherein, The lifecycle control includes: By using idempotency flags and execution path records, the results of retries for the operations corresponding to the API requests are kept consistent.

9. The API execution method of claim 1, wherein, In response to the risk assessment result meeting the threshold, dynamic temporary permissions are granted, including: The validity period and scope of the dynamic temporary permissions are determined based on the principle of least privilege.

10. The API execution method according to claim 1, wherein, Using a state machine to monitor the API request and caching the context of the API request, checking for duplicate processing of the API request includes: Based on the unique ID, the state machine, and the context, determine whether the API request has been processed repeatedly.

11. The API execution method of claim 1, wherein, The maximum number of retries and the time interval are preset for the automatic retries.

12. An application programming interface (API) server device for dynamic access control, comprising: A network interface module, configured to receive API requests sent by users and generate a unique ID for the API requests; A verification module, configured to perform permission verification on the API request; A dynamic authorization module is configured to, in response to the failure of the permission verification, assess the risk of the API request for the part that failed the permission verification, and in response to the risk assessment result of the API request meeting a threshold, issue a first dynamic temporary permission; as well as An operation module, configured to, in response to successful permission verification, complete the API request based on partial or full verification of successful permissions. The operation module is also configured to complete the API request based on the first dynamic temporary permission in response to the permission verification failing, including: generating a first temporary authorization token based on the first dynamic temporary permission, and automatically retrying the API request using the first temporary authorization token; The process of completing the API request based on partial or full authorization verification and automatically retrying the API request includes: Translate the API request into database operation instructions. In response to insufficient permissions for the operation instruction, a dynamic authorization calculation is performed on the operation instruction. In response to the successful dynamic authorization, a second dynamic temporary permission is granted, and a second temporary authorization token is generated based on the second dynamic temporary permission. Based on the unique ID, check whether the API request is processed repeatedly, and In response to the absence of duplicate processing, the API request is automatically retried using the second temporary authorization token.

13. The API server apparatus of claim 12, wherein, The dynamic authorization module includes a risk assessment module, a behavior pattern assessment module, and a status management module.

14. A computing device, comprising: Memory; as well as A processor coupled to the memory is configured to execute the API execution method of any one of claims 1-11 based on a computer program stored in the memory.

15. A computer readable storage medium comprising computer program instructions, wherein, When the computer program instructions are executed by the processor, they implement the API execution method of any one of claims 1-11.

16. A computer program product comprising computer program instructions that, when executed by a processor, implement the API execution method of any one of claims 1-11.

Images