In this blog post, I’ going to explain what I consider a creative way of exposing on-premises APIs. Let’s envision the following scenario:
You have an on-premises API that is secured using Windows Authentication and for which you need to know the identity of the caller. This API is already consumed by various on-premises consumers and you want to make it also available to online consumers but you want to benefit from throttling and caching capabilities of Azure API Management.
A traditional way of doing this could be by hosting your on-premises API into a DMZ and plugging the APIMGMT to that DMZ endpoint. Another way is using VNETs and VPN techniques to control and establish connectivity. That said, you’d control the connectivity but you should still be able to control identity as per our scenario, this is a pre-requisite for your backend API to know the identity of the user consuming it (via an App).
Therefore, what you could do is the following:
- Publish your on-premises API as an Azure AD Proxy Application (enable KCD, install the proxy connector and configure the app in AAD). This step will result in an External URL (public facing) that will be mapped to your on-prem API.
- Extract the Swagger definition of your on-premises API and publish in APIMGMT through the publisher portal but use the AAD Proxy App endpoint instead of the on-prem one.
- Subscribe to the published API and start consuming your on-prem API though the APIMGMT Gateway that will itself take the AAD Proxy gateway route
Overall, you’ll end up with such an architecture:
Offering some benefits:
- No need to deal with network constraints.
- AAD Proxy connector only requires outbound traffic so no need to put the API hosts within a DMZ nor to enable inbound traffic.
- Protocol transition between OAuth & Kerberos is handled by the connector (providing you configured KCD correctly and you provide the right SPN to be used by the connector)
- You benefit from APIMGMT throttling and caching capabilities as well as all the other features such as analytics, subscription mechanism (which isn’t mandatory BTW), etc.
So it’s a creative way of enabling a microservices architecture as the same backend API could be divided into smaller APIMGMT services with a total control over your consumers & resources.