In today’s post we’ll go through the steps to get Azure Active Directory (AAD) integrated in RedHat’s OpenShift. So that we can use the AAD identity we all love in OpenShift too.
For the next steps, I’m assuming you already have an OpenShift deployment up & running. If not, check out this repository!
Continue reading “Enabling Azure Active Directory support in OpenShift (Origin)”
Today we’ll do a deep-dive into how you can log into an Azure Linux VM with Azure Active Directory (AAD). In essence, we’ll go through the following documentation flow, and then take a look how that looks under the hood.
Part one : “Creation”
The part on creating & integrating the VM is VERY straightforward…
- Create a resource group
- Create a Linux virtual machine
- Add the “Azure AD login VM”-extension
And that’s it! Really, that’s it…
Continue reading “Taking a look under the hood of the Linux VM Authentication”
Today’s post will cover three more advanced topics that I’ve seen surfacing on a regular basis ;
- Transferring a Subscription versus Changing the Directory of a Subscription
- Moving resources between subscriptions with different AAD (Azure Active Directory tenants
- Understanding the relationships between components when leveraging an Enterprise Agreement (EA)
- Various advanced scenarios on how AAD in intertwined between subscriptions & the EA
Transfer vs Change Directory
Apparently there is a bit of confusion between the “Transfer” and the “Change Directory” buttons for a subscription ;
In essence ;
Transfer Subscription = Change the Owner AND Change the Directory
What does that mean?
- If you want to transfer the billing of a subscription, you do a “Transfer“.
(Do note: Transferring a subscription will also change the directory to the one linked to the new owner. If this is a different one, then you’ll be linked to a new AAD Tenant.)
- If you do not want to transfer the billing, and just change the directory, you do a “Change directory“.
(Do note: Changing a directory will not remove the account owner. And (s)he’ll still have owner rights on it! Also be aware that all rights set linked to the previous tenant will disappear. So you’ll have to reinstate IAM. For which you can easily leverage management groups...)
Continue reading “Azure Subscription Management – Beyond the 101… aka The Advanced Topics”
For today’s post, we’re going to do a REST call towards an Azure API. For this we’re going to create a “Servce Principal” and afterwards use the credentials from this object to get an access token (via the Oauth2 Client Credentials Grant) for our API.
What’s the flow going to be?
- The application does a clients_credential call. Here it’ll provide ;
- it’s application id as a client_id
- it’s secret as the client_secret
- choose “clients_credentials” as the grant_type
- set the “resource” to “https://management.azure.com”
- AAD will return an access token
- You can now call the API adding an additional header ;
- Header Name = Authorization
- Header Value = “Bearer *accesstoken*”
- The API will return a response
(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service )
Now let’s see how that would look in reality?
Continue reading “Azure : “My first REST API Call”-tutorial”
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)”
From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…
Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!
Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉
Continue reading “Azure : Pushing Azure Resource Manager Templates through a CI/CD (release) pipeline with Visual Studio Team Services”
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”