blog/secure-app-service-with-easy-auth-and-app-gateway-public/

[giscus[bot]]

blog/secure-app-service-with-easy-auth-and-app-gateway-public/

Exploring Cloud concepts with Chris Reddington (Welsh Tech Geek, Cloud Advocate, Musical Theatre Enthusiast and Improving Improviser!). We will regularly invite guests to talk about their experiences with the cloud and hear about some of the lessons learned around their cloud journey. Cloud with Chris is a community-driven personal podcast. Content from episodes do not represent the views of any company or organisation.

https://www.cloudwithchris.com/blog/secure-app-service-with-easy-auth-and-app-gateway-public/

[chrisreddington]

Want to join in the discussion? You can do that in two ways! You can either authorize the giscus app to post on your behalf using the GitHub OAuth flow. Alternatively, you can comment in GitHub Discussions directly if you'd prefer not to grant access to the giscus app.

Please keep the discussion on topic with the post.

[xaviermignot]

Hello Chris, thanks for this post, I had to fulfill the same requirements so I have read this post several times over the last few days :)
My situation was a little bit different as I'm using Terraform so doing all of this in "one shot" was another challenge, especially if I want to add later another Web App in my project.

Anyway I still have a question to this day regarding the Azure Managed certificates that we use to secure the traffic between Application Gateway and App Services. In the process described in this post, we first create a CNAME record when binding the App Service to the managed certificate, and later we replace this CNAME record by an A record pointing to the Application Gateway's public IP.
In the Azure docs there is a mention that the CNAME record is mandatory, so I'm wondering if you had any issue later as you have removed this CNAME record. I'm thinking about certificate renewal issues as the managed certificates are renewed every 6 months so you probably have reached this date since the writing of this post ^^

Many thanks in advance and thanks again for sharing this post ;)

[chrisreddington]

Thanks for commenting Xavier, I'm glad that this was helpful 😊

I actually deleted the app not long after writing the post, and working through the scenario.

I think the docs would trump any community Blog post, so would be best to follow the recommendations laid out there. Would be great to hear how you get on though!

[xaviermignot]

Well, there is this one line in the doc page linked in my previous comment:

Is not supported on App Service not publicly accessible.

So I guess I need to rework my code to use an external certificate (a non managed one) between the Application Gateway and the App Services. This scenario is an endless source of joy, I have enough material to write an entire series of blog posts :O

[mirecad]

Hello, I use almost identical solution for my app services, but without easy auth. I don't like checking 401 as health check. I am monitoring detailed status of my /health endpoint for example for degraded state etc. This would not be possible with easy auth without anonymous login enabled. But on the other hand I like the concept of preauthentication. It would be nice to bypass auth for some urls like /heath. Do you think this is possible? I was not able to find a solution for this yet.

[xaviermignot]

Hello, not using Easy Auth will require more work, but will give you more control. As you will have to update your code to handle authentication the solution will depend on the language/framework you use, but I'm pretty sure any stack will allow you to bypass authentication on some routes.
For instance ASP.NET Core does this using attributes on the routes to bypass the default policy. I also think that Health Checks do not use authorization by default unless you specify it using a dedicated method.

[mirandaasm]

Awesome article. We have a similar setup, but we did extended things little bit further. For instance, we had to switch into "File-based configuration" of the EasyAuth module on the App Services we use as the backend of our Application Gateway, so that we could achieve two critical requirements:

1- Add "Exclusion Paths" for the App Services that we use as our backend, so that we could have an entrypoint for our real HealthCheck implementations, as well as some other "well-known" public files that should be exposed/served anonymously;

2- Set the "Forward Proxy" options of the "EasyAuth" module on all of our App Services. This is more than a requirement for us, since we have a lot of "path-based" rules at our Application Gateway, using a single custom domain name as the "public entrypoint", and they all point to multiple different App Services as backends, depending on the matching "path-based" rule. With a setup like this, we obviously couldn't add the Application Gateway's custom domain name into all of our App Services, as Azure wouldn't allow that. Only one App Service can have that custom domain name configured. So, to make it work properly without having to add that custom domain name into our App Services, we had to set the "forwardProxy" option to { "convention": "custom", "customHostHeaderName": "X-Original-Host" }. This way, the Application Gateway forwards the requests to App Services using their own "azurewebsites.net" domain name, but the "EasyAuth" module builds the redirection URIs used at the authentication flow using the hostname present at the "X-Original-Host" HTTP header, which is always injected and sent by the Application Gateway;