Azure DevOps Governance 101 – How does Identity, Billing and Service Endpoints intertwine?

Introduction

A common discussion I have had in my role is around the “billing structure” of Azure DevOps. Though the discussion typically spreads out to other topics like identity and service connections for deployment. In today’s post, we’ll go over the general governance structure behind Azure DevOps.

 

High Level Structure

For this, let us start with a complex drawing! 😉

 

As a bit of an introduction ;

  • Azure Active Directory is a component used for identity on both the Azure DevOps side (organization level), Azure Subscription and on the contract level for Role Based Access Control (RBAC).
  • Azure DevOps has the concept of an organization, which can hold multiple projects. The billing & identity part reside on organizational level (marked in red). Where the service connections for deployment (pipelines) resides on project level (marked in green).
  • There can only be one AAD linked to an Azure DevOps subscription. Though you can invite users from another AAD tenant via a typical B2B invite. Thus granting access to users outside of the AAD tenant linked to that organization.
  • There can only be one Azure subscription linked for billing. Though you can have multiple Azure subscriptions linked as service connections for deployment.
  • Multiple Azure DevOps organizations can use the same Azure subscription for billing. This will even allow the scenario of multi org billing.

So far for the basics… Let us now delve deeper into various topics.

 

Billing

Each Azure DevOps organization is linked to an Azure subscription for billing. If you want to learn more on how to set this up, do check out this documentation page.

Next to that, you can also link multiple organizations to the same Azure subscription. Which then provides you with the ability to enable the concept of “Multi Organization Billing“. The advantage is that you can consolidate the user costs across organizations. Where if each organization would have their own Azure subscription, though the same users would be part of multiple organizations, they would need to pay multiple times. This you can mitigate by leveraging the same Azure subscription for billing purposes.

A common question here is the ability the share pipelines across organizations… This is not possible. The number of concurrent pipelines is linked to an organization and cannot be shared across.

 

Identity

Azure DevOps also provides you with the ability to integrate with Azure Active Directory. Want to learn more? Do check out this documentation page.

If you want to invite people from outside of the linked tenant, you can do this via a B2B invite. There is also no relationship with the AAD tenant to the linked Azure subscription for billing, or the one used on the billing aspect of your contract.

 

Deployment

Next to using an Azure subscription for billing purposes… You can also link Azure subscriptions (or other cloud services) via a Service Connection. This connection is the link you can then use in your pipelines. There is also no required link between the Azure subscription used for billing, or the ones used for service connections.

 

Closing Thoughts

As always, I hope this helps! Governance scenarios are common for any enterprise and the setup needed to achieve the most complex scenarios does not make the configurable concepts easier… Though no worries, there is a logic behind it. 😉

Taking the user delegation SAS tokens for a spin

Introduction

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.

 

Bibliography

Continue reading “Taking the user delegation SAS tokens for a spin”

How to talk to the Azure Storage APIs from a Single Page Webapplication (NuxtJS/VueJS) by using AAD (Oauth2 Implicit Flow)

Introduction

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)”

Reverse engineering the “AADLoginForLinux” in order to tweak proactive user configuration

Introduction

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.

 

Disclaimer

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”

Call the Microsoft Graph API -and- your own API from a Single Page (JavaScript) Application

Introduction

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…

Continue reading “Call the Microsoft Graph API -and- your own API from a Single Page (JavaScript) Application”

Integration MSAL (Microsoft Authentication Library) into VueJS

Introduction

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).

Now when looking at JavaScript, it’s safe to say that this language has a significant place in the front-end side of development. There are several JavaScript frameworks that hope to make the life of the developer using it a bit more easy… Where VueJS is one of those. Why pick one over another? It all depends on when you start, and it’s kinda like with religions I guess. There are a big of nuance differences, though in essence they all have the same goal (give or take). 😉 As my personal experience situates itself on the VueJS side of things, this post will cover the VueJS integration.

 

Challenges

Continue reading “Integration MSAL (Microsoft Authentication Library) into VueJS”

Enabling Azure Active Directory support in OpenShift (Origin)

Introduction

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.

 

Prerequisites

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)”

Taking a look under the hood of the Linux VM Authentication

Introduction

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”

Azure Subscription Management – Beyond the 101… aka The Advanced Topics

Introduction

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”

Azure : “My first REST API Call”-tutorial

Introduction

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.

 

Protocol Flow

What’s the flow going to be?

  1. The application does a clients_credential call. Here it’ll provide ;
    1.  it’s application id as a client_id
    2. it’s secret as the client_secret
    3. choose “clients_credentials” as the grant_type
    4. set the “resource” to “https://management.azure.com”
  2. AAD will return an access token
  3. You can now call the API adding an additional header ;
    1. Header Name = Authorization
    2. Header Value = “Bearer *accesstoken*”
  4. 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”