A method for secure publishing of a multi-tier API service interface

Abstract

The application relates to the technical field of information security, and particularly discloses a multi-level API service interface security publishing method, which comprises the following steps: establishing a unique coding system, and allocating a unique AppID containing administrative level information to each application system and a secure networking gateway; a trusted access control system constructs a registration and management mechanism based on the AppID; a multi-level routing mechanism is established based on the allocated AppID, and hierarchical forwarding is carried out according to different levels of requests; a signature-based interface authentication mechanism is enabled in combination with the AppID, an AppID key, a random number and a timestamp; and finally, hierarchical security access control is carried out based on the allocated AppID. The multi-level API service interface security publishing method has the advantages that the problems of API interface publishing difficulty, weak authentication and complex routing under a multi-level architecture are solved, unified identification, intelligent routing, security authentication and hierarchical control integration are realized, the system flexibility, security and expandability are improved, and the method is suitable for multi-level network environments such as government affairs and large organizations.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and in particular to a method for safe publishing of multi-level API service interfaces. BACKGROUND

[0002] In the informatization system of a large organization, there are a large number of data interaction requirements between different departments or nodes. In order to realize communication between systems at different places and with different structures, the prior art usually adopts various ways to publish and call API interfaces:

[0003] Traditional VPN / dedicated line connection scheme: cross-network system communication relies on VPN tunnel or physical dedicated line for interconnection, and on this basis, the target system IP and interface path are manually configured. This scheme is complicated in network configuration, and has high deployment and maintenance costs; it relies on fixed IP and lacks flexibility; it cannot cope with dynamically adjusted nodes or interfaces, and has poor scalability.

[0004] Static API registration and calling: some systems register API documents through a platform, and the interface path and parameter format are maintained by administrators, and the calling party accesses through hard coding or configuration. This way lacks an automatic registration mechanism, has high maintenance costs; lacks a unique identification mechanism, and has serious interface conflict and duplicate naming problems; lacks version management and interface state management (such as activation / disuse) capabilities.

[0005] General API gateway (such as Kong, Apigee, Zuul, etc.): in enterprise applications, some cloud-native architectures introduce API gateways for traffic control, authentication, rate limiting, etc. However, these systems are based on homogeneous and same-level environments, and the design intention is biased towards internal calling scenarios of microservices. They are not suitable for complex network structures under multi-level and isolated network segments in government affairs, etc.; lack a location-aware coding system (such as AppID) for level addressing; and lack data forwarding mechanisms and permission control mechanisms between cross-level nodes.

[0006] Simple token or account password authentication mechanism: the current interface authentication methods of many systems are still at the initial stage of token, BasicAuth, APIKey, etc. They lack tamper-proofing and anti-replay mechanisms, and have a large security risk; the interface cannot distinguish the system identity of the calling party, and lacks trusted authentication based on the "system-system" dimension; and cannot support one-time signature, two-way authentication and other higher-level security requirements.

[0007] In summary, the main problems with existing technologies include: chaotic interface addressing, reliance on manual maintenance of domain names / IPs, lack of a unified encoding and identification system, and inability to accurately locate target services; inconsistent registration and management, lack of a standard interface registration and management platform, absence of lifecycle management, and difficulty in tracking interface versions and status; lack of cross-level routing mechanisms, preventing interfaces from being automatically routed or forwarded between multi-level nodes; insufficient security of authentication mechanisms, with existing authentication schemes being easily forged and lacking complete signature verification, timestamp verification, and anti-replay mechanisms; and incompatibility with API platforms in multi-level government architectures, as general API gateway products do not consider regional / administrative level divisions and are difficult to implement in government or isolated network environments. Summary of the Invention

[0008] The purpose of this invention is to provide a method for securely publishing multi-level API service interfaces, aiming to solve the problems of difficulty in publishing API service interfaces under multi-level architecture, weak authentication, and complex routing in the prior art. It also provides a method and system for securely publishing multi-level API service interfaces with unified identifier management, intelligent routing, and secure authentication mechanisms, thereby improving the system's automation, controllability, and security.

[0009] To achieve the above objectives, this invention provides a method for securely publishing multi-level API service interfaces, comprising the following steps:

[0010] S1. Establish a unique coding system and assign a unique AppID containing administrative hierarchy information to each application system and secure network gateway;

[0011] S2, the trusted access control system builds a registration and management mechanism based on AppID;

[0012] S3. Establish a multi-level routing mechanism based on the AppID allocated by S1, and perform hierarchical forwarding according to requests at different levels;

[0013] S4. Enable a signature-based interface authentication mechanism by combining AppID, AppID key, random number, and timestamp;

[0014] S5 uses the AppID assigned by S1 to perform hierarchical security access control.

[0015] Preferably, in S1, the AppID is a 16-bit code, with the first 10 bits representing the administrative position and level of the system, and the last 6 bits representing the system number. The system number of the secure network gateway is 000000.

[0016] Preferably, S2 is as follows:

[0017] When application systems and secure network gateways connect, they complete interface registration through the trusted access control system. After successful registration, the trusted access control system assigns a unique AppID and a corresponding AppID key to the application system and secure network gateway.

[0018] The secure network gateway obtains all AppID keys and builds a global AppID key table for interface authentication;

[0019] The trusted access control system performs full lifecycle management of registered application systems and secure network gateways, including system information updates and status monitoring.

[0020] Preferably, S3 is as follows:

[0021] Each secure network gateway has a built-in AppID routing rule table. The AppID routing rule table is generated by the trusted access control system according to the administrative hierarchy topology and is periodically synchronized to each secure network gateway. The AppID routing rule table includes routing path information corresponding to different administrative levels.

[0022] When the secure network gateway receives an interface request, it extracts the source AppID (X-SRP-SRCAPPID) and the target AppID (X-SRP-DSTAPPID) carried in the request header.

[0023] The secure network gateway compares the first 10 digits of the target AppID with the first 10 digits of its own AppID:

[0024] If they match, they are determined to be requests at the same level and are directly forwarded to the corresponding local application system for processing;

[0025] If there is a discrepancy, it is determined to be a cross-level request. Based on the administrative level information of the target AppID, it is routed through a preset routing path to the upper-level gateway or the gateway of the target level, and then forwarded by the upper-level gateway or the target gateway to the corresponding application system.

[0026] Preferably, S4 specifically includes the following steps:

[0027] S41. Before sending a request, the application system uses the HMAC-SM3 algorithm to generate a signature X-SRP-SIGN by combining its own AppID (X-SRP-SRCAPPID), its own AppID key, the target AppID (X-SRP-DSTAPPID), a random number, and a timestamp. The format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3.

[0028] S42. The application system transmits authentication information fields, including X-SRP-SRCAPPID, X-SRP-DSTAPPID, and X-SRP-SIGN, through the HTTP Header.

[0029] S43. After receiving the request, the secure network gateway extracts the authentication information from the HTTP Header. It first checks whether the timestamp in X-SRP-SIGN has expired. If it has expired, the request is rejected directly. If it has not expired, the same algorithm and parameters are used to regenerate the HMAC-SM3 signature, and then the signature is compared with the received signature.

[0030] If they match, the verification passes, ensuring that the request source is traceable, the content has not been tampered with, and it is not a duplicate request; if they do not match, the request is rejected.

[0031] Preferably, in S5, the secure network gateway performs access control on interface requests based on the AppID according to the security policy preset by the trusted access control system:

[0032] When an intrusion is detected in a data center system, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the data center system from entering the network;

[0033] For a given application system, a hierarchical access control strategy is adopted, allowing only requests from AppIDs corresponding to the central-level system, while rejecting requests from AppIDs at other levels.

[0034] Therefore, the present invention employs the above-mentioned method for securely publishing multi-level API service interfaces, and the beneficial effects are as follows:

[0035] (1) This invention achieves unique positioning of any node interface by combining the location information in the AppID encoding with the system number; data requests between systems can intelligently determine the routing path based on the AppID and automatically forward between different nodes such as the central, provincial, municipal, and county levels, without relying on static IP or VPN configuration, which greatly improves the flexibility and scalability of the system, greatly simplifies the service connection process between cross-regional and cross-network segment systems, and realizes unified addressing and rapid connection.

[0036] (2) The present invention adopts a request authentication mechanism that generates signatures using domestic encryption algorithms such as HMAC-SM3, which can effectively prevent data from being tampered with or forged; the introduction of timestamp and random number mechanism can resist replay attacks; the authentication parameter design in the form of HTTPHeader facilitates system access and expansion; at the same time, there is no direct call between application systems, and all requests are made through a secure network gateway, avoiding the leakage of application system IP and port information; thus, a strong identity authentication mechanism based on system to system is constructed to meet the high security standards required by government affairs and sensitive scenarios.

[0037] (3) The secure network gateway in this invention can determine whether the request is a same-level route by comparing the first 10 digits of its own AppID with the target AppID. Same-level requests are processed by the local application system, while cross-level requests are forwarded to the target gateway. The routing logic can adapt to changes in the hierarchical topology and supports dynamic expansion. This mechanism improves the forwarding efficiency and accuracy of interface calls and reduces human configuration errors and network maintenance pressure.

[0038] (4) All application systems in this invention must complete registration and identity binding through the trusted access control system. This system uniformly manages the entire lifecycle of AppID, including creation, modification, decommissioning, and abandonment. At the same time, it realizes the standardization of the entire process of interface release, permission allocation, and access control, which reduces the difficulty of operation and maintenance and improves the visibility, standardization, and security of interface resource management.

[0039] (5) The platform architecture of this invention adopts a modular design, covering components such as gateway, registration center, coding system, and routing service, which can be flexibly combined; the coding system, authentication mechanism, and gateway behavior can adapt to different organizational structures and permission models, and can be widely promoted and applied in multiple industries such as government affairs, medical care, finance, and power. From the perspective of solving multiple levels and applications with one platform, it has high promotion and reuse value and can bring significant social and economic benefits.

[0040] (6) All routing, authentication, and response operations during the interface call process are uniformly recorded in this invention, providing original evidence for subsequent auditing, security tracking and performance analysis, improving the transparency and compliance of the system, and facilitating fault diagnosis and security supervision.

[0041] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0042] Figure 1 This is an overall architecture diagram of an embodiment of a method for securely publishing multi-level API service interfaces according to the present invention;

[0043] Figure 2 This is an overall flowchart of an embodiment of a method for securely publishing multi-level API service interfaces according to the present invention;

[0044] Figure 3 This is a schematic diagram illustrating a cross-level request in an embodiment of a method for securely publishing multi-level API service interfaces according to the present invention.

[0045] Figure 4 This is a schematic diagram of a same-level request in an embodiment of a method for securely publishing multi-level API service interfaces according to the present invention. Detailed Implementation

[0046] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0047] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components.

[0048] like Figure 1 As shown, the architecture of this invention includes several application systems, a secure network gateway, and a trusted access control system. Among them, 1 to n application systems are distributed at the central, provincial, and municipal nodes, serving as carriers of business functions. They are responsible for government affairs processing and data query systems in government affairs scenarios, undertaking specific business logic, and generating and processing data.

[0049] The secure network gateway is responsible for encrypting, transmitting, and decrypting data packets, ensuring the security of cross-node data interaction, such as preventing tampering and leakage, and enabling application systems at different levels to communicate securely.

[0050] The trusted access control system manages the access permissions and data flow rules of each node's secure network gateway through control messages, ensuring that only trusted nodes and legitimate data can participate in collaboration and preventing unauthorized access.

[0051] like Figure 2 As shown, a method for securely publishing multi-level API service interfaces includes the following steps:

[0052] S1. Establish a unique coding system, assigning a unique AppID containing administrative hierarchy information to each application system and secure network gateway. The AppID is a 16-bit code; the first 10 bits represent the system's administrative location and level, and the last 6 bits represent the system number. The secure network gateway, as a special application system, has a unique system number of 000000. The AppID is uniformly assigned by the trusted access control system, serving as a unique identifier for interface requests and responses, used for routing, authentication, access control, and log auditing. The AppID enables a unified identification and location information fusion service addressing method across domains and layers.

[0053] S2. The trusted access control system builds a registration and management mechanism based on AppID, specifically as follows:

[0054] When the application system and the secure network gateway connect, they complete the interface registration through the trusted access control system. After successful registration, the trusted access control system assigns a unique AppID and a corresponding AppID key to the application system and the secure network gateway. The secure network gateway also obtains all the AppID keys and builds a global AppID key table for S4 interface authentication.

[0055] Then, the trusted access control system performs full lifecycle management of the registered application systems and secure network gateways, including system information updates and status monitoring.

[0056] S3. A multi-level routing mechanism is established based on the AppID allocated by S1, and requests are forwarded in a hierarchical manner according to different levels, specifically as follows:

[0057] Each secure network gateway has a built-in AppID routing rule table. The AppID routing rule table is generated by the trusted access control system according to the administrative hierarchy topology and is periodically synchronized to each secure network gateway. The AppID routing rule table includes routing path information corresponding to different administrative levels.

[0058] When the secure network gateway receives an interface request, it extracts the source AppID (X-SRP-SRCAPPID) and the target AppID (X-SRP-DSTAPPID) carried in the request header.

[0059] The secure network gateway compares the first 10 digits of the target AppID with the first 10 digits of its own AppID:

[0060] If they match, they are determined to be requests at the same level and are directly forwarded to the corresponding local application system for processing;

[0061] If there is a discrepancy, it is determined to be a cross-level request. Based on the administrative level information of the target AppID, it is routed through a preset routing path to the upper-level gateway or the gateway of the target level, and then forwarded by the upper-level gateway or the target gateway to the corresponding application system.

[0062] By decoupling the routing mechanism from the location coding, the target path can be dynamically determined without the need for manual maintenance of the configuration rule table. It can automatically adapt to changes in the topology structure by parsing the hierarchical identifier carried in the request and generate the optimal forwarding path in real time. This can not only cope with dynamic adjustment scenarios such as adding or migrating nodes, but also reduce configuration errors caused by manual intervention, and greatly improve the flexibility and reliability of API interface routing in multi-level network environments.

[0063] S4. Enable a signature-based interface authentication mechanism by combining AppID, AppID key, random number, and timestamp, specifically including the following steps:

[0064] S41. Before sending a request, the application system uses the HMAC-SM3 algorithm to generate a signature X-SRP-SIGN by combining its own AppID (X-SRP-SRCAPPID), its own AppID key, the target AppID (X-SRP-DSTAPPID), a random number, and a timestamp.

[0065] The format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3 (SRCAPPID + DSTAPPID + random number + timestamp, AppID key).

[0066] S42. The application system transmits authentication information fields, including X-SRP-SRCAPPID, X-SRP-DSTAPPID, and X-SRP-SIGN, through the HTTP Header to ensure that the source of the interface request is verifiable, tamper-proof, and replay-proof.

[0067] S43. Upon receiving a request, the interface receiver, including the secure network gateway or the target application system, extracts the authentication information from the HTTP Header. It first checks if the timestamp in X-SRP-SIGN has expired. The expiration time is typically 5 seconds (configurable). If expired, the request is rejected. If not expired, the signature is regenerated using the same algorithm and parameters. The AppID key needs to be retrieved from the AppID key table based on the source AppID and compared with the received signature.

[0068] If they match, the verification passes, ensuring that the request source is traceable, the content has not been tampered with, and it is not a duplicate request; if they do not match, the request is rejected.

[0069] S5 uses the AppID assigned by S1 to perform hierarchical security access control.

[0070] The secure network gateway performs access control on interface requests based on the AppID according to the security policies preset by the trusted access control system.

[0071] When an intrusion is detected in a data center system, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the data center system from entering the network;

[0072] For a given application system, a hierarchical access control strategy is adopted, allowing only requests from AppIDs corresponding to the central-level system, while rejecting requests from AppIDs at other levels.

[0073] Example 1

[0074] like Figure 3 The diagram illustrates the cross-level request process using bidirectional communication between the central node application system AppID1 and the provincial node application system AppID2. The specific interaction process is as follows:

[0075] (a) The request process from the central level to the provincial level

[0076] First, the central node's AppID1 initiates a request, with the request header carrying the source AppID: AppID1 and the destination AppID: AppID2, and then hands it over to the central node's secure network gateway.

[0077] Next, after the central routing service identifies the destination AppID, i.e., AppID2, it forwards the request to the provincial node secure network gateway through the secure network gateway. The provincial routing service then passes the request to the provincial destination AppID2.

[0078] After AppID2 finishes processing, the response data is returned to AppID1 via the reverse path through the provincial and central routing services, completing a cross-level call.

[0079] (ii) The request process from the provincial level to the central level

[0080] The process logic is the reverse of the above. AppID2 initiates a request with the source ID: AppID2 and the destination ID: AppID1 in the request header. After being forwarded by the provincial and central routing services, AppID1 responds and then returns, achieving bidirectional interaction. Through the above interaction process, two applications at different levels can send and receive messages and transmit data to each other, realizing cross-regional business collaboration.

[0081] Example 2

[0082] like Figure 4 As shown, application system 1 and application system 2 at the same level exchange data through secure access devices and routing services. The specific process is as follows:

[0083] First, application system 1 sends a request to the secure access device, with the request header carrying the source AppID (AppID1) and the destination AppID (AppID2). The secure access device then forwards the request to application system 2 through the routing service.

[0084] After processing, Application System 2 returns the data content to the secure access device, which then returns it to the application system. Next, Application System 2 sends a request to the secure access device, with the request header carrying the source ID (AppID2) and the destination ID (AppID1), which is also forwarded to Application System 1 through the routing service. After processing, Application System 1 returns the data content, which is then sent back to Application System 2 via the secure access device.

[0085] Within the same-level request, the source and destination of data are identified by including source ID and destination ID in the request header, enabling accurate routing and data transmission between different application systems. Secure access devices play a role in security verification and filtering, ensuring communication security; the routing service is responsible for accurately forwarding requests and sending back data based on the request header information, ensuring collaborative work and data interaction between different services or applications.

[0086] Therefore, the present invention adopts the above-mentioned method for securely publishing multi-level API service interfaces. It achieves unified identification and accurate addressing of multi-level systems through a unique AppID, realizes full lifecycle management by relying on trusted access control, ensures cross-level communication security by combining intelligent routing and strong signature authentication, and strengthens risk management by using hierarchical access control. It effectively solves the problems of API interface publishing, authentication and routing under multi-level architecture, and significantly improves system security and ease of use.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for securely publishing multi-level API service interfaces, characterized in that, Includes the following steps: S1. Establish a unique coding system and assign a unique AppID containing administrative hierarchy information to each application system and secure network gateway; The AppID is a 16-bit code. The first 10 bits represent the administrative position and level of the system, and the last 6 bits represent the system number. The system number of the secure network gateway is 000000. S2, the trusted access control system establishes a registration and management mechanism based on AppID; specifically: When application systems and secure network gateways connect, they complete interface registration through the trusted access control system. After successful registration, the trusted access control system assigns a unique AppID and a corresponding AppID key to the application system and secure network gateway. The secure network gateway obtains all AppID keys and builds a global AppID key table for interface authentication; The trusted access control system performs full lifecycle management of registered application systems and secure network gateways, including system information updates and status monitoring; S3. A multi-level routing mechanism is established based on the AppID allocated by S1, and requests are forwarded hierarchically according to different levels; specifically: Each secure network gateway has a built-in AppID routing rule table. The AppID routing rule table is generated by the trusted access control system according to the administrative hierarchy topology and is periodically synchronized to each secure network gateway. The AppID routing rule table includes routing path information corresponding to different administrative levels. When the secure network gateway receives an interface request, it extracts the source AppID (X-SRP-SRCAPPID) and the target AppID (X-SRP-DSTAPPID) carried in the request header. The secure network gateway compares the first 10 digits of the target AppID with the first 10 digits of its own AppID: If they match, they are determined to be requests at the same level and are directly forwarded to the corresponding local application system for processing; If there is a discrepancy, it is determined to be a cross-level request. Based on the administrative level information of the target AppID, it is forwarded to the upper-level gateway or the gateway of the target level through the preset routing path, and then forwarded to the corresponding application system by the upper-level gateway or the target gateway. S4. Enable a signature-based interface authentication mechanism by combining AppID, AppID key, random number, and timestamp; S5 uses the AppID assigned by S1 to perform hierarchical security access control.

2. The method for securely publishing multi-level API service interfaces according to claim 1, characterized in that, S4 specifically includes the following steps: S41. Before sending a request, the application system uses the HMAC-SM3 algorithm to generate a signature X-SRP-SIGN by combining its own AppID (X-SRP-SRCAPPID), its own AppID key, the target AppID (X-SRP-DSTAPPID), a random number, and a timestamp. The format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3. S42. The application system transmits authentication information fields, including X-SRP-SRCAPPID, X-SRP-DSTAPPID, and X-SRP-SIGN, through the HTTP Header. S43. After receiving the request, the secure network gateway extracts the authentication information from the HTTP Header. It first checks whether the timestamp in X-SRP-SIGN has expired. If it has expired, the request is rejected directly. If it has not expired, the same algorithm and parameters are used to regenerate the HMAC-SM3 signature, and then the signature is compared with the received signature. If they match, the verification passes, ensuring that the request source is traceable, the content has not been tampered with, and it is not a duplicate request; if they do not match, the request is rejected.

3. The method for securely publishing multi-level API service interfaces according to claim 2, characterized in that, In S5, the secure network gateway controls access to interface requests based on the AppID according to the security policies preset by the trusted access control system: When an intrusion is detected in a data center system, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the data center system from entering the network; For a given application system, a hierarchical access control strategy is adopted, allowing only requests from AppIDs corresponding to the central-level system, while rejecting requests from AppIDs at other levels.

Images