Chapter 9. Deploying Additional Applications on Azure AD

Providing the correct authentication to your application is essential, particularly if you want to allow authentication only to users from your Azure Active Directory (Azure AD), or from any other Azure AD. Azure AD provides two concepts to give your users the required authentication.

In this chapter, we'll introduce you to the idea of single-tenant and multi-tenant applications and what's different between them. Furthermore, we'll discuss roles and claims in a single-tenant app that we move to a multi-tenant app, and you can test the transition between the two models. We'll also deploy a multi-tenant app that uses OpenID Connect. In all the different labs, you'll learn what you need from an application vendor to integrate the application into your environment. You'll be able to ask the right questions and take your deployment in the right direction.

We'll divide the chapter into the following sections:

• Preparing your lab environment
• What...

Preparing your lab environment

In this chapter, you can use any machine that has Visual Studio installed. In our case, we installed it on the YD1APP01 server. This should be your perfect development environment. You will use Azure AD1: yourdomain1.onmicrosoft.com during this lab, and one test guest user from another tenant and a test user from any other Azure AD to test multi-tenant applications. Furthermore, you will need to use the code examples from the code package to use it in your Visual Studio to configure and run the applications:

Lab environment overview

After preparing our lab environment, we can directly jump into the first section of the chapter, which describes single- and multi-tenant applications.

What defines single- and multi-tenant applications

On the face of it, there's a simple explanation of what a single-tenant or a multi-tenant application is. We can say that single-tenant apps are only available in the tenant they were registered. On the other hand, multi-tenant apps are available to users in both your home tenant and in other tenants:

• Single-tenantapplications are primarily used if you want to isolate your application from everyone and provide access only to your internal users
• Multi-tenantapplications are used when you want to provide the app to your internal staff, guest users, and Microsoft personal account users in a collaboration scenario, for example

We highly recommend reviewing https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant to find the differences between the endpoints that are used in both scenarios.

Deploying a single-tenant application including roles and claims

In this section, we'll deploy Microsoft's sample, WebApp-RoleClaims-DotNet.sln, as a single-tenant configuration. We start with this setting and move the application to a multi-tenant application in the next part. The tracker app provides the following application roles, which we can use to test the role/claims topic. First, we can use the admin role to perform all actions. With the writer role, you're empowered to create tasks in the application. To change the status of a task, you can assign the approver role. To view the tasks and their associated states, we can map the observer role.

With the following steps, we'll configure Azure AD for our application:

1. Open the Azure portal: https://portal.azure.com.
2. Navigate to the Azure AD blade.
3. Click App registrations.
4. Create +New application registration:

New app registration

5. Provide a name.
6. Add the Sign-on URL, https://localhost:44322/:

App settings dialog

7. Provide the App ID URI in the format...

Moving the single-tenant app to a multi-tenant scenario

In this section, we'll reconfigure the application to work as a multi-tenant application that you can use from other Azure AD tenants or a Microsoft personal account. With the following configuration we migrate the application:

1. Open the Startup.cs file in your solution:
   • Comment the ConfigureAuth(app) line
   • Uncomment the ConfigureMultitenantAuth(app) line:

Modifying the code for multi-tenant usage

2. Change the ida:TenantId value to our Azure AD domain name:

Changing the tenant ID

3. Press F5 in Visual Studio to build and run the app.
4. A new app will be available in Azure AD, but the users don't have roles assigned:

Check the role assignment for the newly created app

5. Reassign the roles to the users:

Reassign roles

6. Test logging in with your users and check the application.
7. Test logging in with a user from another Azure AD or a Microsoft personal account.
8. You should be able to log in:

Check the login with the guest user account

Note

You can find more information...

Deploying another multi-tenant app with OpenID Connect

In this section, we'll install a multi-tenant app that works with OpenID Connect as an authentication protocol. Working through this sample will help you to deploy the correct app registration inside your Azure AD, and you'll learn what exactly needs to be configured in the application to use your Azure AD as an authentication provider:

1. Open the Azure portal: https://portal.azure.com.
2. Navigate to the Azure AD blade.
3. Click App registrations.
4. Click +New application registration:

Create a new app registration

5. Provide an application name and the sign-on URL, https://localhost:44302/:

Provide the app properties

6. Copy the Application ID to Notepad.

7. Click Settings:

Get the app configuration data

8. Provide the App ID URI in the format https://181031inovitdemos.onmicrosoft.com/MTTodoWebApp:

Adding the App ID URI

9. Provide the Logout URL. The Home page URL should already be filled in.
10. Provide the URL in the format https://localhost:44302/Account/EndSession.

11. Click...

Summary

In this chapter, you learned about single- and multi-tenant applications and the differences between them. You handled both application types in your environment. Furthermore, you discovered roles and claims in both application types, so now you can provide a role-based access control (RBAC) scenario. With all the other applications you've deployed, you now understand the differences between the different protocols, such as SAML2.0, OAuth2 with the different flow types, and OpenID Connect. You also learned how the System for Cross-domain Identity Management (SCIM) helps you to provision users (synchronizing) from Azure AD to the application.

In the next chapter, you'll learn how to provide a cloud-based identity management life cycle. We'll focus on how to provide secure and usable authentication and identity management to your users.