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.
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.
Continue reading “Azure Data Lake Storage (Gen2) : Exploring AAD B2B & ACL hardening”
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!
For this exercise, we’re going to leverage this blueprint ;
Continue reading “Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops”
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”
Last week the blog post “Simplifying security for serverless and web apps with Azure Functions and App Service” was published. In essence, it talks about how you can integrate Azure Functions with Azure Key Vault in order to retrieve secrets and import them into the application settings (being environment variables). You can do this in a secure manner, by providing the Azure Functions platform with a Managed Service Identity, and granting its underlying service principle with (limited: list & read) rights to the Key Vault.
Let’s take a look!
The first thing we’ll need to do, is to enable the “Managed service identity” for our Azure Function plan. Let’s browse to our Azure Function plan, and then select “Platform features”.
Continue reading “Using Azure Key Vault with your application settings (environment variables) powering Azure Functions”
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.
Continue reading “Traffic Light Protocol alike Security Reference Architecture for Azure”
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)”