This is a long read and I spent a pretty long time going through videos and articles compiling this into one post. Not something I would have done usually. But I do think that sometimes having it all in one place is easier to access than splitting into multiple articles. I hope the TOC helps group things.
Azure AD is Microsoft’s cloud-based identity and access management service.
Lots of words. But do they make sense?
What is Active Directory
Active Directory is a directory service developed by Microsoft.
I know, that’s terrible definition.
What is a directory service
In computer science, a directory service or a name service is a map of the names of resources connected to a network, to their respective network addresses.
A directory service defines a namespace for a network. Anything within that namespace has a unique identifier. That allows other devices in the network to uniquely identify it within the network.
Active directory is Microsoft’s implementation of a directory service that supports the LDAP protocol and provides functionality like authentication, group or user management, policy administration etc.
What is identity?
Identity defines who a person is, or qualities of a person or group that make them different from others
That definition is pretty much spot on in technology too.
What problems do modern identity apps solve
- Cloud based
- Supports authentication and authorisation for:
- users
- devices
- applications
- Highly scalable
- No single point of failure
- Built for distributed systems
- Secure and resilient
And that is also what Azure AD promises.
Looking at Microsoft’s authentication tech
Microsoft as a brand was founded back in 1975! So as a company it has a pretty long history and when it released its operating system, it started thinking about security.
Once upon a time Microsoft implemented the Domain controller based on kerberos. This was great for on-premises authentication.
With Azure AD, the on-premises identities are synced to the cloud and back letting the same identities work in both places.
All of this is made possible because Microsoft has implemented popular standards that are used for authentication under the hood of Active Directory. It did not invent a new auth mechanism.
Microsoft Authentiation on Azure Portal
When you head to portal.azure.com and sign in using your microsoft id - an email address based on live or outlook with a .com or .co.uk, you are allowed to view a portal with no subscriptions.
This I didn’t know until today. I thought I had to get at least one subscription before I could use the portal. Thanks to a tutorial video I watched today.
Also for the purpose of creating an Azure Active Directory, you do not need a subscription. You just need to be able to log in to the portal. The free version obviously has limitations but will help you understand the basics.
Create an Azure Active Directory
- Find the Azure Active Directory link in the navigation bar after you log in to the portal.
- When the following page loads, go ahead and find the
Create a directorybutton. choose the basic option for the sake of testing. - Fill the details: organization, initial domain name, country/region
- The domain name has to be unique, by default, for free, it gets created with
yourdomainname.onmicrosoft.com
- The domain name has to be unique, by default, for free, it gets created with
Example:
Terminology
| Term | Definition |
|---|---|
| Identity | A thing that can get authenticated. An identity can be a user with a username and password. Identities also include applications or other servers that might require authentication through secret keys or certificates. |
| Azure subscription | Used to pay for Azure cloud services. You can have many subscriptions and they’re linked to a credit card. |
| Single Tenant | Azure tenants that access other services in a dedicated environment are considered single tenant. |
| Multi Tenant | Azure tenants that access other services in a shared environment, across multiple organizations, are considered multi-tenant. |
For a full list of terms and definition head to Microsoft Docs
User Authentication in Azure AD
Azure AD supports the following methods for a user to be authenticated
- Interactive logon
- Managed in either Azure or On-premises
- Role based access control
Try it out. Create a user in your Azure Active Directory.
App Management in Azure AD
Azure AD can help manage your applications.
- single tenant
- multi tenant
- of the shelf enterprise apps
How does this work?
When you have to manage app authentication using Azure AD you have to register your app with Azure AD. These applications are called specific things in Azure AD
| Term | Definition |
|---|---|
| Public Client | A client that is accessible by a random user on their machine is a public client |
| Confidential Client | An app running on a virtual machine, serverless app, API etc |
| App Registrations | The section in Azure Active Directory where you manage your applications existing registrations |
| Enterprise Applications | A special type of application, made available by either your own organisation or a third party. You can find several applications like Docusign, GSuite, Github.com, Dropbox etc. You have the option to add either your own application to this section, an on-premises application, and a non-gallery application (not shown in the list on the list on the website). Adding Custom applications require Azure AD Premium. |
Modern Authentication techniques: Overview
Legacy applications use older identity or authentication management solutions. Over time new identity protocols have arrived.
From Kerberos and NTLM to SAML, WSFED, OAuth, OpenID Connect, etc.
I will not be getting into the details of each one in this post but I have linked them to their wikipedia articles so that you can refer to them and given summaries of some below.
What is it?
No clear definition for this. Modern auth is not a single auth mechanism. It is a category of several different protocols that helps enhance the security of cloud-based resources. Some examples are: SAML, WS-Federation and OAuth.
WS - Federation
It is one of the WS-* authentication protocols. Web Services Federation. Used to negotiate the issuance of a token. We see this in use in Windows Identity Foundation based apps, Azure App Fabric access control service.
SAML
Security Assertion Markup Language - a standard for exchanging authentication and authorisation between different parties. There are SAML tokens and protocol itself. SAML is extremely popular because it is a lot more flexible, supports many profiles and allows integration of identity using different flows. This is the technology that makes Single Sign On possible. SAML is like an ID Card, a small, standardized way to show who someone really is. To learn more about this, I recommend reading Cloudflare’s Learning Docs on SAML.
OAuth
OAuth is an open standard authorization protocol that provides applications the ability for secure designated access. Like logging into a Hugo.io using GitHub authentication. It allows you to approve one application interacting with another on your behalf without giving away passwords. Like delegating the authentication bit to another app. For more details I recommend reading Varonis’s blog post on OAuth.
A simple OAuth example:
- I have a github account
- I go to a website, Awesome.com
- I am reading some blog posts there but then I found something that I must comment on
- In order to comment, I need to log in using github.
- I do this via OAuth by allowing Awesome.com to read my profile and get to know who I am and gives me the ability to add comments!
There are some issues here:
- There are no restrictions as to what permissions the consumer website has to your producer application. This means, you could be granting way too many permissions to the consumer website or application, wherein the consumer in the above example is Awesome.com.
Not ideal and could lead to data leaks. And this could be a great way phish your data!
OpenID Connect
A protocol that extends OAuth that makes it a full fledged, well defined form. Based on OAuth 2.0 and is simple to use. Learn more about it from the openid website.
Microsoft’s authentication library that developers must use today to gain OpenID support is Microsoft Authentication Library (MSAL).
Before the OpenID protocol was defined, Microsoft released Active Directory Authentication Library (ADAL). A detailed list of differences between the two can be found in Microsoft Docs.
Also more details on OpenID Connect from Microsoft Docs
OpenID Connect flows
There are three broad categories of authorisation flows that OpenID connect supports.
- Implicit Flow
- Hybrid Flow
- Authorization Code flow using Proof Key for Code Exchange (PKCE)
You can read all of these in much more detail on Scott Brady’s blog.
Federation
I have heard this term a lot and only just got to read more about this.
A set of technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains.
In simple words - when a user logs in to Azure AD using on-premises credentials, Azure AD relies on Azure Active Directory Federation Services to validate your credentials with the ADFS.
Federation connects different identity management systems together. Read more about this on jumpcloud’s post
Service Principals
What are they?
Azure Service Principals are identities created for use with applications, services etc that need to access Azure resources. Roles are assigned to Service principals, instead of giving it directly to an application. Services principals are meant to be used for automated scenarios, not for users, but for machines.
You can create a service principal without having an app too. This is to allow you to create a service principal that can later be assigned to an App, thereby granting the app the roles that the service principal has.
Create a Service Principal
Download and install Azure CLI. Then go run the following on powershell or whatever shell you use and have the az cli installed in.
az ad sp create-for-rbac -n myserviceprincipal --skip-assignment
The --skip-assignment part will skip assigning the service principal to a subscription. This should give you a little JSON object in the terminal.
{
"appId": "random-guid",
"displayName": "myserviceprincipal",
"name": "yourusername",
"password": "another-guid",
"tenant": "tenantId-guid"
}
Keep a copy of that JSON if you intend to use it anywhere. You’ll need the appid and the password.
In order to view this newly created service principal though, you’ll have ot head to the App registrations section. You must be wondering now that you only created a service principal, why is it in the app registration view then? Just the way it implicitly links it to an imaginary app.
Similarly, when you register an application on Azure AD in the portal, it automatically creates a Service Principal of the same name and gives the App Users.Read permissions as a default.
Now from the command line, try and list out all the service principals available.
az ad sp list --query []."displayName"
This command lists just the names of the service principals in the current directory
To view details of a specific service principal, copy the object id from the portal for that service principal and then run the following:
az ad sp show --id "longguid"
Application Registrations
For Azure AD to manage authentication for an application, the application has to register with it. There are different types of registrations based on the type of the app or how the app is going to be consumed.
- Single tenant: App used within one directory
- Multi tenant: app used and shared among multiple directories
Another way to categorise applications:
- Native applications: public clients
- Web APIs: confidential clients
There are many ways to register an app with Azure AD:
- Azure portal
- Azure CLI
- Powershell
- Azure AD Graph API
Register an app on the Portal
Log in to the portal and head over to Active Directory section. Click on Register an application.
You will then pick a name for the app registration.
Then you are given three options:
- accounts in this organizational directory only
- accounts in any organizational directory - if you have multiple active directory directories, then users in other directories can use this app too! When the user from another Directory logs in, then a shadow of the application gets registered in that tenant too.
- accounts in any organizational directory and personal microsoft accounts - B2C
The last field is Redirect URI - this tells Azure AD which application url to redirect the app to after the authentication.
That’s it.
Application walkthrough
When you select the application you just created, you get presented a lot of details. The Application ID or the ClientID is what your app needs to know while authenticating using Azure AD. Not the object ID. This in combination with the tenant id.
If you actually go through the Quickstart, you can even download an entire application sample and learn about AD.
Branding section is where you can provide your custom logo, different URLs for homepage, terms of services, privacy statement etc..
The authentication settings allows you tweak your Redirect URIs and also a logout URL. You can choose the OpenID client workflow and choose a certain client type - public client or not.
Managing Secrets
Some example use cases:
A Client credential flow - secret could be a password. An Auth code flow could be used to ask for new access tokens.
What is the purpose of secrets?
A web application would need the secret to request an access token using the refresh token.
If an application has an associated service principal, then that service principal’s password is a client secret! This is something I have been confused about when I first inherited an API that uses Azure AD.
Similarly if you want your application to be authenticated using certificates, you could upload a certificate from a certificate authority and use it as a public key.
Managing app from the CLI
AZ CLI is cross platform, so is powershell today. I can run AZ CLI from my favourite bash shell.
az loginaz ad