Jump to content
Microsoft Windows Bulletin Board

Recommended Posts

Posted

From our own metadata and experience at Microsoft, we know that a considerable number of our customers use App Service behind one of our reverse proxy solutions, such as Azure Application Gateway or Azure Front Door.

In simple terms, this means that when our customers have an App Service, it often runs as part of the backend pool of an Azure Application Gateway or is configured as the origin in an Azure Front Door profile, which is great because this setup is beneficial for several reasons.

Firstly, it enhances security by obfuscation. With a reverse proxy in the data path, clients only contact the reverse proxy instances and are unaware of the second connection between the reverse proxy instances and the real backend. This unrevealed internal architecture reduces the attack surface for malicious actors.

Secondly, the reverse proxy can act as the TLS termination point, offloading the TLS handshake, encryption, and decryption from the App Service. This reduces the TLS computational load on the App Service and simplifies the management of TLS certificates, through Key Vault.

Thirdly, the reverse proxy can load balance and distribute incoming client requests across multiple backend servers or origins, improving performance and ensuring no single server is overwhelmed, making scalability attainable.

Finally, if Azure Front Door is used as the reverse proxy solution, it can also act as a cache, reducing the load on backend servers by serving content directly from the reverse proxy POPs (Point of Presence) servers, which improves response times for users, as the content is served directly from a location closer to the user, which is faster than contacting the origin.

As we can see, using a reverse proxy like Azure Application Gateway or Front Door before an App Service, seems very convenient, but there is a drawback: maintaining session affinity and authentication can be challenging if custom domains are not being used in the App Service configuration.

This is because in a reverse proxy scenario, instead of one connection we have two: one between the client and the reverse proxy, and another one between the reverse proxy and the backend / origin and maintaining the original information across those different connections is a challenge.

What is the problem that we are trying to resolve with the new "Session Affinity Proxy" setting?

When employing a reverse proxy to front App Services, clients typically utilize a custom domain that directs to the proxy´s IP address, while communication between the proxy and the backend App Services occurs via the default App Services domain name. Although this configuration is generally effective, it may present challenges when employing advanced configurations such as Session Affinity or Authentication within App Services (explained further in this article). To address these issues and ensure that an App Services deployment is reverse-proxy aware -utilizing the same domain name requested by the client to the proxy- a new configuration was recently introduced, beggining with Session Affinity cookies.

First, let´s clarify what "Cookie-Based Affinity" Means.

A "Cookie Based Affinity," also known as a "sticky session" or "session persistence," is a technique used to ensure that a client's requests are always sent to the same server. This is particularly important in scalable environments where web servers instances are added dynamically and hosted applications store user data in session variables or in a local cache, commonly referred to as a stateful application.

Therefore, maintaining the "Session Affinity" is crucial for stateful applications that can use cookies to store important session information. If we send the request to a server without the stored sessions variables, the application logic can break, session state can get lost, authentication can fail, or back-end URLs can inadvertently be exposed to end users. 

Why maintaining "Session Persistence" challenging in scenarios with an App Service behind a reverse proxy without custom domains?

Let´s use below diagram as an example for further explanation.

In this diagram, we need to consider that Session Affinity (ARR) in App Services is enabled

When the clients send the request to Application Gateway or Front Door (1), they send it with a host value in the request header equal to "constoso.com", that is different from the hostname configured in the backend "contoso.azurewebsites.net" (2).

The HTTP Response from the backend (3) includes affinity cookies with a default domain name of "contoso.azurewebsites.net" (ARR enabled in the configuration of App Service) that differs from the original one "contoso.com".

Due to security reasons, clients do not accept a cookie with the default domain name "contoso.azurewebsites.net" in the response (4) because its domain differs from the original, and therefore the "sticky session" is not maintained and the stateful application is broken.

The new "Session Affinity Proxy" setting to the rescue

For solving the problem that we have described above, we are introducing the "Session Affinity Proxy" setting in the App Service configuration.

This is the portal view of the new setting:

And you can also enable it via az cli:
az resource update –name <app-name> --resource-type "Microsoft.Web/sites" -g <resource-group-name> --set properties.clientAffinityProxyEnabled=true
This new property is available for the following services

  1. Web App
  2. Functions /Logic Apps (Standard)

The new App Services property "clientAffinityProxyEnabled" that you set when you choose from the Portal "Session affinity proxy: On", in the configuration of a Web App, Function, or Logic App (or when you activate it via CLI)  is a boolean setting that provides an out-of-the-box experience by setting cookie domain name based on incoming requests as seen by Application Gateway/Front Door.

The following illustration demonstrates how this new solution works:

As you can see when we enable the setting, we are sending the original domain (as seeing by the client) from the reverse proxy to the backend.

As we know the original value, we are capable when we sent the HTTP Response from the backend to includes affinity cookies that contain the original hostname (contoso.com) rather than the configured one (contoso.azurewebsites.net) and therefore these cookies are not going to be rejected by the clients as they contain the expected hostname.

This is a straightforward configuration that resolves the problem of "Cookie Based Affinity" and allows to work without custom domains configured on the App Service.

Before this setting was introduced, our recommended solution was to use always custom domains as per this documentation, but with the new configuration setting "Session Affinity Proxy: On", we have a solution that just work with one click and reduces the complexity of configuration for our customers.

This simplifies the process significantly and provides a seamless experience for users, eliminating the need for additional setup while ensuring consistent session affinity.

View the full article

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...