Today’s blog post will be how you can leverage the authentication scenario of a Daemon, Service User or Server Application when our application/API is using Azure Active Directory for its authentication flows.
“An example of a daemon application is a batch job, or an operating system service running in the background. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.”
In essence, a “daemon application” will do a “clients credentials grant” whilst using an Azure Active Directory Service Principal. The “application id” of the service principal will serve as the “client_id” and a generated “secret” will service as the “client_secret”.
In addition to this, we want our application to grant permissions (authorization & identification) based on the group memberships of Azure Active Directory. Where this is pretty straightforward for our basic user objects. This requires a bit of attention when wanting to achieve the same for our service principal.
Continue reading “Azure Active Directory : Group integration for daemon / server applications (aka Service Principals)”
For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).
High Level Setup
So what will we be setting up & testing today?
The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp. You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.
Continue reading “Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!”
For today’s post, we’ll be deploying a java web-app to Azure. Here we’ll be leveraging our well-known “App Service” as the underlying PaaS component to host our web-app.
Sample Workload : Geoserver
For today’s example, we’ll be using “geoserver” as the grounds for our little proof-of-concept. In addition, we’ll even trow in the Azure PostgreSQL Database for the back-end store.
Continue reading “Azure App Service : Deploying a java webapp (geoserver) to Azure”
In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.
High Level Architecture
VMchooser has the following high level architecture ;
- Web App : The front-end of the application is hosted on an Azure Web App.
- Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
- Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
- Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
- Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
- API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.
Continue reading “The anatomy of “vmchooser”… Adding some serverless into the architecture!”
In my previous post I talked about integrating Azure MySQL with a PHP webapp. Today we’ll elaborate on that one a bit further and see how we can setup CodeIgniter to use the Azure MySQL.
Prep the webapp
First thing, set all your database variables as app settings (read: environment variables) ;
That’s it as preparation 😉
Continue reading “Setting up Azure MySQL with CodeIgniter by having SSL enforced”
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)
Continue reading “Single Page Webapp : How to secure your app and your API with Azure Active Directory”
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.
For today’s demo, I’ve created a small web app ;
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).
Continue reading “Demo : Azure Webapp Authentication Integration”