A few months ago I did a post on using PHP to connect to the Azure management API. And a week ago I did a demo on how to secure a “classic” webapp with Azure Active Directory. Today we’ll look how to secure a single page webapp by using Azure Active Directory. For the post of today I’ll be using two webapps ;

Front end ; a small webapp based using AngularJS

Backend ; also a small webapp based on PHP, which will serve the API calls made from the front end

Why does this kind of setup differ from a “classic” approach? With single page apps, we see a very clear segregation of backend & front end. When the backend & front end are combined, we often see more simple mechanisms used, often based on session information. When the two are clearly separated, we’ll need to authenticate to both individually… I’ve often seen the error where organizations just protect the front end, as this is where the user logs in. And they forget to secure the backend API… An unsecure API means that everyone who can access that API will be able to retrieve (or delete/adjust) the data served by that API. Let that one sink in!

Flow of the day

So what will we be doing today?

A user access our front end

If the user is not authenticated, (s)he will be redirected to Azure Active Directory (AAD) to login

AAD will redirect (on success) with an authorization token

We’ll inject this authorization token into the calls made to the backend (to prove your identity)

The backend API will validate the authorization token and verify it against the issuer (AAD)

Earlier this week I migrated “storage.kvaes.be” towards Azure. It was long due… Though I was determined to change the backend to Azure Table Storage. Are the better setups for this? Yes there are! Though I wanted to get myself a bit more familiar with the table storage from PHP. So I thought it was a nice test. 🙂 Anyhow, for the actual data migration I used a combination of manual mutations & data factory. I’ve already used the Azure Data Factory a few times before, and it always pleases me.

That brings me to today’s post, where I’ll do a quick run through how you can use Azure Data Factory for the migration of your MySQL database towards an Azure SQL Database (or any other support target).

In the previous post I showed you how you can protect any web app without altering code. Now what if you want to go a bit further in terms of authorization? Today we’ll take a look into this capability.

Here we can see if the azure web app thinks we are logged in or not. It also presents us with the opportunity to login to an identity provider of our choice and afterwards logout. In addition, you are presented with all the header information as the web app receives from the underlying platform (being Azure Webapps).

Sometimes we come across applications that needed some basic form of protection, but (sadly enough) the code base did not allow it. Today we’ll see how we can enable authentication / authorization on your web app, -without- altering any code! We’ll be doing this capability from the web app service itself, without the code noticing anything of this.Enable / Configure the Azure Active Directory Authentication

Let’s start by doing to our web app and looking for the “Authentication / Authorization” section.

We’ll enabling the “App Service Authentication”. As we do not want guests, we’ll select “Log in with Azure Active Directory” as a way to force authentication. Next up we’ll configure the Azure Active Directory ;

In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?

We’ll be creating a kind of service user in Azure which Terraform will use to log in.

We’ll be authoring a small configuration file that will serve as the input for our network

Up in the Clouds

Views are my own

The content of this blog will, at all times, portray my own views. At no time will this reflect the views of the organization I am linked to. Neither can the information provided be used as support statement.