In previous chapters, we went through a theoretical overview of how modern authentication protocols work and how they can simplify the way that users interact with an application .We analyzed the pros and cons of each authentication flow that these protocols provide, how they fit into the modern application landscape from a technical perspective, and the main challenges that an enterprise faces every day in the real world.
Having shared a list of the most famous identity providers that can be found on the market today, we would like to take a deep dive into one of them: Azure Active Directory (AAD).
In this chapter, we will explain many of the features that AAD offers, starting with the features that relate to the implementation of the underlying authentication protocols that we now know and understand. Then, we will go ahead with a list of features that have been built on top of the basic identity provider capabilities that, nowadays, are implemented by any identity solution on the market. Finally, we will have a look at what the future of AAD might be and which identity trends Microsoft is investing in and implementing in its main identity platform.
We will cover the following main topics in this chapter:
AAD is a unique identity and access management service and unified control plane solution that provides authentication, authorization, and security capabilities to all of Microsoft’s first-party cloud solutions, such as Azure, Microsoft 365, and Dynamics 365, and a plethora of third-party applications. Third-party developers can easily publish their applications into the AAD Gallery (and hundreds already have) to allow AAD administrators to seamlessly integrate applications into their enterprise and grant access to end users. If an application cannot be found in the gallery, the application can be manually added to an AAD tenant leveraging the underlying authentication protocols’ implementation.
AAD users can use single sign-on (SSO) to access all AAD applications so that they are not forced to re-enter their credentials each time they access a new application: an administrator can configure which applications a user or a group of users needs to have access to (authorization).
On top of the aforementioned authentication and authorization capabilities, AAD implements a long list of security features that help strengthen the security posture of an enterprise and reduce the attack surface for a malicious user. Using zero trust as the guiding principle, AAD intensively leverages machine learning algorithms that analyze and study the behavior patterns of a user while they interact with the AAD platform so that it’s easier to detect anomalous behaviors and identify and distinguish between legitimate and non-legitimate traffic (using Identity Protection) as early as possible. Administrators can also input their own security controls in order to prevent all the behaviors that the internal security teams usually prohibit (using Conditional Access), and they can also configure tailored administrative roles to be active only for a limited time (using Privileged Identity Management).
We know that collaboration with external companies is paramount to any enterprise – to this end, AAD provides the ability to trust identities coming from other AAD tenants and other external identity providers. Since, typically, a user in an AAD tenant is an employee that belongs to the company that owns the AAD tenant, external users belonging to external companies are usually contractors, suppliers, or simply business partners that need to access applications and services published by the enterprise they need to do business with.
With all the challenges that are involved when managing such a diverse set of users, it is fundamental to have full control over what these users can and can’t do. Furthermore, user life cycles must be organized so that a user will only have access to a resource for the amount of time they need to perform a specific task; with the Identity Governance feature, AAD allows us to review and validate user access to AAD resources by unburdening IT administrators of this responsibility and effectively delegating it to the proper business decision makers.
Automation and the ability to programmatically access all AAD features are important, and AAD provides several tools to accomplish this. AAD PowerShell and the AAD CLI are command-line tools that allow us to interact with an AAD tenant programmatically, and they can be used together with the publicly available Microsoft Graph RESTful API through the many software development kits (SDKs) provided by different programming languages.
In the following sections, we will define the types of objects that can be created in AAD, their relationships, and the features that are built on top of them. This chapter does not aim to be a comprehensive and detailed description of all Azure features; we will mainly focus on all the authentication-related features, particularly how the concepts we’ve learned about throughout this book are the foundation of all modern identity providers. The goal is for you to recognize how these concepts underpin the implementation of a real-world identity provider, in order to become familiar with them and be able to recognize them regardless of the technology or the vendor providing the service. Cloud services such as AAD also change at a very fast pace, and therefore, some of the topics described in this chapter might change slightly in the future.
AAD is a globally distributed identity and access management service organized so that each customer that would like to start using it can create their own separate and isolated instance, which is also referred to as a tenant. Each AAD tenant has a unique GUID and a unique tenant name that is written in the following format: tenantname.onmicrosoft.com. The tenant name is also called the default domain of the tenant.
Before diving into the description of the AAD objects, it is worth refreshing the concept of a security principal. It’s common to encounter the concept of security principals when talking about identity. In simple terms, a security principal can be defined as any entity that can be authenticated, that can be assigned permissions to do something, and that can be the target of a permission. Typical examples of security principals are users and groups.
AAD provides the ability to create and orchestrate the interactions of different types of objects. The list of objects includes the following:
A user always has at least the following attributes:
There are several types of users in AAD that are typically used for different and distinct use cases:
You can think of the application object as the blueprint for all the properties that the application must have: redirect URIs for the OAuth 2.0/OIDC protocols, client secrets, allowed permissions (scopes) to other applications, and so on. The service principal is an instance of the application object from which it inherits a set of static values; the service principal is the real object to which the permissions are assigned.
It is also important to explain the concept of the home tenant: applications in AAD can either be single-tenant or multi-tenant. The meaning is straightforward: a single-tenant application can only grant access to users in the home tenant, while a multi-tenant application can grant access to users belonging to external AAD tenants too. In the case of a multi-tenant application, a service principal is created in the external AAD tenant too with the same logic as the service principal created in the home tenant; it inherits all the properties and permissions the application object has defined in the home tenant.
But when is the service principal created in an external AAD tenant? This happens when an external user tries to access the application. According to the permissions that the application needs in the external AAD tenant, the user is first asked to insert their credentials and then prompted with a consent web page, where they need to agree to or disagree with the list of permissions required by the application (something similar happens with mobile applications installed on smartphones). Some permissions may require the user to be an administrator; in that case, the administrator must be involved in the consent process before the end users can successfully start utilizing the application.
This flow is described in the following diagram:
Figure 8.1 – Service principal creation flow in a multi-tenant AAD scenario
One particular type of service principal is the managed identity. A managed identity removes the need for developers to manage an application’s or entity’s credentials because the passwords (including their rotation) are completely managed by AAD. Managed identities are typically assigned to Azure resources so that they can, in this way, automatically request an OAuth 2.0 access token to use with other Azure resources, which must be registered in AAD as well. The only thing that is needed is for an administrator to create a managed identity and assign it to an Azure resource; from that moment, the developer using that resource can simply ask for an access token without specifying a client secret because AAD will verify whether the operation is allowed (authorization). AD Domain Services (AD DS) veterans will find the concept of managed identities very similar to Managed Service Accounts (MSAs).
Now that we know what the different types of objects in AAD are, let’s discuss which authentication protocols AAD supports.
AAD supports several authentication methods. Here’s the complete list at the time of writing:
This means that AAD does not provide any endpoint that speaks the RADIUS protocol, but it simply provides the ability to integrate with an existing RADIUS server (specifically, a Windows Server installation with the Network Policy Service role) to add MFA controls during the normal authentication flow.
With regards to the OAuth 2.0 and OIDC protocols, these are all the supported flows:
All these flows have been discussed in Chapter 4, Authentication Flows, except for the device authorization grant flow, which is part of an extension of the OAuth 2.0 protocol defined in a separate RFC (RFC 8628), so let’s briefly describe it.
The device authorization grant flow is typically used by a client application to obtain both an access token (or an ID token for OIDC) and a refresh token when it is not possible to input information coming from the user in the device where the client runs (e.g., an IoT device or smart TV). To complete the flow, the user must navigate to a web page on a different device and authenticate with their credentials after providing, as input, a code that identifies the authentication session created by the initial device. AAD uses a dedicated endpoint to support this flow: https://login.microsoftonline.com/{tenant_name}/oauth2/v2.0/devicecode.
The flow is described here:
Figure 8.2 – Device authorization grant flow
Here are the steps that explain the flow in detail:
POST https://login.microsoftonline.com/{tenant_name}/oauth2/v2.0/devicecode
Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3
&scope=openid%20resource_server_id
The client application then starts a loop (steps a and b) where it constantly asks AAD for the outcome of the user’s authentication.
In the Registering and configuring applications section later in this chapter, we will describe the technical steps needed to configure each of these flows for an application registered in AAD.
In Chapter 2, The Cloud Era and Identity, we covered an overview of the different types of identities and described how those identities live in a cloud identity system. Let’s now try to apply those concepts to AAD.
The complexity and the size of an enterprise company introduce challenges when it comes to using a cloud identity system such as AAD. Without getting into too much detail (more information on this topic can be found in Chapter 2, The Cloud Era and Identity), we should know that it is unlikely that there is a single identity system in the customer’s premises, but a non-negligible number of different services likely provide authentication and authorization to the end users. Generally speaking, we can classify the user provisioning or synchronization process into four categories:
Let’s describe them in greater detail.
Luckily, most enterprises already have centralized on-premises identity solutions that are based either on AD DS or an LDAP directory. This common configuration has led the AAD engineering team to develop tools that facilitate the synchronization process of the users belonging to such systems to AAD:
AAD Connect Sync is the primary tool used to synchronize on-premises users stored in a single or multiple Active Directory forest environment. AAD Connect Sync is a standalone tool that needs to be installed on an on-premises Windows Server. As stated before, multiple Active Directory forests can be part of the identity source systems, each with a predefined set of synchronization rules that can be customized to filter out the users that are out of the scope of the synchronization (e.g., service accounts or built-in AD users). Users, groups, and devices are objects that AAD Connect Sync can synchronize to AAD. It’s important to mention that one AAD Connect Sync installation can only synchronize those objects to a single AAD tenant, and an AAD tenant can only be associated with one AAD Connect Sync tool.
Objects synchronized by AAD Connect Sync (flagged as directory-synced) cannot be modified directly in AAD (with the exception of a very limited set of attributes) and therefore any update must be made on Active Directory first, and you need to wait for AAD Connect Sync to propagate the update to AAD (by default, the synchronization interval is 30 minutes). AAD Connect also provides several other features that are sometimes mandatory to enable specific features in AAD (some of which will be discussed in the next paragraph), such as the following:
It is possible to have multiple installations of the AAD Connect Sync tool in order to have a backup server in the unfortunate event that one server goes down and becomes unavailable, but only one AAD Connect Sync tool can be active at any one time. The active AAD Connect Sync tool is the only one performing the final step of the synchronization (i.e., the export of the users to AAD) while the secondary ones, configured in staging mode, will honor all the synchronization rules (they must be kept in sync with the primary one) without effectively exporting the users to AAD.
AAD Connect Cloud Sync is a lightweight version of the standard AAD Connect Sync tool based on the SCIM protocol. AAD Connect Cloud Sync currently does not support all the features that AAD Connect Sync does, but it does support all the scenarios that include disconnected on-premises Active Directory forests since multiple active installations are possible by means of a lightweight agent that can be deployed close to the resources that need to be synced. AAD Connect Cloud Sync can coexist with an existing AAD Connect Sync installation.
Microsoft Identity Manager (MIM) is an identity synchronization tool that provides a plethora of built-in connectors to provide all the capabilities needed to get different external identity systems in sync out of the box by defining which system takes precedence over conflicts and which identities must be merged, disconnected, or exported. In order to synchronize an LDAP directory to AAD, the only option is to use MIM and its built-in LDAP connector. This is an advanced configuration and requires a deep knowledge of the tool.
Cloud Human Resources (HR) systems are very common today, and the built-in synchronization engine available in AAD really helps to automate the user provisioning process. Examples of cloud HR systems are Workday and SuccessFactors.
The most common HR scenarios are as follows:
The AAD Provisioning Service is a service that runs in the cloud and reacts whenever one of the preceding events is triggered by the cloud HR system. Depending on how the enterprise is organized in terms of on-premises identity systems, the AAD Provisioning Service can be configured to either synchronize the users directly to AAD (in a cloud-only scenario where no on-premises identity system is present or relevant) or synchronize the users to an on-premises Active Directory environment. In the latter case, users will, in turn, be synchronized through AAD Connect to AAD. The latter scenario is more common for an enterprise since it is rare to find a cloud-only environment when you are not in a newly established company that does not have to manage legacy identity systems that are rooted within the internal processes of an older company. The workflow described is shown in the following diagram:
Figure 8.3 – Cloud HR app to on-premises synchronization flow
It is important when configuring the AAD Provisioning Service to plan its configuration based on the particular Active Directory topology and requirements a company might have. These are the things that must be planned or known upfront:
Having a user in AAD is not sufficient to allow an application federated with AAD to undertake decisions about what the user can and can’t do in the application (authorization). Nowadays, most applications have an internal data structure that maps the unique identifier received into the authentication token issued by AAD after a successful user authentication to a specific role in the application, which, on the other hand, enables the user to perform specific actions in the application’s business logic.
Some applications available in the AAD gallery (the internal AAD store that provides out-of-the-box integration and configuration of applications published by third-party vendors) already support the automatic provisioning of users to AAD. Within their internal users’ data structure, they implement an authorization model that is managed automatically by both the application and AAD.
This out-of-the-box synchronization is done through the SCIM protocol (already discussed in Chapter 2, The Cloud Era and Identity), which is preconfigured through a built-in connector with predefined attribute mapping rules when the application is integrated with AAD through the AAD gallery. This particular integration removes the burden of manual user provisioning into cloud applications and facilitates the AAD administrator job by automating the life cycle management process of the identities so that any update of the status of an existing user is synchronized into the application without any human intervention on either side. For instance, when a user is terminated, this mechanism allows us to disable the user’s access to the external application by automatically informing the application that the user does not have the right to interact with the application.
It’s not uncommon that, once a user is created in AAD, it needs to be synchronized to an on-premises identity system or application. As a matter of fact, when it is not possible to consolidate all existing identity systems into one but, because of retro-compatibility with legacy applications, these systems must be kept alive, it is very common to have duplicated users. Duplicated users cause great administrative effort because they must be kept in sync and they need to be deleted, disabled, or modified on all identity systems to guarantee the consistency of the information across each application.
With this in mind, it’s easy to understand why a tool that can keep all the users and identities aligned regardless of where they are stored is so important. AAD provides this capability using a couple of tools:
This agent can be installed on a Windows Server machine and must be registered to an AAD tenant. The agent supports the SCIM protocol and can be used to synchronize AAD users to an application or an identity system that supports the SCIM protocol and, therefore, provides a SCIM-compliant endpoint.
The ECMA Connector Host tool is used in conjunction with the AAD Provisioning Agent when the target application or identity system does not support the SCIM protocol. It translates the synchronization commands coming from the AAD Provisioning Agent into commands that are understood by the target application. ECMA Connector Host natively supports SQL-based applications and the LDAP protocol by providing two native connectors that can be configured to map users’ attributes coming from the Provisioning Agent to the target user’s attribute format. The following list of SQL-based applications is supported:
The following LDAP directories are supported:
At the time of writing, the ECMA Connector Host is still in Public Preview.
It’s worth mentioning that it is also possible to develop a custom application that exposes a SCIM endpoint and implements the logic to synchronize the users to a remote application in the background by translating the SCIM calls it receives to synchronization operations in the remote application. This way, it is possible to use just the AAD Provisioning Agent and avoid using the ECMA Connector Host tool.
It’s common for an organization to need to store specific information related to a user that requires the creation of a new user attribute. This often happens when all the existing attributes are already in use or there is no suitable attribute that can store that piece of information.
AAD allows us to extend the default set of attributes with custom attributes defined by an administrator. The operation can be delegated to the AAD Connect Sync tool, which will create an attribute with the name the administrator chooses. This is a convenient way of storing additional information related to an organization’s identity that is needed by an application to implement its business logic (e.g., only show specific parts of the application to users that have a particular value within an extension attribute). These extension attributes are usually passed to the application as claims within a security token.
One thing that is worth mentioning is the fact that the use of extension attributes should not be abused because application-specific information about the user should, in general, be stored within the application itself (such as in an internal database) and not within the identity provider. An identity provider should only store information that is not specific to a single application but that can be utilized among different applications; that, ideally, is related to the identity of a user (e.g., a user’s role); and that does not contain too much specific information for an application (e.g., the list of paid services a user has subscribed to).
Now that we understand how users are provisioned in AAD, we can discuss the different authentication types that are available and how to decide which one to use in different scenarios.
We now should know what the different user types are in AAD. Different authentication types can be used with specific user types according to the following table:
MFA |
Federated |
Pass Through |
Seamless SSO |
Password Hash Sync |
Passwordless |
TAP | |
Cloud user |
Yes |
N/A |
N/A |
N/A |
N/A |
Yes |
Yes |
Hybrid user |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Table 8.1 – AAD users’ authentication types
Guest users do not feature in the table because they (and their credentials) do not live in the inviting AAD tenant and, therefore, their authentication type depends on how authentication has been configured in the external identity system (which could be another AAD tenant). The only authentication an administrator in the inviting tenant can configure is either to enforce MFA for a guest user or trust a guest user’s MFA that has been done in the home tenant.
We will now describe each authentication method in the table.
First of all, let’s start by saying that MFA is not a primary authentication method, but it is always used in conjunction with another authentication type that is used as the primary method.
When using MFA, the second factor of authentication is added to the primary one. To successfully implement an MFA authentication configuration, the two factors of authentication (the primary and the secondary) usually belong to two out of the three different types of credentials a user can use: something a user knows (typically a password, a PIN, or a code), something a user is (a biometric factor such as a fingerprint or the user’s face), and something a user has or owns (such as a smartcard or an OATH token).
The user is challenged with the request to use the second authentication factor after they successfully authenticate in AAD through one of the authentication types listed in the preceding table. This allows an administrator to independently configure each of the authentication factors.
In AAD, given that the primary authentication is the user’s password, the MFA’s second factor of authentication can be one of the following:
The Microsoft Authenticator app as a second factor enables the use of push notifications to the user’s smartphone. The user can either accept or deny access through the app if they think that the authentication attempt is fraudulent. The app also allows us to generate OATH verification codes (such as time-based one-time passwords (TOTPs)).
OATH (not OAuth!) is an open standard that specifies how TOTP codes should be generated. The codes can be generated either in software (such as the Microsoft Authenticator app) or directly into specialized hardware provided by a third-party vendor.
Phone verification can be done either with text message verification, where an SMS with a code is sent to the user’s phone number (registered when an administrator has enabled MFA for the user), or with a phone call to the same phone number where the user has to press # on the keypad to accept the second-factor request. Phone verification is the least secure second-factor authentication method, and therefore, it is not recommended to use it unless it’s the only option available.
MFA in AAD can be configured either per user or through a Conditional Access policy. In this case, the usage of Conditional Access policy is the recommended method.
Passwordless authentication is a particular type of MFA where neither of the two factors of authentication includes the user’s password. We will describe it in one of the next subsections.
Federated authentication can be used with hybrid identities that have been synchronized to AAD through the AAD Connect (Cloud) Sync tool. Companies that have already invested in on-premises identity provider solutions such as Active Directory Federation Services (AD FS), NetIQ Access Manager (NAM), or PingFederate (to name a few) can create a federation between AAD and the on-premises identity provider to delegate hybrid user authentication to the on-premises system. The federation is done through the SAML or the WS-Federation protocol and can be configured for each AAD-registered domain individually (federated authentication is not a tenant-wide configuration). With this setup, AAD acts as a relying party (in some flows online, you can find the relying party represented as the service provider). In a federated authentication scenario, the flow is as follows:
The use of federated authentication is not the recommended way of authenticating hybrid identities since it adds complexity and increases the management overhead because of the presence of multiple on-premises servers that need to be maintained. Only organizations that have already invested in an on-premises identity provider should use this solution. Others should go with PTA or password hash synchronization (PHS) and Seamless SSO instead, which reduces complexity and increases security (as explained in the next subsections).
PTA is a lightweight solution for hybrid identity authentication that involves the installation of agents (three is the minimum recommended number) onto on-premises Windows Server machines. Hybrid users must have been synchronized by an on-premises Active Directory forest since PTA only supports validating a user’s credentials against a Domain Controller. PTA can be configured through the AAD Connect Sync tool, which installs the very first PTA agent on the AAD Connect Sync tool machine. PTA agent-based installation is more secure than federated authentication because it does not introduce any inbound endpoints, but all the communication from the agents to AAD and vice versa happens within an outbound connection. The authentication flow is as follows:
PTA authentication is triggered for users that do not have direct visibility from their machine to an Active Directory Domain Controller. This usually happens when the user is not connected to the corporate network and tries to access an application from the internet. When the user is connected to the corporate network, Seamless SSO authentication, if configured, is triggered instead.
As an alternative solution to authenticate on-premises Active Directory users (synchronized again by the AAD Connect tool), it is possible to use PHS. AAD Connect Sync can optionally synchronize Active Directory password hashes to AAD to allow a user’s authentication to happen locally in AAD without installing any additional components (no agents and no federation servers). PHS can be used in combination with Seamless SSO and can also be configured as a backup authentication solution in all situations where the primary authentication method is not available (either the PTA agents are not responding, or the federations servers are not available). The synchronization of the password hashes is a secure process that the AAD Connect Sync tool implements by encrypting the hashes multiple times before they are synchronized to AAD.
Users connected to their corporate network are used to not inserting their credentials when accessing applications that are federated with a third-party identity provider using a modern authentication protocol. This is because when the users are stored in Active Directory, the identity provider leverages IWA – and because the user is already authenticated on their corporate domain-joined machines to provide SSO (through the Kerberos protocol).
When using PTA or PHS authentication in AAD, there is no intermediate identity provider that can provide SSO to the end users. That’s when the Seamless SSO feature becomes important. Seamless SSO allows users who have direct visibility of a Domain Controller (connected to their corporate network) to SSO into applications federated with AAD.
This is made possible because when configuring Seamless SSO (again, by means of the AAD Connect Sync tool), AAD challenges the user accessing the application in the corporate network to provide a Kerberos ticket through a 401 Unauthorized response. The user’s domain-joined machine does the rest in the background by exchanging the Kerberos tickets it has already acquired during the user’s login for a Kerberos ticket that can be used with AAD (during Seamless SSO setup, the AAD Connect Sync tool creates a computer account, AZUREADSSOACC, which represents the AAD tenant where the users have been synchronized. This account’s service principal name is used to generate the Kerberos ticket).
Enabling Seamless SSO is only recommended when there are still legacy operating systems in an enterprise network such as Windows 7 and 8 devices. For Windows 10 and 11, SSO is guaranteed by the means of the PRT, which is a token retrieved by a Windows 10/11 device from AAD during a user’s initial logon and is regularly renewed in the background without prompting any input from the user. The PRT is a JSON Web Token (JWT) that is issued to a device that is either AAD-joined, hybrid AAD-joined, or AAD-registered. It is out of the scope of this book to describe these different device states, but, for the sake of comprehension, you could imagine those different states as three different ways of registering a device identity in AAD. An enterprise, as a matter of fact, can independently choose which registration method best fits each of its devices according to the following (simplified) flowchart:
Figure 8.4 – AAD device onboarding decision flowchart
Passwordless authentication is a form of MFA that can be configured in AAD to discourage and ideally remove the usage of passwords. Passwordless authentication can leverage the following technologies:
Each of these technologies embeds two authentication factors to effectively implement MFA. Windows Hello for Business is a Windows technology that stores security encryption keys within a domain-joined device Trusted Platform Module (TPM) – something the user owns – which can either be unlocked using a biometric factor (something the user is) or using a PIN (something the user knows). The Microsoft Authenticator app is installed on a smartphone the user owns, which can be unlocked using a biometric factor (something the user is) or a PIN (something the user knows). The app uses number matching (a technique used to mitigate MFA fatigue attacks by making users more aware of their MFA prompts), which basically shows a number that must be inserted into the AAD login page when the user is prompted. FIDO2 security keys are pieces of hardware that store secure cryptographic keys (something the user owns) that are unlocked either through a biometric factor (something the user is) or a PIN (something the user knows). FIDO2 security keys must be registered upfront by the end user.
Passwordless authentication replaces password-based authentication types (PTA, federated, and PHS) by implementing a solution that is both secure and convenient.
As already explained in the AAD basics section, the AAD username is stored in the userprincipalname attribute. There may be scenarios where the user needs to authenticate with a username that is different from the synchronized userprincipalname, on-premises with the AAD Connect (Cloud) Sync tool. The on-premises Active Directory attribute that is mapped to the AAD UPN might not be a suitable attribute for all the on-premises Active Directory forests, especially in merger or acquisition scenarios where two or more companies probably have a completely different setup in their on-premises identity systems.
In these scenarios, one or more domains are likely registered in AAD and used both as UPN suffixes and mailbox domains. In the latter scenario, AAD provides the capability to use the ProxyAddresses attribute, an attribute containing all the user’s email addresses, as the source of user’s UPNs so that they can leverage any of their email addresses to log in to an application federated with AAD. This feature, named alternate login ID, is still in Public Preview (at the time of writing) and it has some limitations that do not make it suitable for every scenario, but it’s a very convenient way to enable user authentication with an attribute, the email address, that almost every user already knows.
Before diving into the next section, here are some tips that might help you decide which is the best authentication type to choose for an organization:
We now understand the different authentication types that AAD provides to users. Let’s see how AAD allows us to manage and configure applications in the next section.
In the AAD basics section, we analyzed the twofold nature of an application in AAD. We know that an application has a definition that lives in the home tenant (the tenant where it has been effectively created) and a service principal, which is an instance of an application definition that can live both in the home tenant and within an external AAD tenant, where it will be created as a dedicated new instance. The service principal inherits the application definition permissions and applies them to the resources that live in the same tenant where it has been instantiated.
AAD provides several ways to manage its services:
The examples that will be described in this paragraph use the Microsoft Entra admin center, which has been released recently and still has the same look and feel as the AAD admin center. This means that any example that you see here can be easily mapped between the portals.
To manage this twofold nature of an application, the AAD portal provides two different sections:
You can see in the following screenshot how App registrations and Enterprise applications are part of two different sections in the Microsoft Entra admin center portal:
Figure 8.5 – Entra admin center
Let’s now delve into the details of these two types of applications in the following subsections.
When registering a new application in AAD through the App registrations menu, the only mandatory pieces of information are a display name for the application and the type of the application: single-tenant or multi-tenant. A multi-tenant application can grant access to users belonging to external AAD tenants, while a single-tenant application can grant only access to users belonging to the home tenant.
Once registered, this is what my single-tenant ClientApp01 looks like in the portal:
Figure 8.6 – An application definition overview
Within an application definition, it is possible to specify the configuration of the OAuth 2.0/OIDC protocols for the application. As you can see in the preceding screenshot, once an application is registered, AAD auto-generates a unique application ID (which also represents the client_id information used in OAuth 2.0/OIDC). We are not going to detail all the capabilities that the App registrations menu provides for an application; we will just focus on the parts related to the two authentication protocols to see how the concepts we’ve learned about throughout the book have been implemented in a commercial identity provider.
In the Authentication menu, the following can be defined:
This is a screenshot of the Authentication menu taken for the ClientApp01 definition:
Figure 8.7 – Authentication menu for the ClientApp01 definition
In this section, we will explain how it is possible to generate secrets (shared secure strings), upload certificates, and use federated credentials.
Secrets and certificates can be used in the client_secret parameter used in the authorization code grant flow and the client credentials flow, whereas federated credentials are built-in AAD features that allow us to trust tokens issued and signed by an external OIDC identity provider.
Here’s a screenshot of the menu taken for the ClientApp01 application definition where a secret has been generated:
Figure 8.8 – Certificates and secrets menu for the ClientApp01 application
In the Token configuration menu, it is possible to define additional claims to be returned within the access tokens and ID tokens issued by AAD upon a user’s successful authentication. Here’s a screenshot for the ClientApp01 application:
Figure 8.9 – Token configuration for the ClientApp01 application
In the API permissions menu, it is possible to authorize the application to ask for specific scopes during an authentication request. The values defined here can be used as strings within the scope parameter used in all the OAuth 2.0/OIDC flows. To allow an application to request a scope, the scope must be defined within the application definition of the other application that accepts them. In the following example, there is a list of scopes that ClientApp01 can request for two distinct applications: one set of scopes that can be requested to perform specific actions against the built-in Microsoft Graph API and another set of scopes for the custom ServerApp01 application. The definition of the scopes in the ServerApp01 application is done within the Expose an API menu (see the next section).
Keep in mind that the business logic that implements the authorization controls and the semantics behind each scope must be done within the application logic. AAD (and the OAuth 2.0/OIDC protocols) only defines an authorization model that describes the relationships between applications, enforcing which scopes can be requested by an application and adding them to the issued token to delegate their effective implementation to the application receiving them.
Figure 8.10 – API permissions menu for the ClientApp01 definition
Within the Expose an API permissions, it is possible to define a list of scopes that can be requested for an application. The implementation of the authorization controls behind the scope definitions in AAD (which are just strings) must be done within the application logic upon receiving the scopes as claims within the AAD-issued JWT. When a client application asks for a scope, the authenticating user must consent and allow the application to do what’s explained in the scope description. Some scopes (application permissions) can be consented to by any user, while others require an administrator to intervene and consent for the user or the entire organization (all the users in the AAD tenant) to prevent AAD from asking for consent from the end users when they try to log in to the application.
Here’s a screenshot for the ServerApp01 application:
Figure 8.11 – The Expose an API menu for the ServerApp01 definition
AAD provides a set of endpoints that can be used to interact with it by means of one of the AAD-supported authentication protocols. Not surprisingly, the endpoints include the pointers to the federation metadata files that are used to establish the federation between AAD and an application and all the familiar endpoints defined by the OAuth 2.0/OIDC protocols specifications that we have analyzed throughout this book. As an example, here’s the list of endpoints for the KatsutonX AAD tenant:
Figure 8.13 – ClientApp01 service principal’s granted permissions (scopes)
If the application definition related to a service principal provides a SCIM endpoint for user synchronization, then it is possible to configure an automatic user provisioning workflow (entirely managed by the AAD Provisioning Service) through the Provisioning menu. This will basically create, update, and delete users within the SCIM-enabled application and delegate user life cycle management entirely to AAD.
In the Single sign-on menu, on the other hand, it is possible to configure the SAML protocol configuration if the application does not support the OAuth 2.0/OIDC protocols. This option is only available if the service principal is created first, directly in the Enterprise applications menu (this is a little bit counterintuitive, but it’s how AAD works).
By taking as a reference the OAuth 2.0 configuration of the ClientApp01 and ServerApp01 applications described in the previous paragraph when discussing what a registered application was, here is an example of an AAD-issued access token obtained through the client credentials flow:
GET https://login.microsoftonline.com/b946974b-a933-49a1-9be9-610b2f7b7b8a/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=5d14cb59-3aca-49a4-8b6d-134ce3502ee2&client_secret=xDJ8Q~6QrdkVphZjTWkb9krIp5eQXGh8qEO8rdyg&scope=api%3A%2F%2Fceff2f83-b273-470c-8d05-23d04d877528%2F.default
{"token_type":"Bearer","expires_in":3599,"ext_expires_in":3599,"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1Ni IsIng1dCI6IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSIsImtpZCI6 IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSJ9.eyJhdWQiOiJhcGk6Ly 9jZWZmMmY4My1iMjczLTQ3MGMtOGQwNS0yM2QwNGQ4Nzc1MjgiLCJpc3Mi OiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9iOTQ2Otc0Yi1hOTMzLTQ5YT EtOWJlOS02MTBiMmY3YjdiOGEvIiwiaWF0IjoxNjU2NjA1NjUwLCJuYmYi OjE2NTY2MDU2NTAsImV4cCI6MTY1NjYwOTU1MCwiYWlvIjoiRTJaZ1lEQTl JbnJqQnU4RUR3c1ZuLzhHNXJNTUFBPT0iLCJhcHBpZCI6IjVkMTRjYjU5L TNhY2EtNDlhNC04YjZkLTEzNGNlMzUwMmVlMiIsImFwcGlkYWNyIjoiMSIs ImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0L2I5NDY5NzRiLWE5MzM tNDlhMS05YmU5LTYxMGIyZjdiN2I4YS8iLCJvaWQiOiI2NzI2M2NjYi1hOT A5LTRkNWMtYjM2MC05ZmMyY2JkOGMzZTEiLCJyaCI6IjAuQVRzQVM1Zed1V E9wb1VtYjZXRUxMM3Q3aW9Ndl84NXpzZ3hIalFVajBFMkhkU2c3QUFBLiIs InN1YiI6IjY3MjYzY2NiLWE5MDktNGQ1Yy1iMzYwLTlmYzJjYmQ4YzNlMSI sInRpZCI6ImI5NDY5NzRiLWE5MzMtNDlhMS05YmU5LTYxMGIyZjdiN2I4YS IsInV0aSI6Ik5yTy16RHY4Q1Vxd1pRMVBMbEstQUEiLCJ2ZXIiOiIxLjAif Q.Uv4SvZUSZye7LZvn93LrGtKVw3j-8TAZcVQgmlnX5_WWPx6LRPBrqh8sl CC5y4hvHy1MV6rKbpepLSSo62U1-Ox6YxLyL_rxd3963Ue8P7voXAcvzQIt veuPUDNe0Qhn7XPNuBvNIf-WiaSE-qSJE4n817qJ8cKXLNwNp-LqXCc38S9 NS6W0yRAE1qK5ZXOWgJbkBp0K5Td1NHA6hfBkaM7soDmvMuaADbGHRkGXxS 0QnxcLGaS-7s8VQjN82uG-XlnPEz6jMvvbLaomk1slCawYbTMqUgQqbB6mY SEEhMVLZQ89hHbL3XpcDeFWgs45hBg6brlAIOzwV1JnPAaKRg"}
{ "typ": "JWT", "alg": "RS256", "x5t": "2ZQpJ3UpbjAYXYGaXEJl8lV0TOI", "kid": "2ZQpJ3UpbjAYXYGaXEJl8lV0TOI" }.{ "aud": "api://ceff2f83-b273-470c-8d05-23d04d877528", "iss": "https://sts.windows.net/b946974b-a933-49a1-9be9-610b2f7b7b8a/", "iat": 1656605526, "nbf": 1656605526, "exp": 1656609426, "aio": "E2ZgYDizmjtQvMnv0HdZwXUfBOYeAQA=", "appid": "5d14cb59-3aca-49a4-8b6d-134ce3502ee2", "appidacr": "1", "idp": "https://sts.windows.net/b946974b-a933-49a1-9be9-610b2f7b7b8a/", "oid": "67263ccb-a909-4d5c-b360-9fc2cbd8c3e1", "rh": "0.AtsAS5dGuTOpoUmb6WELL3t7ioMv_85zsgxHjQUj0E2HdSg7AAA.", "sub": "67263ccb-a909-4d5c-b360-9fc2cbd8c3e1", "tid": "b946974b-a933-49a1-9be9-610b2f7b7b8a", "uti": "0Y6Fozzet0aCs4veEArDAA", "ver": "1.0" }.[Signature]
In the Registering and configuring applications section, we explained the application management model that is implemented in AAD and its close relationship with the OAuth, OIDC, and SAML protocols. In the next section, we will go through a set of additional AAD features that integrate with its authentication capabilities through more enterprise-oriented features that enable collaboration scenarios with external organizations and increase the overall security posture of the organization.
On top of all the authentication capabilities that AAD provides as an implementation of the OAuth 2.0/OIDC specifications, AAD has built a set of management and security features that ease the tasks of both governing identities and their life cycles and securing access to the assets protected by AAD, such as applications and the data behind them. In this section, we will give you an overview of these features. Some of them require additional licensing (AAD Premium 1 and 2) in order to be used.
Conditional Access is a security feature that can decide to grant or block a user from accessing AAD-federated applications according to specific conditions that are evaluated during a user’s authentication attempt.
The Conditional Access feature consists of creating policies where an administrator can define the conditions that trigger the policy and the actions that AAD must perform when those conditions are satisfied.
A Conditional Access policy comprises the following:
A condition is also called a signal, and it can include the following:
So, basically, the logic is as follows: when a user authenticates against AAD because they would like to access an AAD-protected resource (such as a federated application), AAD evaluates all the active Conditional Access policies by looking at the defined assignments to understand whether that particular authentication session is within the scope of a policy. If all the assignments are satisfied (e.g., the user is a member of a specific group, accessing a specific application, and satisfying specific conditions defined in the policy’s assignments), then the access control is triggered (the user is either granted or denied access) and eventually enforced if the policy is not set to Report-only mode (which only audits the effects of the policy without enforcing the access controls).
Here is a screenshot, taken from the Entra portal, of the Conditional Access policy creation wizard:
Figure 8.14 – Conditional Access policy creation
Identity Protection harnesses the huge amount of underlying signals that AAD captures every day when users authenticate and use the platform. Once those signals are acquired, AAD applies complex artificial intelligence (AI) algorithms to extract relevant insights and build patterns that define a user’s behavior when interacting with AAD and the connected services.
These patterns and behaviors are then used to find exceptions (outliers) that allow AAD to make decisions and flag a particular user or sign-in attempt that deviates from their standard pattern. As an example, it would be impossible for a real user to perform an authentication attempt from Rome followed by an authentication attempt from New York after only 5 minutes – in cases like this, AAD will highlight this log-in attempt as a security risk. Identity Protection uses three risk levels to label a user or a sign-in attempt as risky: low, medium, and high.
Specific actions can be associated with each of the preceding risk levels, such as blocking the account, forcing the user to change their password, or forcing the second factor of authentication. Identity Protection provides reports containing the decisions that have been made regarding a specific risk level, and it can also be integrated into a Conditional Access policy assignment.
Privileged Identity Management (PIM) embeds two common security principles that are considered best practices when it comes to assigning and defining permissions for a user:
AAD provides a set of built-in administrative roles that restrict administrative permissions to specific tasks, such as managing users (User Administrator role) or managing applications only (Application Administrator). AAD also provides very generic roles that can do a lot of things to different entities that are part of AAD. The most common example is the Global Administrator role, which has permission to do everything on a particular AAD tenant.
The temptation to grant the Global Administrator role to an administrator is high because it prevents any potential headaches related to the authorization errors that arise when a user tries to legitimately do something that their current assigned role does not allow. However, as per the principles stated previously, this approach is utterly wrong: the headache of tomorrow will be much worse if someone steals the credentials of a privileged user with the power to do everything on an AAD tenant.
PIM tries to help security administrators by providing built-in capabilities that allow role assignments to not be permanent but eligible: a user does not have an administrative role assigned to them but, with PIM, they can request a specific role that another administrator must already have configured for them so that they are allowed to request it for a predefined timeslot. A request for a non-permanent role assignment can also be subject to the approval of another administrator, and each request is audited to provide information about which user was assigned which role at which specific point in time.
Managing external identities (or guest accounts) can become tricky when the number of external users rises. Guest users are users that come from outside an organization’s boundaries; as such, their life cycle is managed by an external identity provider. That’s why AAD provides some built-in capabilities to manage those users.
The External Identities capabilities mainly fall into the following features:
With this feature, it is possible to specify basic authorization controls for guest users and who in the tenant can invite them (by default, every user in an AAD tenant can invite guests). It is also possible to allow invitations only to specific domains (companies) to prevent inviting all kinds of users into a tenant that might also belong to companies that shouldn’t have visibility of your organization’s data.
Self-service sign-up is also possible. A user flow can be created to guide an external user to sign up and become part of your tenant if, for instance, your company has a web portal that is free for everyone to access and, therefore, you want people to be able to create an account without an administrator’s intervention. Basically, in the External collaboration settings section in the Azure portal (see the following screenshot), define the constraints involved in the onboarding process of an external (guest) user:
Figure 8.15 – AAD external collaboration settings
Once a guest user is onboarded and is visible to the inviting AAD tenant, it makes sense to define common authorization controls for them. This is done by the cross-tenant access settings, which allow you to define which applications, by default, external users are granted or denied access to. It is possible to have both a default configuration that applies to all guest users and specific configurations that apply to specific external AAD tenants (defined by their registered domains).
Cross-tenant access settings are a very convenient way to manage authorizing external users because they allow you to create a permission baseline that applies to all guest users without having to granularly specify explicit permissions for each guest user that has been invited to an AAD tenant. The following screenshot is of the Cross-tenant access settings section in the Azure portal:
Figure 8.16 – AAD cross-tenant access settings
The AAD Identity Governance umbrella comprises a framework for managing the life cycle of a user’s authorizations regardless of the type of user (whether it is a guest or a member):
Figure 8.17 – An AAD user’s life cycle
This is done using the following features:
AAD’s entitlement management is a workflow-based solution that enables a built-in identity governance process to manage internal and external users’ life cycles. Permissions and access requests are defined in an entity called an access package, which is contained in a logical container named a catalog. A catalog can contain multiple access packages, and it defines a role-based access control model that allows you to delegate the administration of the catalog or the contained access packages to specific people in a company.
This comes in handy when it is necessary to delegate the management of the permissions of a particular business unit to its business owner. The administrator generally doesn’t know whether a user really needs access to a particular application; the business owner usually does. This model benefits both the administrators, because they are relieved of the burden of a dull task, and the business owners, who can improve their agility when managing their resources.
An access package contains the following:
Users need to access a specific portal to see and request the access packages they have been assigned to; afterward, an approval process is triggered in the background and the designated approvers will receive email notifications informing them that a new access package request needs their attention.
Access reviews, simply put, are built-in scheduled objects that periodically request business approvers to review the following:
It often happens, as a matter of fact, that permissions remain assigned to individuals that have left the company, changed their role, or simply do not need access to some resources anymore. That’s where access reviews help.
Throughout the book, we have always referred to the federated authentication model, which involves different identity providers holding user credentials, and a trust model, which describes the interaction between applications and identity providers.
The verifiable credentials feature in AAD implements a new authentication model, the same one we briefly described in Chapter 2, The Cloud Era and Identity, which comprises the concepts of both verifiable credentials and decentralized identities (DIDs).
This new model tries to resemble the interactions that we commonly have in our real lives by digitalizing the concepts of issuer, holder, verifier, and wallet. Let’s try to use these terms in a real-world example: when you are stopped by a police officer, among other things, you usually show them your driving license, the police officer verifies it, and then they usually let you go. In this scenario, you are the holder of your driving license (your credentials), which is stored in your wallet, and the police officer is the verifier of your credentials, which are issued by the government, the issuer.
This real-world authentication model, called the presentation model, can be translated into the digital world by representing each concept described here as different pieces of software. Let’s see how AAD implements it. At the time of writing, the service is still in preview and it is named Verified IDs, part of the Microsoft Entra family. These are the components involved:
AAD is the issuer of a verified ID that contains a user’s credentials (cryptographic keys) and signed claims about the user. The Microsoft solution for verifiable credentials implements the World Wide Web Consortium (W3C) Verifiable Credentials Data Model 1.0 and DIDs V1.0. Part of an AAD tenant is the AAD verifiable credentials service, which enables you to issue and revoke verifiable credentials by provisioning and writing DIDs on the Identity Overlay Network (ION).
ION is a public, permissionless Layer 2 DID network that runs on top of the Bitcoin blockchain.
The Microsoft Authenticator application acts as a digital wallet where the AAD-issued verifiable credentials are stored. It orchestrates the interaction between the user, the issuer, and the verifier. The application can only present to a verifier the portion of a verifiable credential that the user has consented to.
The presentation model is not likely to replace the existing federation model, which had and still has great success within small and large companies that have adopted it, but it’s more likely that the two models will coexist for many years.
Microsoft Graph is a gateway that allows programmatic interaction with every entity that belongs to a first-party Microsoft cloud service (i.e., AAD, Azure, Microsoft 365, and Dynamics 365).
Microsoft Graph exposes RESTful APIs that model the different objects that are used within the aforementioned cloud services. For AAD, the relevant objects are users, groups, and devices. Each entity is made up of a list of properties and methods that can be used to query the graph to retrieve information about a specific object.
The endpoint Microsoft Graph answers to is https://graph.microsoft.com/, and to use it, you have to obtain an access token from AAD by leveraging one of the supported OAuth 2.0 flows. Two types of permissions are available for an application to be granted the authorization to query Microsoft Graph, delegated and application permissions:
These permissions involve the interaction of a user with the identity provider during the acquisition of the access token. Basically, the application that is assigned delegated permission to Microsoft Graph needs to be authorized by a user to perform the action granted by that permission. For instance, if an application registered in AAD is assigned the User.Read.All delegated permission, then only an OAuth 2.0 flow that involves a user authentication (e.g., the authorization code grant flow) can be used to obtain an access token. The user must also have the same permission that the application is asking for in order for the delegation to be successful. In other words, if I assign the User.Read.All delegated permission to an application, then also, the user must be assigned the very same permission to the Microsoft Graph (which is done by assigning a specific AAD role to the user) in order for the delegation to succeed.
This is a type of permission that is assigned directly to an AAD-registered application that does not need any user interaction to be honored. The access token can be obtained by an OAuth 2.0 flow that does not involve a user’s authentication, such as the client credentials flow.
As an example, let’s see how a user entity is modeled within Microsoft Graph and how it is possible to interact with it. User properties include the following:
Methods, which allow you to interact with a user’s object, include the following ones (each method is associated with a specific HTTP verb):
Method |
Description |
HTTP verb |
List users |
Get a list of user objects |
GET |
Create user |
Create a new user object |
POST |
Get user |
Read the properties and relationships of the user object |
GET |
Update user |
Update the user object |
PATCH |
Delete user |
Delete the user object |
DELETE |
Table 8.2 – Microsoft Graph user object methods
Here’s an example of how it is possible to retrieve the list of properties associated with a user by leveraging the get user method, assuming that the access token, which must be sent in the authorization HTTP header, has already been obtained through an OAuth 2.0 flow according to the permissions model explained previously:
GET https://graph.microsoft.com/v1.0/users/me
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
"businessPhones": [
"4250000000"
],
"displayName": "Fabrizio Barcaroli",
"givenName": "Fabrizio",
"jobTitle": null,
"mail": "[email protected]",
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": "Barcaroli",
"userPrincipalName": "[email protected]",
"id": "57f25ecb-d0ff-4707-8211-b1ab756696c0"
}
Each method, when invoked, can be enriched with additional parameters to filter the result only by the information that is needed. For instance, it is possible to restrict the number of attributes that are returned when querying Microsoft Graph for a user object.
Microsoft also provides several SDKs in different programming languages that ease the task of interacting with Microsoft Graph:
When interacting with AAD, it is inevitable to meet Microsoft Graph at some point on the journey. The good news is that whatever your technical background, Microsoft Graph will simplify the management of all AAD-related resources thanks to its standard and scalable architecture.
In this chapter, we’ve seen how OAuth 2.0/OIDC concepts are implemented in a real identity provider, AAD. We’ve seen how all the different parts of the protocols can be configured in AAD, including redirect URIs, secrets, flows, and tokens. The purpose of this chapter was to give an overview of how a commercial identity provider, at the end of the day, effectively implements a standard authentication protocol so that you can easily navigate the same concepts in other identity providers too.
In the next chapter, we are going to focus on real-world scenarios, starting with a holistic view of the identity challenges a company needs to deal with, going through the many implications the identity strategy has within a company, and going in depth to see the anatomy of a cloud-born application.
Figure 8.12 – AAD protocol endpoints
When an application is registered (defined) in the App registrations menu, a service principal is created in the home AAD tenant and it will become visible in the Enterprise applications menu. Remember that a service principal is an instance of the application definition, which inherits the permissions that are defined in the application definition. As you can see in the following screenshot, the ClientApp01 service principal has been granted the permissions (scopes) that have been defined and consented for the application by a user or an administrator: