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).
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>
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
The Lua script below, which I saved as get-ws-creds.lua:
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
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.
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.
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:
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.
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.
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
In my previous post, we discussed how we can implement a basic AI Agent with Kong AI Gateway. In part two of this series, we're going to review LangGraph fundamentals, rewrite the AI Agent and explore how Kong AI Gateway can be used to protect an LLM
This is part one of a series exploring how Kong AI Gateway can be used in an AI Agent development with LangGraph. The series comprises three parts: Basic ReAct AI Agent with Kong AI Gateway Single LLM ReAct AI Agent with Kong AI Gateway and LangGr
What Is RAG, and Why Should You Use It? RAG (Retrieval-Augmented Generation) is not a new concept in AI, and unsurprisingly, when talking to companies, everyone seems to have their own interpretation of how to implement it. So, let’s start with a r
In February 2024, Kong became the first API platform to launch a dedicated AI gateway, designed to bring production-grade performance, observability, and policy enforcement to GenAI workloads. At its core, Kong’s AI Gateway provides a universal API