Chapter 10: Planning and Implementing Enterprise Apps for Single Sign-On (SSO)

The previous chapter covered conditional access policies, including planning for and testing these policies to verify that they are working correctly and providing the proper controls, in addition to Azure Identity Protection and using sign-in and user risk conditions with policies. In this chapter, we will discuss how we can implement enterprise applications in Azure AD with single sign-on (SSO).

In this chapter, we're going to cover the following main topics:

• Designing and implementing access management and SSO for apps
• Integrating on-premises apps using Azure AD Application Proxy
• Planning your line-of-business application registration strategy
• Implementing application registrations
• Planning and configuring multi-tier application permissions

Technical requirements

In this chapter, we will continue to explore configuring a tenant for use with Microsoft 365 and Azure. You will need access to Azure Active Directory. If you have not created the trial licenses for Microsoft 365 yet, please follow the instructions provided in Chapter 1, Preparing for Your Microsoft Exam.

Designing and implementing access management and SSO for apps

In Chapter 6, Implementing and Managing Hybrid Identities you learned how to configure SSO for hybrid identity infrastructures using Azure AD Connect. This chapter will build upon SSO and how we can use SSO for enterprise applications, both on-premises and in the cloud, to provide the best user experience. The first step for any company that wants to have SSO available to their users is knowing about the applications that the company is using. In this section, we are going to discuss how Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) can help us discover the applications that are being accessed by users and how we can manage the applications that we want them to use.

Discovering apps with Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps is a cloud service for Microsoft 365 that provides Cloud Access Security Broker services. A cloud access security broker is used as an enterprise policy enforcement point between the consumers and the providers so that applications adhere to the baseline security requirements of the company. Microsoft Defender for Cloud Apps provides these capabilities for Microsoft, third-party cloud services, and registered on-premises applications.

Microsoft Defender for Cloud Apps is a helpful solution that aids in discovering applications that are being used within your company, both for planning for SSO integration with Azure AD and for controlling Shadow IT within your company. Shadow IT is where you use applications that are not approved by the company for use on the company network or on devices that also access company data. Microsoft Defender for Cloud Apps will identify all the applications that are being accessed through managed users and devices. These applications are then reported on the discovery dashboard. Knowing about the applications that are being used and accessed allows us to plan for SSO for authorized applications and block unauthorized applications.

For companies that have users in office locations with a firewall or a device that can log network traffic, Microsoft Defender for Cloud Apps's discovery capabilities allow you to connect these logs. Microsoft Defender for Cloud Apps will then create a discovery report that lists the applications that are being accessed. The workflow and architecture of Microsoft Defender for Cloud Apps are shown in the following diagram:

Figure 10.1 – Microsoft Defender for Cloud Apps architecture

For more information on Microsoft Defender for Cloud Apps, please go to https://docs.microsoft.com/en-us/cloud-app-security/what-is-cloud-app-security.

Next, we will discuss how to use Cloud Discovery to identify application use and the next steps to take.

Cloud Discovery

As we mentioned in the previous section, Microsoft Defender for Cloud Apps utilizes logs from network traffic to identify the applications that users are accessing. The traffic logs from on-premises firewalls or proxies will provide a snapshot report of the most common applications and users that are accessing these apps. Traffic from managed devices will be fed into the Microsoft Defender for Cloud Apps discovery overview dashboard, as shown in the following screenshot:

Figure 10.2 – Microsoft Defender for Cloud Apps Cloud Discovery dashboard

This information is the basis for planning and monitoring the application use within your organization. Chapter 11, Monitoring Enterprise Apps with Microsoft Defender for Cloud Apps, will discuss how to manage these applications and protect against shadow IT. The next section will discuss how to plan for single sign-on (SSO) for our non-Microsoft cloud and hybrid applications.

Planning for SSO for on-premises federated apps to migrate

As we discussed in the previous section, Cloud App Security logs information about the apps that are being accessed, helps us discover the applications that users are accessing, and evaluates whether they will be allowed access by users and devices logged in to Azure AD. Once we have created our list of sanctioned applications, we will want to allow users to authenticate to these applications with the same credentials that they use in Azure AD for Microsoft applications. If your company is currently utilizing SSO through Windows Active Directory and Active Directory Federated Services (AD FS), you can migrate these applications to Azure AD to take advantage of the cost benefits of decreased hardware, as well as the compliance and governance services that are available within Azure AD. The following diagram shows how to utilize Windows Active Directory and AD FS for cloud and line-of-business apps. In this architecture, the users and devices on Azure AD can connect to on-premises line-of-business apps by migrating applications to Azure AD and SSO through Azure AD Application Proxy.

Figure 10.3 – Active Directory and Cloud Apps using AD FS for SSO

The following diagram shows the architecture after migrating these applications to Azure AD. This architecture simplifies how to manage and monitor applications and the use of SSO.

Figure 10.4 – Active Directory and Cloud Apps migrated to Azure AD for SSO

When this architecture is utilized, the company can utilize the various security, compliance, and governance tools available within Azure AD, Microsoft 365, and Azure for cloud and on-premises line-of-business applications, such as Cloud App Security, Conditional Access policies, and Azure AD Identity Protection. In the next section, we will discuss these two types of applications.

App types to migrate

When you're determining what applications will utilize SSO, it is important to understand the different types of applications that you may have in your infrastructure.

There are two types of applications you can migrate:

1. SaaS applications are applications that are generally procured by the company. Examples of such third-party SaaS applications include Dropbox, Salesforce, ServiceNow, and Workday. These applications have their own cloud authentication components. Many of these applications can utilize Azure AD as the authentication identity provider. The next section on implementing application registrations will discuss how to register third-party SaaS applications in Azure AD.
2. Line-of-business applications are applications that are developed by the organization and are not meant to be used by other companies. These can be on-premises or cloud-native applications. If they are on-premises, they may be provided with SSO capabilities through the settings within Azure AD Connect for a hybrid identity infrastructure, as discussed in Chapter 6, Implementing and Managing Hybrid Identities. These applications can also utilize an Application Proxy to register to Azure AD, which we will look at in the Integrating on-premises apps using Azure AD Application Proxy section.

In the next section, we will learn how to prepare line-of-business applications to utilize Azure AD for authentication.

Preparation and planning for usage and insights

If your company is currently utilizing AD FS, you can install Usage & insights on the local domain as part of Azure AD Connect. Usage & insights will identify the enterprise applications on-premises and determine the level of readiness to manage authentication with Azure AD.

Figure 10.5 – Usage & insights report for AD FS applications

Usage & insights provides a list of on-premises applications and checks the following:

• Whether they are ready to migrate and can be fully supported by Azure AD in the current "as-is" configuration.
• Whether the reviews suggest that the application may have some settings that are capable of migrating to Azure AD, but that some settings may need to be adjusted before migration.
• Whether any additional steps are required; that is, it checks whether the application does not currently support Azure AD and whether the settings need to be adjusted to allow it to be migrated. You may find that these applications are not supported by Azure AD at all, depending on the settings of the application.

In the next section, we will discuss assigning roles for managing and creating application registrations.

App management and assigning roles

Once we have gone through the planning process and identified the apps that are ready to migrate, it is important to assign the proper roles. These roles are for creating app registrations and managing apps. Some of the main roles that are used for app management are as follows:

• The Application Administrator role, which allows users to create and manage enterprise applications, application registrations, and application proxy settings. These administrators can also grant application permissions and delegated permissions.
• The Cloud Application Administrator role can still manage enterprise applications and application registrations, but since this designation is for cloud applications, they cannot manage application proxies.

  Note

  Neither of these roles can be added as owners when you're creating new application registrations, but both can add credentials that impersonate an application's identity. Therefore, it is important to create Conditional Access policies for the users that are assigned these roles to protect against potential identity theft. Creating Conditional Access policies was discussed in Chapter 9, Planning, Implementing, and Administering Conditional Access and Azure Identity Protection.

  In addition, when assigning administrator roles to users, a best practice would be to only provide the elevated administrator roles when they are needed to perform a job function. Once that job function is complete, the administrator role is moved from active to available for the next time it is needed.

These just-in-time administrator roles are provided through Privileged Identity Management (PIM), which we will discuss in more detail in Chapter 13, Planning and Implementing Privileged Access and Access Reviews. In the next section, we will learn how to integrate an on-premises application using Azure AD Application Proxy.

Integrating on-premises apps using Azure AD Application Proxy

In the previous sections, we went through the planning process of discovering and identifying applications that can be migrated to Azure AD for SSO. In this section, you will learn how to configure Azure AD Application Proxy to migrate on-premises applications to Azure AD for authentication and SSO. Azure AD Application Proxy provides integration between Azure AD and the on-premises application and the authentication settings in Windows Active Directory. The following diagram shows how Azure AD Application Proxy works. The difference between Azure AD Application Proxy and the hybrid identity architecture of Azure AD Connect is that this is a single registration for a single on-premises application. Rather than having a synchronization between Windows AD and Azure AD for authentication and authorization, the Azure AD Application Proxy service is used to pass the credentials to Azure AD for the user to authenticate. The Application Proxy service makes the on-premises application emulate a cloud application in Azure AD. This provides SSO authentication through Azure AD and uses Microsoft 365 and other registered cloud applications as the single identity provider.

Figure 10.6 – Application Proxy diagram

As we mentioned in the previous section, the role that's required to perform this configuration is an Application Administrator or Global Administrator role. Adhering to the principle of least privilege, you should assign users who need to perform this configuration with the Application Administrator role. Once that role is activated, you can begin the configuration, as shown in the following steps:

1. Go to Azure Active Directory and select Application proxy from the Manage menu.

Figure 10.7 – Application proxy

2. If you receive a message stating that Application proxy is disabled on your tenant, it will be enabled automatically when you download and install the connector.

Figure 10.8 – Application Proxy is currently disabled for your tenant

3. Select Download connector service, as shown in the following screenshot:

Figure 10.9 – Download connector service

4. Accept the terms and download the Application Proxy connector.

Figure 10.10 – Accept terms & Download

5. Locate the AADApplicationProxyConnectorInstaller.msi file in your Downloads folder and start the installation. Accept the license terms and click Install.

   Note

   Make sure that your network has been configured properly for the Application Proxy connector to communicate with Azure AD by following the steps at https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-deployment-plan.

Figure 10.11 – Installing the Application Proxy Connector

6. During the installation, sign in to your Azure account (when prompted) with the account that has been assigned the Application Administrator or Global Administrator role.

Figure 10.12 – Signing in to your Microsoft Azure account

7. Once you've installed the Application Proxy connector, refresh the Application proxy tile in the Azure portal. Your connector will now be active, as shown in the following screenshot:

Figure 10.13 – Application Proxy is active

8. The message stating that Application Proxy is currently disabled for your tenant will still be visible, but Enable application proxy will no longer be grayed out. Select Enable application proxy.

Figure 10.14 – Selecting Enable application proxy

9. Select Yes when prompted to continue enabling Application Proxy.

Figure 10.15 – Continuing to enable Application Proxy

10. Once Application Proxy has been enabled, the next step is to configure an app. Select + Configure an app, as shown in the following screenshot:

Figure 10.16 – Configure an app

11. Enter a name for your application and provide an Internal Url for your enterprise application. For External Url, you can create a name for your app and select a custom URL for your tenant from the dropdown, as shown in the following screenshot as 1. If you do not have a custom URL to use, it will use your tenantname.msapproxy.net for External Url, shown as 2. Once you've entered this information, select + Add to add the on-premises application for SSO.

Figure 10.17 – Configuring Application Proxy for an on-premises application

12. With that, the application has been added and can be used with Azure AD for SSO.

    Note

    The Application Proxy connector should be installed on more than one device in your on-premises network for additional resiliency in case of a device failure.

In the next section, we will discuss how to plan for your business application registration strategy.

Planning your line-of-business application registration strategy

As you plan for business applications to be registered to utilize Azure AD for SSO, it is important to understand the reasoning for doing so. The first is that SSO creates a better experience for users who only require a single username and password for authentication.

The second is to decrease the infrastructure that is required for authenticating to applications that are on-premises. If we can register our on-premises applications to Azure AD with Application Proxy, we no longer require a Windows Active Directory infrastructure on-premises.

The third reason is security. If we have our applications registered with Azure AD, including on-premises and third-party cloud applications, we can utilize the security solutions within Azure AD to authenticate and authorize all enterprise applications. This includes multi-factor authentication (MFA), single sign-on (SSO), self-service password reset (SSPR), Azure AD Identity Protection, and Azure AD Conditional Access policies.

We can plan this strategy using Cloud App Security Discovery and Application Usage and Insights. Both planning and discovery options were discussed earlier in this chapter.

In the next section, we will learn how to register third-party cloud applications with Azure AD.

Implementing application registrations

In the previous sections, we discussed how to discover third-party applications through Cloud App Security. We also learned how to install application proxy connectors on-premises and add those on-premises line-of-business applications to Azure AD. In this section, we will learn how to register third-party cloud applications with Azure AD. Let's get started:

1. In the Azure portal, navigate to Azure Active Directory and select Enterprise applications from the Manage menu.

Figure 10.18 –Enterprise applications

2. In the Enterprise applications tile, you will see the list of current applications that are registered. Select + New application to add a new application.

Figure 10.19 – New application

3. Scroll through the list and find the application that you need to register for. You also have the option to + Create your own application at the top of the tile.

Figure 10.20 – Browsing Azure AD Gallery or the Create your own application option

4. Selecting Create your own application will open another tile. Within this tile, you can select a non-gallery application or register with Application Proxy. Choosing Application Proxy will take you to the same application configuration that was shown in Figure 10.17. The following screenshot shows the Create your own application tile:

Figure 10.21 – Create your own application

5. Selecting an application from the gallery will take you to a tile for that application. Included within this tile is a link to some documentation to guide you through the registration process. This is shown in the following screenshot:

Figure 10.22 – Registering for the third-party cloud application

6. Once you've registered, your application will be ready to use for SSO with Azure AD.

You must repeat these steps for each of the enterprise applications that you would like to register and utilize SSO for Azure AD within your tenant. You will need to have proper licensing for the users of the third-party cloud applications to register and allow SSO to be effective.

The next section will discuss multi-tier application permissions for applications.

Planning and configuring multi-tier application permissions

The final area that we need to consider for our application strategy is securing the applications and determining who can grant consent to them. You can do this by going to the Enterprise applications menu, then Security, and then Consent and permissions, as shown in the following screenshot:

Figure 10.23 – Consent and permissions

Within Consent and permissions, we can configure who can grant consent. These options allow only an administrator to grant consent, allow users to grant consent to low-impact applications, or allow users to grant consent to all applications. These options are shown in the following screenshot:

Figure 10.24 – User consent options for applications

Below these options are options for assigning group owners the appropriate permissions for granting access to users, as shown in the following screenshot:

Figure 10.25 – Group owner consent options

Configuring these permissions is important if you wish to have the proper levels of security and governance over your applications. If your applications include sensitive information, then allowing users to grant application access could lead to security vulnerabilities. Planning properly and having an appropriate strategy can help you determine the level of governance that's needed for application permissions.

Next, we will summarize what was discussed in this chapter.

Summary

In this chapter, we covered the process for discovering, planning, and implementing application registrations for single sign-on to enterprise applications. These enterprise applications include on-premises applications that are accessed through Application Proxy and cloud applications. The more applications that we can register for single sign-on in Azure Active Directory, the better the user experience becomes and the more we can utilize and leverage Azure AD security solutions.

In the next chapter, we will discuss how to use third-party cloud applications within our organization and how to manage, monitor, and control them with Cloud App Security.