8

Real-World Identity Provider – A Zoom-In on Azure Active Directory

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:

• An overview of AAD
• AAD basics
• Supported authentication protocols
• Registering and configuring applications

An overview of AAD

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 basics

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:

• Users: A user represents (most of the time) the identity of an individual. A user contains a list of attributes used to store a user’s information, such as first name, surname, office address, and email address, and attributes used for user authentication, such as user principal name, password, and Multi-Factor Authentication (MFA) phone number.

A user always has at least the following attributes:

• User Principal Name (UPN): This is the attribute that contains the account name an individual uses to log on when prompted by the AAD login page. The UPN format is something like [email protected] and is made up of two parts: the prefix (the part before @) and the suffix (the part after @), which must be either the default domain or a custom domain registered by an administrator.
• Password: This is the attribute that contains a user’s password; it is only mandatory for cloud users.
• Display name: This is the attribute that contains the display name for a user. Most of the time, it is a combination of an individual’s first name and last name.

There are several types of users in AAD that are typically used for different and distinct use cases:

• Cloud user: A user that is created directly in AAD is called a cloud user; each user is identified uniquely by a UPN. A cloud user’s UPN and password are stored in AAD, and their life cycle is entirely managed within AAD (using Create, Read, Update, and Delete (CRUD) operations).
• Hybrid user: A hybrid user is a user that has been synchronized by an on-premises identity system, which, most of the time, is one or more Active Directory forests. The official tools that Microsoft provides to perform this synchronization are AAD Connect and AAD Connect Cloud Sync, which read the user’s information from the on-premises Active Directory forests and write it to AAD (more details about this process will be explained shortly). A hybrid user cannot be modified directly in AAD (excluding some specific attributes); it can only be modified on the on-premises system first so that the updates are then synchronized to AAD. A hybrid user may leverage different authentication types depending on whether the on-premises password hashes are synchronized to AAD or not (more details can be found later in this chapter).
• Guest user: A guest user is a user that has been invited to the AAD tenant. This is part of the External Identities set of features that orchestrate the interaction between AAD and external identity systems. AAD allows us to invite users belonging to external identity systems such as external AAD tenants, Microsoft accounts, Google accounts, and WS-Federation or SAML identity providers where the invited user must accept an emailed invitation before gaining access to the application published by the inviting tenant. Once the invitation is redeemed and accepted, the external (guest) user can start to access applications federated by the inviting AAD tenant. The user’s credentials will still be managed by the external identity provider and authentication will still happen there. What happens is that the inviting AAD tenant will trust the token issued by the external identity provider and it will issue a new token for the final application (just as standard federation works). A guest user can be seen in AAD as a placeholder (a reference) for the real user, who still lives in the external identity provider.

• Groups: Groups are containers of users or, more generally, containers of security principals, which can include application identities too (see the Applications bullet point later in this list). Membership within a group can either be static or dynamic. In the former, members are added manually; in the latter, members are added according to predefined rules that can be customized to, for instance, add all the users that have a specific value or a specific attribute (e.g., all the users in the marketing department). Groups are security principals too.
• Devices: A device, typically the client machine used by a user, can be represented in AAD. A device object is created in AAD when a client machine is either registered, AAD-joined, or hybrid AAD-joined. Having a device representation in AAD allows us to create security rules that can allow or block access to a particular AAD resource, such as an application, according to the status (information) of the device, which can be classified as compliant or non-compliant to the aforementioned security rules. It is not the purpose of this book to provide a thorough explanation of how device management works in AAD. For additional details, visit https://docs.microsoft.com/en-us/azure/active-directory/devices/overview.
• Applications: The representation of an application in AAD can be tricky to grasp at first sight, so bear with us and it will become clearer in the end. We know that, because of how the federated authentication protocols work, an identity provider must be aware of the applications that delegate authentication to it. The process of application configuration in AAD is called application registration. When a user registers an application in AAD, a couple of things occur: an application and a service principal (which is another type of security principal) are created in the tenant, which is also referred to as the home tenant.

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

• Consent model: When defining applications, it is possible to specify the permissions the application might need when interacting with another application. This is done by configuring scopes (merely strings) in the server application definition (operations that can be done within the application) and by authorizing a client application to request these scopes. When a client application requests permission to do an operation (scope) against a server application, the user is asked to grant their consent (i.e., authorize) for the client application to do what has been specified in the scope description. This happens after AAD has successfully authenticated the user, and consent can be granted by any user unless the scope has been explicitly configured to only accept consent granted by an administrator. In the latter case, an administrator can provide consent on behalf of the whole organization (the AAD tenant) so that no subsequent login attempts by any user will ask for consent anymore.
• Administrative units: Administrative units are logical containers that can only contain users, groups, and devices. They are not security principals, but they are used to organize and group the aforementioned AAD resources in order to delegate their management to specific people who do not need or do not want to be granted the full administration of all AAD objects indiscriminately. An example of administrative unit usage could be a business manager who has only been delegated the management of users, groups, and devices belonging to their team – so, for instance, they only need to be able to reset the passwords of the users they manage (those that belong to a specific administrative unit) instead of the passwords of all the users in the tenant.

Now that we know what the different types of objects in AAD are, let’s discuss which authentication protocols AAD supports.

Supported authentication protocols

AAD supports several authentication methods. Here’s the complete list at the time of writing:

• Header-based authentication: This authentication pattern, which involves forwarding HTTP headers from a client application to a destination web application, is supported only when using the AAD Application Proxy service. AAD Application Proxy is a service that comprises two distinct components, one of which runs in the cloud and one of which runs on-premises (through the means of a connector), that allows us to publish on-premises applications that still leverage legacy authentication protocols to the internet.
• LDAP authentication: Support for LDAP authentication is provided only through AD DS, which is a component, briefly described in the previous chapter, that must be deployed within an Azure Virtual Network and leverages identities that come from the synchronization of on-premises Active Directory forests. AD DS is useful in specific use cases, such as lift-and-shift migration scenarios, and for all those applications that still leverage the LDAP protocol and cannot easily be migrated to a modern authentication protocol.
• OAuth 2.0 and OIDC authentication: The OAuth 2.0 and OIDC protocols are fully supported in AAD. They can be used for application and user authentication/authorization, and they are tightly integrated with AAD security capabilities such as MFA and Conditional Access policies. We will go deeper into these two protocols and how they can be used later in this chapter.
• RADIUS authentication: AAD integrates with RADIUS authentication to add support for MFA to specific applications such as the following:
  • Virtual Private Network (VPN)
  • Wi-Fi access
  • Remote Desktop Gateway
  • Virtual Desktop Infrastructure
  • Any other service that depends on the RADIUS protocol to authenticate users

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.

• SAML authentication: SAML is another protocol that is fully supported in AAD. Applications that still need to enable SSO through this protocol can easily integrate with AAD by sharing their federation metadata file or by simply exchanging all the information needed to create the federation (e.g., Entity IDs, Assertion Consumer Service URLs, and certificates).
• Windows Authentication – Kerberos Constrained Delegation (KCD): Windows Authentication can only be used with AAD Application Proxy, which enables SSO to on-premises KCD applications that use integrated Windows authentication (IWA).

With regards to the OAuth 2.0 and OIDC protocols, these are all the supported flows:

• Authorization code grant flows (with PKCE)
• Implicit grant flows
• On-behalf-of flows
• Client credentials flows
• Resource owner password credentials flows
• Device authorization grant flows
• Hybrid 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:

1. The client application sends a request to the AAD /devicecode endpoint in the background to initialize a new authentication session. This is what a request looks like:

   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
2. AAD responds with several parameters that are then used by the client application to continue the flow:
   • device_code: A string that is used by the client application and AAD to identify the current authentication session
   • user_code: The string code the user must input when prompted to authenticate against AAD to identify the authentication session initialized by the client application
   • verification_uri: The URL (https://microsoft.com/devicelogin) that the user must open in a browser window (in a device that is capable of using a browser) to insert user_code and authenticate against AAD
   • expires_in: The expiration time (in seconds) before device_code and user_code expire
   • interval: The number of seconds the client application should loop to wait for the user to successfully authenticate
   • message: A human-readable message containing instructions for the user to successfully authenticate using the device authorization grant flow

The client application then starts a loop (steps a and b) where it constantly asks AAD for the outcome of the user’s authentication.

3. The user opens the AAD device login page (received in the verification_uri parameter) in a browser (which, in this case, can be considered the user agent) where they insert user_code received by the client application.
4. After verifying user_code and consequently identifying the authentication session, AAD requires the user to authenticate with their credentials.
5. AAD validates the user’s credentials and shows them a message containing the result of the authentication.
6. The client application sends another request containing device_code to AAD asking whether the user has been authenticated or not.
7. The client application receives confirmation from AAD that the user has been successfully authenticated and can end the authentication flow.

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.

User provisioning

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:

• Synchronization from on-premises to AAD
• Synchronization from a cloud HR system to AAD
• Synchronization from AAD to a cloud application
• Synchronization from AAD to an on-premises application/system

Let’s describe them in greater detail.

Synchronization from on-premises to AAD

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

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:

• Device writeback
• Directory extensions
• Password hash sync
• Pass-through authentication (PTA)
• Group writeback
• Password writeback

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

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

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.

Synchronization from a cloud HR system to AAD

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 hiring of a new employee
• The termination of an employee
• The update of an employee’s profile (attributes)
• The rehiring of an employee

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:

• Have a clear understanding of which attributes should be mapped from the cloud HR system to AAD or an on-premises Active Directory
• Understand the implications of the attribute writeback feature that enables the synchronization of a user’s attributes from AAD to the cloud HR system
• Assess the on-premises Active Directory infrastructure in order to find the number of forests or domains and the presence of disconnected forests (forests that do not have direct network connectivity to other parts of the network)

Synchronization from AAD to a cloud application

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.

Synchronization from AAD to an on-premises application or system

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:

• AAD Provisioning Agent

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.

• ECMA Connector Host

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:

• Microsoft SQL Server and Azure SQL
• IBM DB2 10.x
• IBM DB2 9.x
• Oracle 10 and 11g
• Oracle 12c and 18c
• MySQL 5.x

The following LDAP directories are supported:

• OpenLDAP
• Microsoft Active Directory Lightweight Directory Services
• 389 Directory Server
• Apache Directory Server
• IBM Tivoli DS
• Isode Directory
• NetIQ eDirectory
• Novell eDirectory
• Open DJ
• Open DS
• Oracle (previously Sun ONE) Directory Server Enterprise Edition
• RadiantOne Virtual Directory Server (VDS)

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.

Authentication types

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.

MFA

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:

• Microsoft Authenticator app

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 software and hardware tokens

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

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

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:

1. An AAD federated application redirects the user to the AAD authentication page.
2. The user inserts their userprincipalname, and AAD, according to the specific UPN suffix, decides whether the user must be redirected to the federated identity provider or can be authenticated locally.
3. The user is redirected to the federated identity provider login page where they enter their credentials.
4. Upon successful validation of the user’s credentials, the third-party identity provider redirects the user to AAD with the authentication protocol-specific security token it issued.
5. AAD reads and validates the issued token, and then it generates and issues a new token enriched with the information needed by the application that initiated the authentication flow.
6. The user is finally redirected to the application, which, based on the information in the token, will authorize or deny access to the application.

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

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:

1. An AAD federated application redirects the user to the AAD authentication page.
2. The user inserts their credentials (UPN and password) into the AAD authentication page. AAD pushes the credentials into a queue (based on a technology similar to Azure Service Bus).
3. One of the on-premises PTA agents reads the credentials from the queue (each of the on-premises PTA agents has the same likelihood of reading the credentials first – therefore, there is no guarantee that one PTA agent is picked over another).
4. Once the credentials are read, the PTA agent tries to validate them against an on-premises Active Directory Domain Controller.
5. Upon successful validation of a user’s credentials, the PTA agent reports the outcome of the authentication to AAD, which, in turn, replies to the application with either a security token or an error message.

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.

PHS

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.

Seamless SSO and Primary Refresh Token (PRT)

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

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:

• Windows Hello for Business
• Microsoft Authenticator app
• FIDO2 security keys

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:

• Use passwordless authentication whenever possible. It’s the most secure and convenient authentication type that AAD provides.
• When passwordless authentication is not an option, avoid using password-based sign-in only and integrate an MFA solution to strengthen the authentication process instead.
• Use PTA whenever possible. It’s a simple and lightweight solution that does not need the installation of any additional servers since the agents can be installed on existing servers.
• Use PHS as a backup authentication method or as the primary method when PTA cannot be used (for example, a disconnected forests scenario).
• Integrate PTA or PHS with Seamless SSO to create a smooth user experience.
• Use federated authentication only when your organization has already spent money on an existing identity provider solution.

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.

Registering and configuring applications

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:

• AAD admin center (https://aad.portal.azure.com)
• Microsoft Entra admin center (https://entra.microsoft.com)
• AAD PowerShell
• The Azure CLI
• Microsoft Graph API

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:

• App registrations: Lists the definitions of applications
• Enterprise applications: Lists the application instances

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.

App registrations

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.

Authentication

In the Authentication menu, the following can be defined:

• Redirect URIs: This is the list of the redirect URIs that are used by the authorization code grant flow, the implicit grant flow, and hybrid flows. They are the application URIs to which AAD should send the JWT once it has been issued. For simplicity, they can be organized per platform (web, single-page application, iOS or macOS, Android, and Windows).
• Front-channel logout URL: This is the URL that AAD uses to trigger a logout inside the application when the logout request has been initiated by another application defined in AAD (also known as a single logout flow).
• Implicit grant and hybrid flows: By default, the implicit grant flow and the hybrid flow are disabled because they are deemed insecure. Some applications cannot use other flows, though, and AAD provides the capability to enable them and decide which types of tokens these flows can issue (access tokens and/or ID tokens).
• Supported account types: This setting defines which account types can log on to the application (either a single-tenant or multi-tenant application).
• Allow public client flows: This is another important setting that is disabled by default. When enabled, it allows us to use the resource owner password credential flow and the device code flow.

This is a screenshot of the Authentication menu taken for the ClientApp01 definition:

Figure 8.7 – Authentication menu for the ClientApp01 definition

Certificates and secrets

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

Token configuration

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

API permissions

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

Exposing an API

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

Example of an AAD-issued token

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:

• Request:

  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
• Response body:

  {"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"}
• Decoded access token:

  { "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.

Additional features

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

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 list of assignments that define the scope of the policy, which include the following:
  • The user or workload identities that the policy should be applied to
  • The cloud apps or actions the user is accessing or doing (registering security information, such as a telephone number for MFA)
  • The conditions a user should satisfy
• Access controls that specify whether the user is granted or blocked access and how the user session is treated (either a persistent browser session or the user has to authenticate after a specified amount of time)

A condition is also called a signal, and it can include the following:

• User risk level (part of the Identity Protection feature)
• Sign-in risk level (part of the Identity Protection feature)
• Device platforms (which operating system the user is using)
• Locations (which locations the user is trying to authenticate from)
• Client applications (which client applications, such as a browser or a native app, the user is connecting from)
• Filter for devices (additional filters to include or exclude devices by creating attribute filters)

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

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

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:

• Just Enough Administration (least privilege): A user should have the minimum set of permissions needed to perform a task
• Just-in-Time Administration: A user should have permission to perform a task only for the amount of time that is strictly needed to do it

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.

External identities

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:

• External collaboration settings

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

• Cross-tenant access 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

Identity Governance

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:

• Entitlement management

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:

• A list of resources and assigned roles that define what permissions a user will get for a specific resource when requesting the access package
• A list of policies, each defining the following:
  • The users who can ask for the access package
  • Whether one or more approvers must approve a user’s request for the access package
  • Optionally, questions requiring input from a user when requesting the access package
  • The access package expiration date (if any)
  • The optionally associated access reviews (see the following bullet)

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

Access reviews, simply put, are built-in scheduled objects that periodically request business approvers to review the following:

• A user’s access to one or more applications
• A user’s membership in one or more groups
• The validity of the permissions assigned to a user through an access package

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.

Verifiable credentials

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 tenant

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

ION is a public, permissionless Layer 2 DID network that runs on top of the Bitcoin blockchain.

• Microsoft Authenticator application

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

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:

• Delegated 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.

• Application permissions

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:

• accountEnabled
• assignedLicenses
• businessPhones
• city
• companyName
• country
• createdDateTime
• department
• displayName
• givenName
• identities
• mail
• mobilePhone
• onPremisesDistinguishedName
• onPremisesSameAccountName
• onPremisesUserPrincipalName
• passwordPolicies
• preferredLanguage
• proxyAddresses
• state
• surname
• usageLocation
• userPrincipalName
• userType

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:

• Request:

  GET https://graph.microsoft.com/v1.0/users/me
• Response:

  {

      "@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:

• C#
• PowerShell
• TypeScript/JavaScript
• Java
• Go
• PHP
• Python

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.

Summary

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

Enterprise applications

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: