Azure offers a great platform for multiple types of apps and services, Web Apps are one of the PaaS service, we are using much. In some scenarios, it makes sense to host a static website on Azure, but to restrict access just for authenticated users. Well, AAD can help you with that by demanding a successful login with an Office 365 account. See how this works here.
My sample static website
My sample works with an Azure DevOps task that automatically generates a HTML website from a source control repository, processes the web with Jekyll in a container and saves the generated HTML artifacts to an Azure website. So, I picked a Jekyll Theme and started a documentation with Markdown files in Visual Studio Code. Then, I push the changes to my Azure DevOps repository and the build process generates the web in Azure. (That's material for another article sometime.) Anyway, in the end there exists a static HTML website in an Azure web app that can be accessed with the https://<website>.azurewebsites.net/ address.
My generated static website looks as here, you can see it's *.html files only (along with some .js, .css and images) and no dynamic webpages.
The goal is to protect that website so that users need to login with their Office 365 login.
Secure it with AAD and create an app
So, let's create an app in my Azure Active Directory (AAD). The app type is "Web App/API", with a custom URI and the home page URL pointing to the Azure website as here. I need to set Multi-tenanted to "On".
Also, the Reply URL must be provided in the Settings. I added
/.auth/login/aad/callback to the web URL as here. This means that, after a successful login, a redirection to that URL is happening.
When created, I need the Application ID. The app properties overview shows the most relevant data and the Application ID can be copied from here.
Secure the web
In the web`s Authentication / Authorization page, we set the App Service Authentication to "On" and configure the web app to use AAD with our Application as here.
The registered Application ID from above must be provided here. Open the "Advanced" mode and paste it in the "Client ID" field.
Ok. We`re done with the configuration in Azure.
Agree to the consent as Administrator
This step is important (and this was my stumbling block). Since I did not consent as Administrator, other users could authenticate, but could not open the website. Google and my colleague Waldek Mastykarz helped out with the article Configuring multi-tenant authentication with Azure App Service authentication options. In that article from 2016, Waldek pointed out – if not automatically asked for consent – that you can force that behavior. So, this sentence solved my issue: "The consent flow can be triggered by adding &prompt=consent to the Azure login URL." Thanks a lot, Waldek!
So, in my case I had to add that parameter to the generated login URL which started similar as here:
Then I signed in with an Administrator and accepted the consent on behalf of my organization.
The website is secured now
NOW, users with any Office 365 account can open that website. So, when a user opens the website, he gets redirected to the sign-in page. Once signed-in with a personal Office 365 account, the app asks for permission to sign-in. As we see here, PattiF with her Office 365 tenant needs to grant access to the Multi tenant app "d365docs" that is stored in the "atwork.at" AAD and wants to sign-in.
So, the user needs to accept that consent to continue. Now, the website is shown. Otherwise, the user does not get access to that website.
Mission accomplished to secure a static website without any custom development! Another benefit of working with Azure.