As a consolidator for traffic to Azure application services,
the Azure application gateway is empowered to be both a revere proxy and a
firewall in addition to being a load balancer for the web applications. This
enables it to rewrite the host header which informs the location of the source.
Developers sometimes wonder when it is a right choice to preserve the original
HTTP host name between a reverse proxy and its backend web application versus
rewriting the location header. This article summarizes existing documentation
from those products.
The App Service is a multitenant service, so it uses the
host header in the request to route the request to the correct endpoint. The significance of the original host header
is that it is universally understood to be the internet domain name that was
used by the browser to send the request towards the gateway and the service
behind it. In some scenarios, the original host value can get changed by say a
reverse proxy or some handler in the request chain. A reverse proxy can close a
client network session and set up a new connection to the backend. Proxies can
duplicate the original header name to some other header such as forwarded for
but the backend needs to change to read from this other header.
The default domain name of the App Services,
*.azurewebsites.net is different from the application gateway’s domain name.
The backend App Service is missing the required context to generate redirect URL’s
or cookies that align with the domain as seen by the browser.
The production-recommended solution is to configure the
Application Gateway and App Service to not override the hostname. Custom domain
names can be given to both the Application Gateway and the App Service in the
backend. This helps to avoid the
reliance on the default *.azurewebsites.net and requires only a custom domain
and associated certificate. When the same domain name is associated with both
the Application gateway and app service in the backend pool, the request flow
does not need to override the host name. The backend application will see the
original host as was used by the client. The DNS configuration for the custom
domain name will remain directed towards the Application Gateway. The TLS
binding for App Services must be configured to accept connections using a
custom dns name. The certificate for the custom domain can be pulled from the
Azure Key Vault.
Another option is to have the application gateway access the
App Service using its default domain suffixed as “.azurewebsites.net”. The default domain is preconfigured to route
traffic to the deployed instance. For app service, this default domain is azurewebsites.net.
Each web app gets its own subdomain.
Potential problems that can arise from not preserving the
host name might include incorrect absolute URLs, incorrect redirect URLs,
broken cookies and such others. If the original name is not preserved and the
app gateway uses absolute URLs to reach the backend, these backend domain might
be disclosed to the end user. This
allows the client to bypass the application gateway and reach the app services directly unless the app service
restricts the caller to be only the gateway.
A common and more specific use case with these absolute
redirect URLs is when they are passed to the identity servers by the client
which then bypasses the application gateway. Leveraging the app services
authentication and authorization capabilities avoids this.
A host name mismatch can also cause potential problems when
the app service issues cookie that uses the incoming host name to construct the
domain name of the cookie. In this case, the browser stores the cookie for that
specific domain rather than the domain of the gateway that the user is actually
using.
After these implications are assessed for the specific
deployment, the location header can still be rewritten with the application
gateway’s domain name by creating a rewrite rule with a condition that
evaluates if the location header in the response contains azurewebsites.net and
include the application gateway’s host name.
No comments:
Post a Comment