Supporting Legacy Web Services (SOAP) With Kong API Gateway
Let's admit it - web services (SOAP) are here to stay for a few more years, and maybe for a long time in some places where there is no business incentive to rebuild them. However, with a decline in new SOAP web services and most applications moving to cloud native architectures, a common query is "how can we support legacy services while moving to microservices?"
The good news is Kong’s versatility of handling multi-protocol traffic and extensibility can help address this question. I recently worked with a customer who wanted to quickly move to microservices but still proxy and integrate existing/legacy SOAP services. After all, new and existing legacy web services will likely need to communicate with each other. Its existing solution would not work with microservices architecture (too slow and monolithic), and the customer turned to Kong.
It was clear to the customer that Kong could handle its journey to microservices, but the key question was: Could Kong Gateway handle its existing legacy web services?
The key requirement with any digital project is to ensure that there is no impact to the consumers. In this case, it was important to provide the same service interface to the consumer (business partners outside of the enterprise) but perform LDAP authentication against a cloud-based identity store and then proxy the request to the existing application.
The key design principles were simplicity and modularity so that as other scenarios surface, they can be addressed. Reviewing a number of different options, I came across the Kong Serverless plugin, which provides the ability to execute any code as part of any request in addition to the functionality provided by other plugins. This gave us the flexibility needed with the added benefit of also leveraging Kong plugins to minimize the amount of work we had to do. I've done custom logic work in other monolithic API gateways before, but the difference with Kong is that it is a light-weight, multi-protocol API gateway that provides enough extensibility to support a variety of use cases (legacy to microservices and FaaS) while staying clear of becoming a heavyweight ESB.
Note: If you would like to try out serverless plugins on Konnect SaaS, reach out to your CXM or Support team to get serverless plugins enabled.
Let's go through the details of what we configured. I detail the steps sequentially below (I used Kong Enterprise v1.3 for the testing).
1. Connecting to the Calculator Web Service Directly
Using httpie
http POST http://www.dneonline.com/calculator.asmx?op=Add Content-type:application/soap+xml <<< '<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"><soap12:Body><Add xmlns="http://tempuri.org"><intA>45</intA><intB>55</intB></Add></soap12:Body></soap12:Envelope>'
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 325
Content-Type: application/soap+xml; charset=utf-8
Date: Thu, 20 Feb 2020 11:03:23 GMT
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><AddResponse xmlns="http://tempuri.org"><AddResult>100</AddResult></AddResponse></soap:Body></soap:Envelope>
Using cURL
curl -v \
>> --url 'http://www.dneonline.com/calculator.asmx?op=Add' \/
> --header 'content-type: application/soap+xml; charset=utf-8' \
> --data '<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
> <soap12:Body>
> <Add xmlns="http://tempuri.org">
> <intA>45</intA>
> <intB>55</intB>
> </Add>
> </soap12:Body>
> </soap12:Envelope>'
* Trying 45.40.165.23...
* TCP_NODELAY set
* Connected to www.dneonline.com (45.40.165.23) port 80 (#0)
>> POST /calculator.asmx?op=Add HTTP/1.1
> Host: www.dneonline.com
> User-Agent: curl/7.64.1
> Accept: */*
> content-type: application/soap+xml; charset=utf-8
> Content-Length: 316
>
* upload completely sent off: 316 out of 316 bytes
< HTTP/1.1 200 OK
...
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><AddResponse xmlns="http://tempuri.org"><AddResult>100</AddResult></AddResponse></soap:Body></soap:Envelope>* Closing connection 0
Using Kong Studio:
2. Pre-Function Script
The Lua script below, which I saved as get-ws-creds.lua:
- Extracts the username and password from the SOAP header (WS-Security header)
- Constructs the Authorization header required for LDAP Authentication
3. Configuring Services, Route and Plugins
To test the integration, we use a publicly available Calculator-Web-Service configured in Kong to proxy to URL http://www.dneonline.com/calculator.asmx?op=Add/. The service performs an add operation of numbers passed in the request.
a. Configure Service
Let's configure a test service with Kong Admin API using httpie CLI
http -f localhost:8001/services name=Calculator-Web-Service url=http://www.dneonline.com:80/calculator.asmx
HTTP/1.1 201 Created
{
"client_certificate": null,
"connect_timeout": 60000,
"created_at": 1582112424,
"host": "www.dneonline.com",
"id": "f1b677fe-4fba-41d1-8d1a-91743863775d",
"name": "Calculator-Web-Service",
"path": "/calculator.asmx",
"port": 80,
"protocol": "http",
"read_timeout": 60000,
"retries": 5,
"tags": null,
"updated_at": 1582112424,
"write_timeout": 60000
}
Next, we configure the necessary Kong routes and the Pre-function and LDAP plugins to finalize the setup:
b. Configure a route /secure-soap-ldap to test
http -f PUT http://<Kong_Admin_API_Host>:8001/services/Calculator-Web-Service/routes/secure-soap-ldap paths[]=/secure-soap-ldap
c. Configure the Pre-function plugin on the route. Notice we pass the lua script get-ws-creds.lua. This script will execute before the LDAP auth plugin runs.
http -f http://<Kong_Admin_API_Host>:8001/routes/secure-soap-ldap/plugins name=pre-function config.functions=@get-ws-creds.lua
d. Configure the LDAP Authentication Kong plugin on the route. Here, I've provided a test LDAP connection and query details, which you can modify to suit your LDAP instance.
http -f <Kong_Admin_API_Host>:8001/routes/secure-soap-ldap/plugins name=ldap-auth-advanced config.ldap_host=ldapconfig.ldap_port=389 config.base_dn=ou=people,dc=api,dc=au config.header_type=ldap config.attribute=cn config.verify_ldap_host=false config.hide_credentials=true
4. Verifying in Kong Manager
Once you've used the Kong Admin API to configure the service, route and plugins, you can quickly visualize and verify in Kong Manager what we did programmatically.
5. Validation
Now it's time to test. I will use Kong Studio to test since it can handle SOAP/WSDL in addition to REST and GraphQL, in a single tool.
Let's try first with correct LDAP credentials passed through the WS-S header in the SOAP envelope, and…. it works! The Pre-function plugin extracts the credentials and seamlessly passes it to the LDAP Authentication plugin to check. Once successful, it proxies the request to the upstream Calculator Web Service to return a SOAP response as below.
Now, I'll try with some credentials that don't exist in the LDAP, and I get back an error response with a 403 code.
What Next?
Now that we've successfully and securely proxied an existing SOAP service, we have the opportunity to enforce any of the capabilities that the Kong API platform provides, including but not limited to:
- Rate limiting
- Response caching
- Response transformer (for example, to customize the error response)
You can check out all the plugins that Kong provides at the Kong Hub.
I've left this last step for you to try as per your requirements and creativity. I welcome your feedback.
Summary
In a few minutes, we were able to securely proxy an existing legacy web service and add additional Kong security plugins. Flexibility and ease of use are why Kong is so popular with customers across the world and why it's quickly becoming the de facto solution for their transition to microservices.