Azure Data Lake Storage (Gen2) : Exploring AAD B2B & ACL hardening

Introduction

In the summer of 2018, the 2nd generation of the Azure Data Lake Storage was announced.  In today’s post, we’ll delve into the authentication & authorization part of this service. We’re going to see how we can leverage AAD to tighten security around our Data Lake.

 

Use Case

To help us in this storyline, we’ll be looking to solve the following use case. A customer has stored a lot of data on its Data Lake, and is looking to provide a “partner” access to a subset of the data. In this use case, what would we need to to to achieve this goal?

 

Azure Data Lake Storage : Access Control Model

The first part of our puzzle is looking at the “Access Control Model“… In essence there are four ways to provide access to the data lake ;

• Shared Key ; The caller effectively gains ‘super-user’ access, meaning full access to all operations on all resources, including setting owner and changing ACLs
• SAS Tokens ; The token includes the allowed permissions as part of the token. The permissions included in the SAS token are effectively applied to all authorization decisions, but no additional ACL checks are performed.
• Azure RBAC ; Azure Role-based Access Control (RBAC) uses role assignments to effectively apply sets of permissions to users, groups, and service principals for Azure resources. Typically, those Azure resources are constrained to top-level resources (e.g., Azure Storage accounts). In the case of Azure Storage, and consequently Azure Data Lake Storage Gen2, this mechanism has been extended to the file system resource.
• ACL ; And last, but not least, we have the access control list we can apply at a more fine-grained level.

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

Traffic Light Protocol alike Security Reference Architecture for Azure

Introduction

The way how organizations categorize/handle classified information can vary significantly. Where it can go from about 6 categories towards a more “limited” set of 3 to 4 categories. Where you see that some government organizations have even tried to reduce this in an effort to make it more accessible.

 

So for today, we’ll be looking at how we can handle sensitive/classified information in Azure. And to ensure you that you Azure implementations can facilitate sensitive data.

 

Side Story : Security should be like a roundabout

Though I don’t remember which conference talk it was… One visual has always stuck with me when talking about security. Imagine security like road infrastructure. Having a complex situation might be needed at times, though it will increase the risk that the drivers (~users) will make mistakes.

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

Single Page Webapp : How to secure your app and your API with Azure Active Directory

Introduction

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?

1. A user access our front end
2. If the user is not authenticated, (s)he will be redirected to Azure Active Directory (AAD) to login
3. AAD will redirect (on success) with an authorization token
4. We’ll inject this authorization token into the calls made to the backend (to prove your identity)
5. The backend API will validate the authorization token and verify it against the issuer (AAD)

 

Demo : Azure Webapp Authentication Integration

Introduction

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.

 

Demo Outline

For today’s demo, I’ve created a small web app ;

• Demo URL ; https://authdemo.kvaes.be/
• Source Repository ; https://github.com/kvaes/Azure-Webapp-Auth-Example

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

Protecting your webapp with Azure Active Directory WITHOUT adjusting any code…

Introduction

Sometimes we come across applications that needed some basic form of protection, but (sadly enough) the code base did not allow it. Today we’ll see how we can enable authentication / authorization on your web app, -without- altering any code! We’ll be doing this capability from the web app service itself, without the code noticing anything of this.
Enable / Configure the Azure Active Directory Authentication

Let’s start by doing to our web app and looking for the “Authentication / Authorization” section.

We’ll enabling the “App Service Authentication”. As we do not want guests, we’ll select “Log in with Azure Active Directory” as a way to force authentication. Next up we’ll configure the Azure Active Directory ;

Azure : Using PHP to go all oauth2 on the management API!

Introduction

As a hobby effort, I wanted to create a small poc where any user would be able to login with their AAD user, grant access to an application, after which that application could query their subscriptions.

In all honesty, I’ve been struggling more than I like to admit with getting this working… So this post will cover all the steps that you need to do to get this working!

 

Oauth & Azure AD

Before getting our hands dirty, read up on the following post ; Authorize access to web applications using OAuth 2.0 and Azure Active Directory

Ready it thoroughly! To be honest, I didn’t at first and it cost me a lot of time. 😉

Anyhow, the flow looks as follows…

So basically;

• We’ll redirect the user to sign-in (and if this hasn’t been done, grant our application access)
• If all went well, we’ll receive an authorization code
• We’ll use this code to get a bearer (and refresh) token
• Next up we’ll use the bearer code to connect to the Azure REST API for getting the list of subscriptions for that user.