Author: Vaidyanathan, Praveen
Supported Versions: 9.12 & above
webMethods API Gateway tutorial
Introduction
This article mainly focuses on Configuration of Reverse Invoke communication between the API Gateway in the DMZ and webMethods Integration Server or API Gateway in the Internal Greenzone. Explains in detail, how the API Gateway Administrator can configure the External and Registration Ports in webMethods API Gateway and Internal Ports in the API GW or ESB internal server for the below deployment scenarios,
- webMethods API Gateway Server within DMZ and Integration Server in the Green zone
- webMethods API Gateway Standard Edition Server in DMZ & webMethods API Gateway Advanced Edition Server in Green Zone in a paired deployment model.
What is Reverse Invoke
- Reverse Invoke enables a secure connection between the API Gateway or Integration Server in the protected network to an API Gateway server within the DMZ. It is a technique for allowing your server to be hidden behind a hard firewall to further reduce the possibility of a security compromise. The communication is always initiated from the internal server to the API Gateway and hence no firewall ports need to be opened that could lead to a violation of security guidelines.
- In webMethods API Gateway this is achieved by,
- creating paired ports in the external server (an external port which is used for the external clients and a registration port). The external client requests come to external port, which delegates the request to its paired port i.e the registration port.
- creating an Internal port in the internal server which will listen and pull the requests queuing up in the registration port.
Deployment Scenario 1: webMethods API Gateway Server within DMZ and Integration Server in the Green zone
In this deployment scenario, typically Threat protection rules as well as the Authentication, Authorization, Mediation are imposed in the API Gateway Server in the DMZ. For this configuration, you should be using the API Gateway Advanced edition license in the DMZ. If Authentication against LDAP or any other external systems within the Greenzone is required, then customers should ensure that appropriate ports are exposed in the firewall for API Gateway to access the internal authentication configured servers.
The configuration involves the following:
- External & Registration ports on the API Gateway
- Load Balance URL in the API Gateway
- Routing Protocol for the API with the Registration Port Alias
- Internal Server configuration with the Registration port of API Gateway for Reverse Invoke.
- External & Registration Ports on the API Gateway Server: As an API gateway Administrator, create external and registration ports in the API GW server deployed in DMZ through Administration->Security->Ports section. Select 'API Gateway external' and provide the values. External Port is the port that is exposed to the consumer requests and Registration port is the port on which the Internal Server listens for the requests. The Registration Port Alias is used in the API Routing Protocol. Hence use a proper alias name to identify the Registration port that can be specified in the Routing protocol. Once created, the external and registration ports appear in the ports table where you can enable them.
- Load Balance URL Configuration on the API Gateway Server: Configure Load balancer url from Administration ->General ->Load balancer. Provide the configured External Port or an external Load balancer URL. The API endpoints will have this port for external consumers. If you have a Load Balancer, then the requests from the LB have to be directed to the API Gateway External port.
- API Routing Endpoint with Registration Port Alias
Create an API in the webMethods API Gateway using any one of the choices. In this deployment scenario, the internal server is a webMethods Integration Server and if you wish to use the Reverse Invoke functionality, then you should modify the routing endpoint of the API created on the webMethods API Gateway in DMZ as below,
apigateway://{REG_PORT_ALIAS}/rest/api/resource - In this case, the native service resides in IS
Ex: apigateway://RegPortAlias/rest/EMP1/employeeDetails/findEmp/15 (sample screenshot below)
REG_PORT_ALIAS is the Registration Port Alias name used in the External-Registration Port configuration in the API Gateway Server in DMZ.
However, if the Internal Server is not a webMethods Integration Server, then you need to have a Reverse Proxy server in DMZ to allow the requests to be allowed to specific endpoints. The routing endpoint can be specified as regular endpoint where the service is hosted.
Note: There are cases where the routing can point to an API which resides in webMethods API Gateway, in this case the end point will be apigateway://{REG_PORT_ALIAS}/gateway/api/resource which in turn will invoke the native service
- Internal Server Port Configuration on the ESB Server (Internal Network): Configure the Internal Server Port in the Integration Server where the native API resides and provide the details of API GW and Registration port, and enable it.
Invoke the API on the API Gateway
Invoke the API from a client as http://<APIGWServer>:<ExternalPort>/gateway/EMP1/employeeDetails/findEmp/15
Deployment Scenario 2: webMethods API Gateway Server both in DMZ and Green Zone.
In this deployment scenario, typically Threat protection rules are imposed in API Gateway Server (Standard Edition) in DMZ. The API's are deployed on the API Gateway in the Greenzone wherein Authentication, Authorization, Mediation are imposed prior to routing the requests to the Native service.
- External API Gateway in DMZ
- External and Registration ports on the External API Gateway in DMZ (Similar to the Deployment Model 1)
- API gateway in Internal Network
- Internal API Gateway Server configuration with the Registration port of API Gateway for Reverse Invoke (Similar to the Deployment Model 1
- Load balancer URL in the Internal API Gateway. Specify the ExternalAPIGW:ExternalPort (configuration is similar to the Deployment Model
- Create an API in the Internal API Gateway Server with routing protocol and endpoint as the Native Server.
- Invoke the API using the external endpoint of the API.In this above deployment scenario, you can use the below URL to access the APIs which reside in the internal server.
http://<<externalserver>>:<<externalport>>/<api-name>/<resource-path>
Ex: http://mcext01:6666/EMP1/employeeDetails/findEmp/15 (sample screenshot below)
Even though the API isn't available in the external server, when the request is made to the external port it delegates it to the registration port. The internal port which we configured on the internal server listens to the registration port and picks up this request (reverse invoke), processes it and then sends back the response to the external server.
