adaptive.run TECH BLOG

Cloud can be tricky sometimes. Find out what scenarios we've ran into that are worth being mentioned and explained.

Considerations when using Azure Front Door and Identity Server

Level: 200
Publishing date: 06-Nov-2020
Author: Catalin Popa

Azure Front Door can be a great tool to front your Azure web app - it's a powerful combination between WAF, CDN and Traffic Manager. But it might be tricky to configure with some services running on .NET that are hosted on Azure Web Apps and fronted by Azure Front Door. 

That being said, let me present a specific case that I stumbled upon. If you're planning that your app will run identity and access control with the help of IdentityServer, then you've hit the "jackpot" that I am mentioning about.

So, the scenario looks like this: Let's presume you have an Azure webapp which runs IdentityServer and you want that webapp to be fronted by Azure Front Door. Reasons why you would want to do this are many, from having custom routing rules that manage the traffic of your solution to simply having a nice POP network that manage requests of your app (I won't get into the details of why Front Door fronts your Azure webapp - the architectural design here can be a long discussion).






You will notice that with normal configuration, the Identity Server will still make a redirect (302 request) to the URL of the webapp (the .azurewebistes.net), even though you have configured the IdentityServer internal config to point to the custom domain that is configured on the Front Door (and yes, even if you set the PublicOrigin property on the IdentityServer).

This can turn up to be annoying and cause problems, because if you want to limit the access to the webapp so that it can only be accessible through Front Door (by allowing access only to the FrontDoor IP classes), you will end up seeing a 403 - Forbidden message after you input the login credentials, even if you access it through Front Door.



Reason why the 403 - Forbidden is happening? It's exactly that 302 - Redirect I was mentioning earlier. Basically the app "jumps" from custom domain addresses and redirects to ".azurewebsites.net" address, executing it at browser level. That means that the redirect/request will come from your IP (and not from Front Door IPs), thus blocking your access (because you are only allowing Front Doors to access the app).


How to overcome this?

You will need to do some custom configuration so that this request will be handled properly. There are two things that you need to configure:

1. Configure the backend host header in the Azure Front Door backend pool to push the custom domain value:



2. Add the custom domain to point on both resources - on the Front Door and also the webapp that it fronts.
Basically you will need to have the same custom domain on Front Door and also on the web app. If you're wondering how this is possible, I'll give you a tip:

- For the Front Door, set up the custom domain using CNAME records.

- For the webapp, set up the same custom domain using TXT records.


After implementing these two steps, you will find that the browser redirect is no longer happening and that the app will only be accessible through Front Door.

adaptive.run

Transform your business.
Run adaptive.

Contact

Phone: +40 72 444 3842
Email: hello@adaptive.run

© Copyright  2019-2024 adaptive.run- All Rights Reserved