What is the correct way to set up a multi tenant app service with custom domain behind an application gateway with path-based routing?

Question

Hello,

I have an app service plan with several apps which are currently accessed through an AGW using path-based routing in the following way:

mydomain.com -> root.azurewebsites.net

mydomain.com/foo -> foo.azurewebsites.net

mydomain.com/bar -> bar.azurewebsites.net

I would like to impose access restrictions on the apps but since I have authentication on "bar.azurewebsites.net" the redirect is to the azurewebsites url rather than mydomain. From reading docs I am under the impression that the answer to this is to use a custom domain for my apps. This also seems to be generally advisable in this scenario to avoid problems with redirects, cookies, headers, etc.

From my reading of this article: https://learn.microsoft.com/en-us/azure/architecture/best-practices/host-name-preservation this should be possible by validating the TXT-record while leaving the A-record pointing to the AGW. However, doing this seems to require purchasing a certificate for end-to-end TLS/SSL instead of using the standard. Alternatively using http for the backend. Is this a correct understanding?

My question is whether this approach would be possible for several apps, i.e. is it possible to let all my apps share the same domain? Or do I need to (or is it a better approach) to create subdomains for my apps? If going with the first approach, how do I ensure the AGW finds the apps through their host name instead of redirecting traffic to itself?

Thanks.

Answer 1

@Erik Magnusson ,

Apologies for the delay in response.

I understand that you wanted to know what the correct way is to set up a multi-tenant app service with custom domain behind an application gateway. If it is possible to let all the apps share the same domain or there is a need to create subdomains for the apps.

Using default domain name and tweaking Application gateway will not work for all scenarios. For example: It may be possible to somehow work with authentication redirect issue using Rewrites but next could be ARRAffinity cookie domain problem. Hence, use of custom domain is highly recommended for advanced configurations on App Services.

Sharing my observations on the 2 custom domain approaches:

Approach#1: Same custom domain for all App services:

As mentioned in the below doc, you can use the custom domain with one web app, say for example www.mydomain.com can be added to one azure web app. In order to use the same domain with another web app, you need to use another subdomain say xyz.mydomain.com but you CANNOT use www.mydomain.com.

https://azure.github.io/AppService/2017/08/08/FAQ-App-Service-Domain-and-Custom-Domains.html

I was not able to make the setup of multiple app services with custom domain behind an application gateway with path-based routing work.

I also discussed this with the Application gateway Product Group team, and they mentioned since "One custom domain cannot be used with multiple web apps", using path-based routing in Application gateway is not feasible.

You can see this blog which shares the similar setup and the disadvantages associated with this setup.

Approach#2: Use different custom domains/subdomains for all App Services:

The best approach would be to create subdomains for your multiple app services and then create respective backend pools for the app services and configure multi-site listeners for each subdomain using individual hostnames or wildcard hostnames in the Application gateway.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview

https://learn.microsoft.com/en-us/azure/application-gateway/configuration-listeners#listener-type

https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview#wildcard-host-names-in-listener

App service configuration:

Use different custom domains/subdomains for all App Services.

root.mydomain.com for root.azurewebsites.net

foo.mydomain.com for foo.azurewebsites.net

bar.mydomain.com for bar.azurewebsites.net and so on..

Application Gateway configuration:

1. Create multisite listeners for each domain/subdomain. Each of these domains should point to AppGW IP.
   • root.mydomain.com
   • foo.mydomain.com
   • bar.mydomain.com
2. Create Backend pools for each app service.
   • root.azurewebsites.net
   • foo.azurewebsites.net
   • bar.azurewebsites.net
3. Do not override "hostname" in the Backend setting.
4. Create Rules for each.
5. You may want to create a custom probe to use "status code matching condition" so that 401 unauthenticated responses don't mark the server as unhealthy.

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.