Issues implementing: Protect APIs with Application Gateway and API Management

Question

Hi, we are having issues implementing the solution described here:

https://learn.microsoft.com/en-us/azure/architecture/web-apps/api-management/architectures/protect-apis

Application gateway WAF is now deprecated and needs to be WAFv2.

Is it possible to implement the solution without using custom domains, but to use the build-in azure domains ? (only have custom domain on the application gateway ?)

I could deploy this solution with a few fixes. It seems that the solution is old and not working anymore without the fixes. https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/web-application-firewall/ag/configure-waf-custom-rules.md

I added a priority on $rule1 and removed the parameter -WebApplicationFirewallConfig to create the gateway. I am not sure if it is a viable solution in this state. Also, editing the gateway afterwards with the Azure console to change minimum instance count to 1 fails.

Would it be possible to combine both solution to protect my APIM ?

Please advise the next steps in support.

Regards,

Simon

Answer 1

Hey @Simon Guertin

In the interim (whilst the docs are being looked at)

You don't technically need to have the same hostheader front to back - however it's recommended to do this and the only way to do it is using a custom domain.

For an API that will be accessed from the internet:
You need a public DNS resolvable domain name pointing to App Gateway's public interface (VIP) either through an A record or preferred a CNAME

You can configure App Gateway to overwrite the existing hostheader sent by the client (matches the public DNS resolvable name) to the MS owned domain for the backend (could be the default domain available for APIM)

But, doing this can later cause problems for oauth and cookies etc, because the client app/browser will think it's communicating to the public hostheader but the backend web app / API will be listening on another host header which doesnt match.

For an API that will be accessed internally:
Here it's a bit easier because you can use your own DNS and custom host name. You can point your applications at the App Gateway internal interface IP. You can again use different host name for the client and have App gateway overwrite that to the default azure host name for the resource you're proxying. However the same caveat applies as above.

The WAFv2 can be setup on the App Gateway and this will work with APIM - but make sure you understand which rules and features are adding value. APIs dont always have the same vulnerabilities as web apps.

Note: Usually when customers use App Gateway with APIM it's because they have dual modes. They want internal users to access some APIs, but also electively open APIs to the public too. In this scenario App Gateway can be used to route just to the API suffix (first path segment) of the APIs you choose to externalise. This scenario requires APIM premium , VNET attached in internal mode (listens on the private IP only, the public IP is currently retained in internal mode for control plane traffic only)

The other , probably less common use case, is for APIM to be public but to use App Gateway and the bot protection available with the WAF. You dont need APIM premium for this , unless the backend is on a VNET/Linked network and not otherwise publicly accessible