webMethods API Gateway supports the safe exposure of APIs by featuring threat protection and enforcing identity and access management policies. Its reverse invoke capabilities supports the exposure of APIs that are running entirely behind a firewall or where just the service implementing the APIs is protected by a firewall.
This tutorial explains how to deploy an API Gateway to the DMZ that exposes APIs for webMethods flow services which are running on a webMethods Integration Server behind a firewall in the so called green zone. The focus is on making sure that no flow services of the internal Integration Server are exposed via the DMZ API Gateway.
The tutorial applies to webMethods API Gateway 10.5.
Simplified DMZ Deployment versus Paired Deployment
The best practice for safely exposing APIs to consumers in the Web is via a paired API Gateway deployment. As shown below the paired API Gateway deployment consists of an API Gateway running in the DMZ communicating to an API Gateway deployed to the green zone protected by a firewall.
The DMZ API Gateway performs threat protection on an external port. Incoming requests to this port are forwarded to the API Gateway in the green zone via reverse invoke. Reverse invoke means that the API Gateway in the green zone is contacting a registration port on the DMZ API Gateway. Since the connection is initiated reverse to the request flow the reverse invoke does not require any port exposure in the firewall protecting the green zone.
The API Gateway in the green zone exposes APIs and performs API specific runtime policy enforcement. According to the routing policy definitions it routes incoming requests to backend services. The backend services might be flow services running on a webMethods Integration Server.
If all backend services are in fact flow services the paired deployment can be simplified by just deploying an API Gateway into the DMZ. The API Gateway performs threat protection and API specific runtime policy enforcement. The API requests are routed to the backend flow services running on the webMethods Integration Server via reverse invoke.
Blocking Requests to Internal Services
The simplified deployment requires a dedicated configuration to ensure that flow services running on the Integration Server can not be invoked through the DMZ API Gateway. The configuration consists of an external port on the DMZ API Gateway that has 2 registration ports. The picture below shows an example port configuration in the port configuration screen of a DMZ API Gateway.
The screen shows the following ports:
- 5500: API Gateway default HTTP regular port
- 9200: API Gateway external port (ExtPortAlias)
- 9201: API Gateway registration port (DefaultRegPortAlias)
- 9202: API Gateway registration port (ApiRegPortAlias)
Requests are received on the external port ExtPortAlias. These requests are forwarded to the registration port DefaultRegPortAlias. DefaultRegPortAlias is connected to an API Gateway internal port that is defined on the DMZ API Gateway. This ensures that requests are not forwarded to the Integration Server in the green zone, but processed within the DMZ API Gateway. The default registration port is the first one defined for an external port. There is no specific naming required.
To forward API requests to the backend services, the API routing policies need to point to the ApiRegPortAlias, the second registration port alias defined for the external port. The policy configuration screen below shows the routing policy configuration of a sample API deployed to the DMZ API Gateway.
The endpoint URI of the Straight Through Routing policy leverages the apigateway scheme and references the ApiRegPortAlias. The resource path of the endpoint URI points to the sample flow service employee running on the green zone Integration Server. As mentioned above this flow service can not be invoked directly from DMZ external port. All non API requests are routed to the internal port of the DMZ API Gateway where the backend flow services are not defined.
The registration port ApiRegPortAlias is associated with the internal port of the Integration Server in the green zone. The following picture shows its port configuration screen with the internal port connected referencing the registration port ApiRegPortAlias on the DMZ API Gateway.
This tutorial shows how to configure a simpiifed API Gateway DMZ deployment. The configuration ensures that internal flow services of an Integration Server connected to the API Gateway via reverse invoke are not exposed to external consumers.