Configuring Azure Application Gateway

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. It is a sophisticated resource comprising of several features such as a reverse proxy, firewall, http listener, backend pool members, http settings and rules for routing traffic to the backend. Configuring the Azure Application Gateway often takes time and effort with the overwhelming number of features and cases to cover. This article explains what to do and what not to do when routing traffic to a backend web application that involves users to login via Azure Active Directory. Such is the complexity of path-based routing, host header-based application redirections and location header rewrites, that this use case is often the most troublesome and requires call out.

When compared to Azure Front Door that offers global load balancing across regions and is preferred for direct connectivity to the internet, App Gateway is suitable for backends contained within a region or is not open to the public internet. Both provide web application firewall and App Gateway provides features such as SSL/TLS termination, autoscaling, zone-redundancy, static VIP, Ingress controller for Azure Kubernetes Service resources, URL based routing, multiple site hosting, redirection, session affinity, websocket, and http/2 traffic, connection draining, custom error pages, rewrite of http headers and URL, and sizing. It is preferable to choose the v2 sku that includes the WAF.

With a normal web application or function application that does not involve authentication and redirect from the Azure AAD login servers, the http settings are typically set for use in path-based routing with the port, protocol, path, timeout, and other parameters specified. The port is typically 443, the path is “/”, the timeout can be 30s and the host header is overridden by “picking a value from the backend pool” which is the web apps default endpoint, say appName.azurewebsites.net.

With the login-based applications that require users to authenticate with Azure AAD, the host header used to specify the redirect conflicts with the requirement of routing all traffic through the gateway. So, after the successful username-password entry by the user, they are redirected to the “appName.azurewebsites.net/” instead of a url based on the application gateway + “/<app-specific-path>”. If the host name override is specified, the path-based routing breaks.

The fix to have users who successfully login to access the app through the application gateway involves writing rewrite rules in addition to path-based routing rules where the location header in those successful login responses is rewritten to replace the appName.azurewebsites.net to application gateway endpoint.  Since all successful responses from the login server for an application redirect have Location header specified, the users upon login are successfully redirected to the web application via the application gateway url and their cookie is set correctly.

Since http settings cannot have both host-header override option enabled as well as disabled for regular and redirected access to the web application, it is suggested to have two sets of settings that map to the backend web application and setup independently one each for the distinct cases of regular and redirected access to the web application. The port associated with an http setting is unique to that setting, so different http settings will require different ports, say 443 and 8443. The web app as a backend pool member of the application gateway can get traffic from either set of rules to cover the regular versus redirected accesses.

The literature says that this combination of path-based routing rule-sets and rewrite based rule-sets can be avoided by using a combined routing that involves host-name pass-through setup such that the application gateway and the web application are put as part of the same web application but those who deploy application gateways know that they might not have control over the creation of a custom domain from the network, so the de facto way is to fall back to path-based routing and cover both the regular and redirected accesses to the web application.