Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops

Introduction

Posts about security are always the ones that make everyone get really excited… Or maybe not everyone. 😉 Anyhow, what is typically the weakest link in any security design? Indeed, the human touch… The effects of this can range from having seen secrets to creating drift (unwanted changes vs de expected baseline). In today’s post, I’ll walk you through an example setup that aims to close some additional holes for you. How will we be doing this? By basically automating the entire infrastructure management with Azure Devops & Terraform. Now you’ll probably think, what does that have to do with security? Good response! We’re going to reduce the points to where human contact can interfere with our security measures. Though we want to do this without putting our agility at risk!

 

Blueprint

For this exercise, we’re going to leverage this blueprint ;

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…

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