A method and system for application access authorization and management of cross-resource pool API gateway

Abstract

The application discloses a kind of API gateway application access authorization and management method across resource pool, the method includes the following steps: S1: when creating application, controller is configured to be stored to nationwide area database Application, as global configuration center;S2: authorization process;S3: cancel authorization process;S4: user calls API application scene;A kind of API gateway application access authorization and management system across resource pool, the system is applicable to any one of the above method, and system includes: one: the application configuration storage module based on database implementation across resource pool;Two: application configuration adaptation module;Three: authentication authorization management module based on plug-in;Four: API calling SDK.The application improves efficiency and performance, reduces resource overhead, flexibly controls consumer configuration using consumer-restriction plug-in, but does not affect the dependence of other APIs on consumers, is simple and easy to use, improves the security capability and application scene of gateway.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing-middleware-API gateway, and particularly relates to a cross-resource-pool API gateway application access authorization and management method and system. BACKGROUND

[0002] As a unified entrance for user request API, the original authentication capability of the interface request served by the API gateway is improved to the API gateway with the unified management of the API. When the API gateway has the security protection capability for API request, it can more conveniently manage the unified management of the calling permission.

[0003] The prior art "API gateway unified authentication method and device" (CN202211365718.1) also uses consumer management and persists the authorization relationship in the backend database, and has high processing speed, but does not solve the problems that the API gateway cannot support multiple authentication methods at the same time, the current authentication method needs to configure authentication information on each API, the operation is cumbersome, and the bound information of the authentication cannot be viewed. SUMMARY

[0004] This section aims to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the abstract and title of the specification to avoid obscuring the purpose of this section, abstract and title, and such simplifications or omissions cannot be used to limit the scope of the present application.

[0005] In view of the above problems of the prior art cross-resource-pool API gateway application access authorization and management method and system, the present application is proposed.

[0006] Therefore, the purpose of the present application is to provide a cross-resource-pool API gateway application access authorization and management method and system, which is suitable for solving the problems that the API gateway cannot support multiple authentication methods at the same time, the current authentication method needs to configure authentication information on each API, the operation is cumbersome, and the bound information of the authentication cannot be viewed.

[0007] To solve the above technical problems, the present application provides the following technical scheme: a cross-resource-pool API gateway application access authorization and management method, the method comprising the following steps:

[0008] S1: when creating an application, the controller stores the application configuration to the nationwide database to serve as a global configuration center;

[0009] S2: authorization process;

[0010] S3: de-authorization process;

[0011] S4: User calls API application scenario.

[0012] As a preferred scheme of the method for application access authorization and management of the cross-resource-pool API gateway provided by the application, in the step S1, the following sub-steps are included:

[0013] Step one: When an application is created, a general configuration template is provided for the supported authentication types to help users quickly create the application, and the application name, the application authentication type, and the application configuration yaml data are specifically included.

[0014] Step two: After the application is created, the user authorizes and deauthorizes the API.

[0015] Step three: After the application is created, the user quickly modifies and deletes the configuration information, and after the change, the configuration is automatically synchronized to the corresponding API according to the authorized relationship table.

[0016] As a preferred scheme of the method for application access authorization and management of the cross-resource-pool API gateway provided by the application, in the step S2, the following sub-steps are included:

[0017] Step one: When the authorization action is performed;

[0018] Step two: When the authorization instruction and the plugin_config are received by the authorization authentication management module.

[0019] As a preferred scheme of the method for application access authorization and management of the cross-resource-pool API gateway provided by the application, in the step one, the following sub-steps are included:

[0020] 1: The configuration adaptation module obtains complete configuration information from the database according to the app_id;

[0021] 2: The app_config (yaml) is converted into the auth_plugin_config according to the app_auth_type;

[0022] 3: The authorization instruction and the plugin_config are issued to the authorization authentication management module to inform the API list to be authorized;

[0023] 4: The relationship record of the application authorization API is written into the database;

[0024] In the step two, the following sub-steps are included:

[0025] ①: In the current instance, create a consumer resource according to app_id, the consumer resource contains a consumer identifier with app_id as consumer_id, carries authentication and authorization information, and a quick authentication code;

[0026] ②: Update the resource configuration information of the API, that is, update the plugins configuration in the API resource, which includes: (1) write an app_auth_type corresponding auth-plugin name identifier, indicating that the API needs to be authenticated through this authentication method; (2) consumer-restriction plug-in, the whitelist and blacklist in the plug-in respectively represent the allowed and disallowed consumer list, and when authorized, write the consumer_id into the whitelist.

[0027] As a preferred scheme of the API gateway application access authorization and management method across resource pools, the de-authorization process includes the following sub-steps:

[0028] Step one: when performing the de-authorization action;

[0029] Step two: when the authorization authentication management module receives the contact authorization instruction and api_id.

[0030] As a preferred scheme of the API gateway application access authorization and management method across resource pools, in the step one, it includes the following sub-steps:

[0031] ①: issue the de-authorization instruction and plugin_config to the authorization authentication management module to inform the API list to be authorized;

[0032] ②: update the database and delete the relationship record of application authorization API;

[0033] In the step two: it is necessary to update the consumer-restriction plug-in in the API resource, and remove the consumer_id from the whitelist in the plug-in.

[0034] As a preferred scheme of the API gateway application access authorization and management method across resource pools, in the step S4, the application scenario includes:

[0035] One: for API without authentication;

[0036] Two: when the API requires authentication, and the application has been authorized to access the API;

[0037] Three: API requires authentication, and the application (hmac-auth method) has been authorized to access the API;

[0038] Four: Set app_auth_type to jwt method.

[0039] A cross-resource pool API gateway application access authorization and management system, the system is suitable for any of the above methods, and the system comprises:

[0040] One: a cross-resource pool application configuration storage module based on a database;

[0041] Two: application configuration adaptation module;

[0042] Three: authentication and authorization management module based on plug-in;

[0043] Four: API calling SDK.

[0044] As a preferred scheme of the cross-resource pool API gateway application access authorization and management system, wherein in "one":

[0045] ①: when creating an application in the gateway console, store the application configuration in the global database, wherein the application configuration table records the characteristics of the created application, and the application authorization relationship table records which API the application has access to;

[0046] ②: when authorizing / denying the API, the configuration is issued to the API (api_id) of each resource pool (region_id);

[0047] ③: when the APP configuration changes, traverse the relationship table, and issue and update the application configuration information of each resource pool API according to the relationship record;

[0048] In "two":

[0049] ①: receive a unified application authorization request body, which contains application ID, resource pool ID, instance ID, API unique identifier and authorization validity period;

[0050] ②: application configuration adaptation module, which is actually a configuration converter, obtains the authentication plug-in type and configuration yaml data according to the application ID, parses the yaml format into Map format authentication configuration, and flexibly supports the authentication method;

[0051] ③: issue the plugin config map to different APIs of the specified resource pool and instance, and the authorization configuration starts to take effect after the API configuration is completed.

[0052] As a preferred scheme of the cross-resource pool API gateway application access authorization and management system, in the "three", wherein:

[0053] ①: After receiving the plug-in configuration issued by the module, the consumer resource is created according to app_id, and the token information of the authentication is in the resource;

[0054] ②: According to the api_id list to be authorized, update the plug-in information plugins in each api resource, which specifically includes: the auth_plugin corresponding to app_auth_type; Update the white list of consumer-restriction plug-in;

[0055] ③: Each API writes multiple authentication plug-ins to realize that the same API can be authorized to different applications, and different applications use different authentication types;

[0056] In "four", wherein:

[0057] ①: Provide a unified SDK for API calling, and the SDK has built-in signature implementation, so that users can quickly start when calling and avoid complicated signature generation process;

[0058] ②: Support multi-language implementation.

[0059] The beneficial effects of the application are as follows:

[0060] 1. The application configuration storage module provides a cross-resource pool APP configuration sharing use scenario;

[0061] 2. The configuration adaptation module completes the conversion of application configuration to plug-in configuration, supports unified access capability of multiple authentication modes;

[0062] 3. The authentication authorization management module supports managing access credentials of certain services through consumers, can be reused by different APIs, and can flexibly control access to APIs through the consumer-restriciton plug-in, without deleting the consumer resource, avoiding the dependence and mutual influence of consumer configuration between APIs, which can guarantee the reuse of consumers among multiple APIs, support multiple authentication configuration and authentication at the same time, and provide more flexible application scenarios for users. BRIEF DESCRIPTION OF DRAWINGS

[0063] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description only represent some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative effort based on these drawings. Among them:

[0064] Figure 1 The application configuration sharing library of the application configuration storage and conversion delivery structure diagram of the application access authorization and management system of the API gateway across resource pools proposed by the present application represents the intention;

[0065] Figure 2 The application configuration storage and conversion delivery structure diagram of the application access authorization and management system of the API gateway across resource pools proposed by the present application represents the intention;

[0066] Figure 3 The application configuration adaptation module of the application access authorization and management system of the API gateway across resource pools proposed by the present application extracts the plug-in configuration according to the authentication type;

[0067] Figure 4 The plug-in-based authentication authorization management module of the application access authorization and management system of the API gateway across resource pools proposed by the present application. DETAILED DESCRIPTION

[0068] In order to make the above-mentioned purposes, features and advantages of the present application more apparent and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the drawings.

[0069] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced in a variety of ways beyond the specific details set forth herein, and the skilled in the art can make similar substitutions without departing from the scope of the present application, so the present application is not limited to the specific embodiments disclosed below.

[0070] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. "In one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment.

[0071] Thirdly, the present application is described in detail in combination with the schematic diagram. In the detailed description of the embodiments of the present application, the cross-sectional view of the device structure is locally enlarged without the general proportion for the convenience of description, and the schematic diagram is only an example, which should not limit the scope of protection of the present application. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in the actual manufacture.

[0072] Reference Figures 1-4 For an embodiment of the present application, a method for application access authorization and management of API gateway across resource pools is provided, the method comprising the following steps:

[0073] S1: When creating an application, the controller stores the application configuration to the regional database, serving as a global configuration center, and other resource pools can share these configuration information;

[0074] In step S1, it comprises the following sub-steps:

[0075] Step one: when creating an application, we provide a general configuration template for the supported authentication types to help users quickly create applications, which specifically includes application name, application authentication type, and application configuration yaml data;

[0076] Step two: after the application is created, the user authorizes and deauthorizes the API;

[0077] Step three: after the application is created, the user quickly modifies and deletes these configuration information, and after the change, the configuration will be automatically synchronized to the corresponding API according to the authorized relationship table;

[0078] S2: authorization process;

[0079] In step S2, it comprises the following sub-steps:

[0080] Step one: when performing authorization actions;

[0081] Step two: when the authorization instruction and plugin_config are received by the authorization authentication management module;

[0082] In step one, it comprises the following sub-steps:

[0083] ①: The configuration adaptation module obtains complete configuration information from the database according to app_id;

[0084] ②: Convert app_config (yaml) to auth_plugin_config according to app_auth_type;

[0085] ③: Issue the authorization instruction and plugin_config to the authorization authentication management module to inform the API list to be authorized;

[0086] ④: Write the relationship record of the application authorization API to the database;

[0087] In step two, it comprises the following sub-steps:

[0088] ①: In the current instance, create a consumer resource according to app_id, the consumer resource contains a consumer identifier with app_id as consumer_id, carries authentication and authorization information, and a quick authentication code;

[0089] ②: Update the resource configuration information of the API, that is, update the plugins configuration in the API resource, which includes: (1) Write an app_auth_type corresponding auth-plugin name identifier, indicating that the API needs to be authenticated through this authentication method; (2) The consumer-restriction plug-in, the whitelist and blacklist in the plug-in respectively represent the allowed and disallowed consumer list, and when authorized, write the consumer_id into the whitelist;

[0090] S3: De-authorization process;

[0091] The de-authorization process includes the following sub-steps:

[0092] Step one: When performing the de-authorization action;

[0093] Step two: When the authorization and authentication management module receives the contact authorization instruction and api_id;

[0094] In step one, it includes the following sub-steps:

[0095] ①: Issue the de-authorization instruction and plugin_config to the authorization and authentication management module to inform the API list to be authorized;

[0096] ②: Update the database and delete the application authorization API relationship record;

[0097] In step two: Update the consumer-restriction plug-in in the API resource, and remove the consumer_id from the whitelist in the plug-in;

[0098] S4: User call API application scenario.

[0099] In step S4, the application scenario includes:

[0100] One: For APIs without authentication;

[0101] Two: When the API requires authentication, and the application has been authorized to access the API;

[0102] Three: When the API requires authentication, and the application (hmac-auth method) has been authorized to access the API;

[0103] Four: set app_auth_type as jwt mode.

[0104] A cross-resource pool API gateway application access authorization and management system, the system is applicable to any of the above methods, and the system comprises:

[0105] One: a cross-resource pool application configuration storage module based on a database;

[0106] ①: when creating an application in the gateway console, store the application configuration in the global database, wherein the application configuration table records the characteristics of the created application, and the application authorization relationship table records which APIs the application has access to;

[0107] app_id is the unique identifier of the current application, according to which the configuration is obtained from the database and issued, and the authorization relationship is recorded; in the authentication and authorization management module, it is bound with the consumer, and the user can select different authentication types, such as key-auth, basic-auth, etc. simple authentication, also hmac-auth, jwt-auth, etc. to cope with different use scenarios; at the same time, different authentication configuration templates are provided for users, and app_config is used to record,

[0108] ②: when performing authorization / deauthorization operation on API, issue the configuration to the API (api_id) of each resource pool (region_id);

[0109] Perform batch authorization / deauthorization operation on API on each resource pool, and update the relationship between the application and the API in the API authorization relationship table;

[0110] ③: when the APP configuration changes, traverse the relationship table, and issue and update the application configuration information of each resource pool API according to the relationship record;

[0111] Two: application configuration adaptation module;

[0112] ①: receive a unified application authorization request body, which contains application ID, resource pool ID, instance ID, API unique identifier and authorization validity period;

[0113] ②: application configuration adaptation module, which is actually a configuration converter, obtains the authentication plug-in type and configuration yaml data according to the application ID, parses the yaml format to Map format authentication configuration, and flexibly supports authentication modes such as key-auth, basic-auth, hmac-auth, jwt-auth, etc.

[0114] ③: The plugin config map is issued to the different API of the specified resource pool and instance, and the authorization configuration takes effect after the API configuration is completed;

[0115] Three: the authentication and authorization management module based on the plug-in;

[0116] ①: After receiving the issued plug-in configuration, the module creates a consumer resource according to the app_id, and the resource has token information for authentication;

[0117] ②: According to the api_id list to be authorized, update the plug-in information plugins in each api resource, which specifically includes: the auth_plugin corresponding to the app_auth_type; update the white list of the consumer-restriction plug-in;

[0118] ③: Each API writes multiple authentication plug-ins to implement that the same API can be authorized to different applications, and different applications use different authentication types;

[0119] Four: API calling SDK;

[0120] ①: Provide a unified SDK for API calling, and the SDK has built-in signature implementation, which can help users quickly get started when calling and avoid the cumbersome signature generation process;

[0121] ②: Support multi-language implementation.

[0122] In the use process, the application configuration storage module provides a cross-resource pool APP configuration sharing use scenario; the configuration adaptation module completes the conversion of application configuration to plug-in configuration, supports unified access capability of multiple authentication methods; the authentication and authorization management module supports managing access credentials for a certain type of service through a consumer, which can be reused by different APIs, and can flexibly control access to APIs through the consumer-restriciton plug-in without deleting the consumer resource, avoiding the dependence and mutual influence of consumer configuration between APIs. Such design can not only ensure the reuse of consumers among multiple APIs, but also support multiple authentication configuration and simultaneous authentication; and can provide users with more flexible application scenarios.

[0123] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit it. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the present application, and all should be covered in the scope of the claims of the present application.

Claims

1. A method for authorizing and managing cross-resource pool API gateway application access, characterized in that, The method includes the following steps: S1: When an application is created, the controller stores the application configuration in the national database, acting as a global configuration center; S2: Authorization process; S3: Deauthorization process; S4: User API call application scenarios; Step S2 includes the following sub-steps: Step 1: When performing the authorization action; Step 2: When the authorization and authentication management module receives the authorization command and plugin_config; Step one includes the following sub-steps: ①: The configuration adaptation module retrieves complete configuration information from the database based on the app_id; ②: Convert app_config (yaml) to auth_plugin_config based on app_auth_type. g； ③: Send the authorization command and plugin_config to the authorization and authentication management module, informing it of the list of APIs to be authorized; ④: Record the relationship between the application authorization API and the database; Step two includes the following sub-steps: ①: In the current instance, a consumer resource is created based on app_id. The consumer resource contains a consumer identifier with app_id as the consumer_id, authentication and authorization information, and a fast authentication code. ②: Update the API resource configuration information, that is, update the plugins configuration in the API resources, which includes: (i) writing an auth-plugin name identifier corresponding to app_auth_type, indicating that the API needs to be authenticated through this authentication method; (ii) the consumer-restriction plugin, in which whitelist and blacklist represent the allowed and disallowed consumer lists respectively. When authorizing, the consumer_id is written into the whitelist.

2. The method for cross-resource pool API gateway application access authorization and management according to claim 1, characterized in that: Step S1 includes the following sub-steps: Step 1: When creating an application, we provide a general configuration template for the supported authentication types to help users quickly create applications. This template includes the application name, application authentication type, and application configuration YAML data. Step 2: After the application is created, the user authorizes and revokes the API. Step 3: After the application is created, users can quickly modify or delete these configuration information. After the changes, the configuration will be automatically synchronized to the corresponding API according to the authorized relationship table.

3. The method for cross-resource pool API gateway application access authorization and management according to claim 1, characterized in that: The deauthorization process includes the following sub-steps: Step 1: When performing the deauthorization action; Step 2: When the authorization and authentication management module receives the authorization removal instruction and api_id.

4. The method for cross-resource pool API gateway application access authorization and management according to claim 3, characterized in that: Step one includes the following sub-steps: ①: Send the deauthorization command and plugin_config to the authorization and authentication management module, informing them of the list of APIs to be authorized; ②: Update the database and delete the relationship record for the application authorization API; In step two, the consumer-restriction plugin in the API resources needs to be updated to remove the consumer_id from the whitelist in the plugin.

5. The method for cross-resource pool API gateway application access authorization and management according to claim 1, characterized in that: In step S4, the application scenarios include:

1. For APIs without authentication; Second: When the API requires authentication, and an application has already been authorized to access the API; 3. When the API requires authentication, and an application has already been authorized to access the API (using the hmac-auth method); 4. Set app_auth_type to JWT.

6. A cross-resource pool API gateway application access authorization and management system, characterized in that, The system is applicable to any one of the methods in claims 1-5 above, and the system comprises:

1. A cross-resource pool application configuration storage module based on a database; 2. Application configuration adaptation module; 3. Plugin-based authentication and authorization management module; 4. API calls to SDK.

7. The API gateway application access authorization and management system across resource pools according to claim 6, characterized in that: In "one": ①: When creating an application in the gateway console, the application configuration is stored in the global database. The application configuration table records the characteristics of the created application, and the application authorization relationship table records which APIs the application has access to. ②: When performing authorization / deauthorization operations on the API, the configuration will be distributed to the API (api_id) of each resource pool (region_id); ③: When the APP configuration changes, traverse the relationship table and issue and update the application configuration information of each resource pool API according to the relationship records; In "two": ①: Receive a unified application authorization request body, which includes the application ID, resource pool ID, instance ID, API unique identifier, and authorization validity period; ②: The application configuration adaptation module is actually a configuration converter. It obtains the authentication plugin type and configuration YAML data based on the application ID, and parses the YAML format into a Map format authentication configuration to flexibly support authentication methods. ③: Distribute the plugin config map to different APIs of the specified resource pool and instance. After completing the API configuration, the authorization configuration will take effect.

8. The API gateway application access authorization and management system across resource pools according to claim 6, characterized in that: In the "three": ①: After receiving the plugin configuration, this module creates a consumer resource based on the app_id, which contains authentication token information; ②: Based on the list of api_ids to be authorized, update the plugin information in each api resource, specifically including: the auth_plugin corresponding to app_auth_type; Update the whitelist of the consumer-restriction plugin; ③: Write multiple authentication plugins for each API so that the same API can be authorized to different applications, and different applications can use different authentication types; In "four": ① Provides a unified SDK for API calls, with built-in signature implementation, allowing users to quickly get started when making calls and avoiding the cumbersome signature generation process; ②: Supports multi-language implementation.

Images