A few days ago the preview for the “User delegation SAS token” has seen the light. In today’s post, we’ll take a first glance on this new capability! Though why should we care about this feature? You can now create SAS tokens based on the scoped permissions of an AAD user, instead of linked towards the storage account key. From a security perspective this is REALLY awesome, cause you can harden the scope of a possible even more.
Continue reading “Taking the user delegation SAS tokens for a spin”
In today’s post we’ll go through how you can setup an SPA (Single Page Application) to access the data pane of an Azure Storage account. For this I’ll be using NuxtJS (a Vue.js framework) for my boiler plating, and will rely on the its generic Oauth2 authentication library. The awesomeness here is that the bearer tokens will automatically be injected in your API calls (Axios). Though you can use this post as inspiration on how to get things working in another framework too!
Why this post? It has has been on my personal todo list for a while due to many reasons. One of which is to remove the barrier of using Azure Storage in this scenario. I find that it makes a lot of sense in way too many use cases. Though I must admit we’ve failed to reduce the learning curve in this scenario! You suddenly find yourself in flux between the complexities of AAD and the way how Azure Storage handles the presented JWT tokens. That being said, this is actually the only correct (secure) way of talking from an SPA to Azure Storage. DO NOT use storage keys or SAS tokens in your SPA. It’s like leaving your master keys out on the porch of your house. AAD is the correct way, and actually… With an SPA, the only correct authentication flow is actually Implicit Flow.
Sample Code Repository
If you are looking for the sample code used for this post ; https://github.com/kvaes/TasmanianTraders-NuxtJS-AzureStorageExample
Continue reading “How to talk to the Azure Storage APIs from a Single Page Webapplication (NuxtJS/VueJS) by using AAD (Oauth2 Implicit Flow)”
Last summer I posted about taking a look under the hood of the Azure Active Directory integration for a Linux Virtual Machine. For today, let’s take it a bit further… What if we would want to pre-provision a set of UIDs (User IDs) & GIDs (Group IDs) on a range of virtual machines for cross machine consistency. Let’s say, we would want to make use of an NFS drive and use the same UID/GID across all those boxes. Can we do that with the AAD extension? If so, how can we do it? Let’s hope we can… Otherwise it’ll become a rather short blog post.
This post is based upon my personal experience reverse engineering how this extension works. This is by no means a support statement. If you’re a technical nut (like myself) and want to know how you can tweak this at your own doing… Then this post is for you. 😉
Continue reading “Reverse engineering the “AADLoginForLinux” in order to tweak proactive user configuration”
If you have gone through the typical authentication scenarios, then you’ve probably seen that almost every single one is calling the Graph API. Where that is already cool as such, we’re all probably more interesting in using our own APIs… Today’s post will go through the process of calling -both- the Microsoft Graph API and your own API from the same code base.
Starting Knowledge Assumption
My assumption is that you are already familiar with the basics of Oauth, where you’re aware that a Single Page Application (SPA) is using an “Implicit Grant Flow“. Also be aware that the Azure Active Directory (AAD) v1 endpoint differs from the v2 endpoint in terms of resources & scopes.
In the v1 endpoint, you would target a “resource” in order to get authorization ;
Where the v2 endpoint rotates around the usage of scopes ;
The latter indicates both the resource & the permission that is targeted…
Setup of the day
As our test bed for today, we’re having a Single Page Application that has its own “Application ID” (clientid in Oauth). Which will be linked to two backend APIs; Microsoft’s Graph API and our own
Both our APIs have a given set of scopes that indicate the permissions that a user grants towards these APIs…
Probably everyone can relate that they do not want to invest the time in something “as commodity” as authentication when developing. Though on the other hand, the “identity” part is a key part to keeping your application (and thus your organization’s data) secure. So how to find the perfect fit in terms of this balance? Leveraging identity providers is the typical path to take here. Where there are quite a few in a SaaS service model even. From the Microsoft stables, you can find both Azure Active Directory & Azure Active Directory B2C to play an important role in this space.
When looking in this space, the defacto protocol standards here are Oauth2 & OpenID Connect. Where OIDC (OpenID Connect) is actually a layer built on top of Oauth2. Anyhow, where they provide a very good / robust security layer, the flip side of the coin is that (like with any security product) there is a given entry barrier in terms of understanding the complexity it brings (in terms of authentication flows).
Continue reading “Integration MSAL (Microsoft Authentication Library) into VueJS”
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)”