Skip to content
This repository was archived by the owner on May 17, 2024. It is now read-only.

README.md

Latest commit

 

History

History
529 lines (385 loc) · 34.2 KB

README.md

File metadata and controls

529 lines (385 loc) · 34.2 KB
page_type sample
description This sample demonstrates how to integrate an app with Azure AD as a multi-tenant app. This cross-platform application suite comprises of an Angular single-page application (TodoListSPA) authenticating users and calling an ASP.NET Core web API (TodoListAPI) which is also secured with Azure Active Directory (Azure AD). Due to the topology of this application suite (multi-tier, multi-tenant), additional steps are needed for making the apps available to users in other tenants.
languages
javascript
typescript
csharp
products
azure-active-directory
aspnet-core
msal-js
msal-angular
microsoft-authentication-library
entra
urlFragment spa-msal-angular-multi-tenant
extensions
services platform endpoint level client service
ms-identity
javascript
AAD v2.0
400
Angular SPA
.NET Core web API

Integrate an Angular SPA using MSAL Angular to authenticate users with Azure AD and call a protected web API using the multi-tenant integration pattern (SaaS)

Overview

This sample demonstrates how to integrate an app with Azure AD as a multi-tenant app. This cross-platform application suite comprises of an Angular single-page application (TodoListSPA) authenticating users and calling an ASP.NET Core web API (TodoListAPI) which is also secured with Azure Active Directory (Azure AD). Due to the topology of this application suite (multi-tier, multi-tenant), additional steps are needed for making the apps available to users in other tenants.

When it comes to integrate Azure AD authentication in their apps, developers can choose to configure their app to be either single-tenant or multi-tenant while registering their app in the Azure portal.

  • Single tenant apps are only available in the tenant they were registered in, also known as their home tenant.
  • Multi-tenant apps are available to users in both their home tenant and other tenants where they are provisioned. Apps that allow users to sign-in using their personal accounts that they use to sign into services like Xbox and Skype are also multi-tenant apps. We will cover provisioning of a multi-tenant app in other tenants using admin-consent

ℹ️ To learn how to integrate an application with Azure AD as a multi-tenant app, consider going through the recorded session: Develop multi-tenant applications with the Microsoft identity platform.

ℹ️ To learn how to integrate a JavaScript Angular application with Azure AD, consider going through the recorded session: Deep dive on using MSAL.js to integrate Angular single-page applications with Azure Active Directory

Scenario

  • TodoListSPA uses MSAL Angular to authenticate a user and obtains an access token from Azure AD for the API on behalf of the authenticated user.
  • The access token is then used by the TodoListAPI to authorize the user.
  • TodoListAPI uses Microsoft.Identity.Web to protect its endpoint and accept authorized calls.

Topology

Contents

File/folder Description
API/TodoListAPI/appsettings.json Authentication configuration parameters for the web API.
SPA/src/app/auth-config.ts Authentication configuration parameters for the SPA.
SPA/src/app/consent/consent.component.ts Contains logic for granting admin consent.

Prerequisites

  • Either Visual Studio or Visual Studio Code and .NET Core SDK
  • You would need at least two Azure Active Directory (Azure AD) tenants to successfully run this sample. For more information on how to get an Azure AD tenant, see How to get an Azure AD tenant.
  • On each tenant, at least one admin account (:warning: i.e. global admin) and one non-admin/user account should be present for testing purposes.

Setup the sample

Step 1: Clone or download this repository

From your shell or command line:

git clone https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial.git

or download and extract the repository .zip file.

⚠️ To avoid path length limitations on Windows, we recommend cloning into a directory near the root of your drive.

Step 2. Install .NET Core API dependencies

    cd ms-identity-javascript-angular-tutorial
    cd 6-AdvancedScenarios\2-call-api-mt/API
    dotnet restore

Step 3. Trust development certificates

    dotnet dev-certs https --clean
    dotnet dev-certs https --trust

For more information and potential issues, see: HTTPS in .NET Core.

Step 4. Install Angular SPA dependencies

    cd ../
    cd SPA
    npm install

There are two projects in this sample. Each needs to be separately registered in your Azure AD tenant. To register these projects, you can:

  • follow the steps below for manually register your apps
  • or use PowerShell scripts that:
    • automatically creates the Azure AD applications and related objects (passwords, permissions, dependencies) for you.
    • modify the projects' configuration files.
Expand this section if you want to use this automation: 
> :warning: If you have never used **Microsoft Graph PowerShell** before, we recommend you go through the [App Creation Scripts Guide](./AppCreationScripts/AppCreationScripts.md) once to ensure that your environment is prepared correctly for this step.

1. On Windows, run PowerShell as **Administrator** and navigate to the root of the cloned directory
1. In PowerShell run:

   ```PowerShell
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force
   ```

1. Run the script to create your Azure AD application and configure the code of the sample application accordingly.
1. For interactive process -in PowerShell, run:

   ```PowerShell
   cd .\AppCreationScripts\
   .\Configure.ps1 -TenantId "[Optional] - your tenant id" -AzureEnvironmentName "[Optional] - Azure environment, defaults to 'Global'"
   ```

> Other ways of running the scripts are described in [App Creation Scripts guide](./AppCreationScripts/AppCreationScripts.md). The scripts also provide a guide to automated application registration, configuration and removal which can help in your CI/CD scenarios.

Choose the Azure AD tenant where you want to create your applications

To manually register the apps, as a first step you'll need to:

  1. Sign in to the Azure portal.
  2. If your account is present in more than one Azure AD tenant, select your profile at the top right corner in the menu on top of the page, and then switch directory to change your portal session to the desired Azure AD tenant.

Register the service app (msal-dotnet-mt-api)

  1. Navigate to the Azure portal and select the Azure Active Directory service.
  2. Select the App Registrations blade on the left, then select New registration.
  3. In the Register an application page that appears, enter your application's registration information:
    1. In the Name section, enter a meaningful application name that will be displayed to users of the app, for example msal-dotnet-mt-api.
    2. Under Supported account types, select Accounts in any organizational directory
    3. Select Register to create the application.
  4. In the Overview blade, find and note the Application (client) ID. You use this value in your app's configuration file(s) later in your code.
  5. Since this app signs-in users, we will now proceed to select delegated permissions, which is is required by apps signing-in users.
    1. In the app's registration screen, select the API permissions blade in the left to open the page where we add access to the APIs that your application needs:
    2. Select the Add a permission button and then:
    3. Ensure that the Microsoft APIs tab is selected.
    4. In the Commonly used Microsoft APIs section, select Microsoft Graph
    5. In the Delegated permissions section, select User.Read in the list. Use the search box if necessary.
    6. Select the Add permissions button at the bottom.
  6. In the app's registration screen, select the Expose an API blade to the left to open the page where you can publish the permission as an API for which client applications can obtain access tokens for. The first thing that we need to do is to declare the unique resource URI that the clients will be using to obtain access tokens for this API. To declare an resource URI(Application ID URI), follow the following steps:
    1. Select Set next to the Application ID URI to generate a URI that is unique for this app.
    2. For this sample, accept the proposed Application ID URI (api://{clientId}) by selecting Save.

      ℹ️ Read more about Application ID URI at Validation differences by supported account types (signInAudience).

Publish Delegated Permissions
  1. All APIs must publish a minimum of one scope, also called Delegated Permission, for the client apps to obtain an access token for a user successfully. To publish a scope, follow these steps:
  2. Select Add a scope button open the Add a scope screen and Enter the values as indicated below:
    1. For Scope name, use TodoList.Read.
    2. Select Admins and users options for Who can consent?.
    3. For Admin consent display name type in TodoList.Read.
    4. For Admin consent description type in e.g. Allows the app to read the signed-in user's files..
    5. For User consent display name type in scopeName.
    6. For User consent description type in eg. Allows the app to read your files..
    7. Keep State as Enabled.
    8. Select the Add scope button on the bottom to save this scope.

    Repeat the steps above for another scope named TodoList.ReadWrite

  3. Select the Manifest blade on the left.
    1. Set accessTokenAcceptedVersion property to 2.
    2. Select on Save.

ℹ️ Follow the principle of least privilege when publishing permissions for a web API.

Publish Application Permissions
  1. All APIs should publish a minimum of one App role for applications, also called Application Permission, for the client apps to obtain an access token as themselves, i.e. when they are not signing-in a user. Application permissions are the type of permissions that APIs should publish when they want to enable client applications to successfully authenticate as themselves and not need to sign-in users. To publish an application permission, follow these steps:
  2. Still on the same app registration, select the App roles blade to the left.
  3. Select Create app role:
    1. For Display name, enter a suitable name for your application permission, for instance TodoList.Read.All.
    2. For Allowed member types, choose Application to ensure other applications can be granted this permission.
    3. For Value, enter TodoList.Read.All.
    4. For Description, enter e.g. Allows the app to read the signed-in user's files..
    5. Select Apply to save your changes.

    Repeat the steps above for another app permission named TodoList.ReadWrite.All

Configure Optional Claims
  1. Still on the same app registration, select the Token configuration blade to the left.
  2. Select Add optional claim:
    1. Select optional claim type, then choose Access.
    2. Select the optional claim idtyp.

    Indicates token type. This claim is the most accurate way for an API to determine if a token is an app token or an app+user token. This is not issued in tokens issued to users.

    1. Select the optional claim acct.

    Provides user's account status in tenant. If the user is a member of the tenant, the value is 0. If they're a guest, the value is 1.

    1. Select Add to save your changes.
Configure the service app (msal-dotnet-mt-api) to use your app registration

Open the project in your IDE (like Visual Studio or Visual Studio Code) to configure the code.

In the steps below, "ClientID" is the same as "Application ID" or "AppId".

  1. Open the API\TodoListAPI\appsettings.json file.
  2. Find the key Enter the Client ID (aka 'Application ID') and replace the existing value with the application ID (clientId) of msal-dotnet-mt-api app copied from the Azure portal.

Register the client app (msal-angular-mt-spa)

  1. Navigate to the Azure portal and select the Azure Active Directory service.
  2. Select the App Registrations blade on the left, then select New registration.
  3. In the Register an application page that appears, enter your application's registration information:
    1. In the Name section, enter a meaningful application name that will be displayed to users of the app, for example msal-angular-mt-spa.
    2. Under Supported account types, select Accounts in any organizational directory
    3. Select Register to create the application.
  4. In the Overview blade, find and note the Application (client) ID. You use this value in your app's configuration file(s) later in your code.
  5. In the app's registration screen, select the Authentication blade to the left.
  6. If you don't have a platform added, select Add a platform and select the Single-page application option.
    1. In the Redirect URI section enter the following redirect URIs:
      1. http://localhost:4200
      2. http://localhost:4200/auth
      3. http://localhost:4200/consent-redirect
    2. Click Save to save your changes.
  7. Since this app signs-in users, we will now proceed to select delegated permissions, which is is required by apps signing-in users.
    1. In the app's registration screen, select the API permissions blade in the left to open the page where we add access to the APIs that your application needs:
    2. Select the Add a permission button and then:
      1. Ensure that the My APIs tab is selected.
      2. In the list of APIs, select the API msal-dotnet-mt-api.
      3. In the Delegated permissions section, select TodoList.Read, TodoList.ReadWrite in the list. Use the search box if necessary.
      4. Select the Add permissions button at the bottom.
    3. Select the Add a permission button and then:
      1. Ensure that the Microsoft APIs tab is selected.
      2. In the Commonly used Microsoft APIs section, select Microsoft Graph
      3. In the Delegated permissions section, select User.Read in the list. Use the search box if necessary.
      4. Select the Add permissions button at the bottom.
Configure Optional Claims
  1. Still on the same app registration, select the Token configuration blade to the left.
  2. Select Add optional claim:
    1. Select optional claim type, then choose Access.
    2. Select the optional claim acct.

    Provides user's account status in tenant. If the user is a member of the tenant, the value is 0. If they're a guest, the value is 1.

    1. Select Add to save your changes.
Configure the client app (msal-angular-mt-spa) to use your app registration

Open the project in your IDE (like Visual Studio or Visual Studio Code) to configure the code.

In the steps below, "ClientID" is the same as "Application ID" or "AppId".

  1. Open the SPA\src\app\auth-config.ts file.
  2. Find the key Enter_the_Application_Id_Here and replace the existing value with the application ID (clientId) of msal-angular-spa app copied from the Azure portal.
  3. Find the key Enter_the_Web_Api_Application_Id_Here and replace the existing value with the application ID (clientId) of msal-dotnet-mt-api app copied from the Azure portal.

Configure Known Client Applications for service (msal-dotnet-mt-api)

  1. In the Azure portal, navigate to your msal-dotnet-mt-api app registration, and select the Manifest blade.
  2. In the manifest editor, change the knownClientApplications: [] line so that the array contains the Client ID of the client application (msal-angular-mt-spa) as an element of the array.

For instance:

        "knownClientApplications": ["ca8dca8d-f828-4f08-82f5-325e1a1c6428"],
  1. Save the changes to the manifest.

Step 5: Running the sample

Using a command line interface such as VS Code integrated terminal, locate the application directory. Then:

   cd ../
   cd SPA
   npm start

In a separate console window, execute the following commands

   cd API/TodoListAPI
   dotnet run

Explore the sample

  1. Open your browser and navigate to http://localhost:4200.

  2. Sign-in using the button on top-right:

login

Regular users won't be able to sign-in, until an admin-user provides admin-consent to application permissions.

admin

You can either consent as admin during initial sign-in, or if you miss this step, via the Admin page

admin

admin

  1. Once admin-consent is provided, users can select the Get my tasks button to access the todo list. When you create a new task, you will also have an option to assign it to any other user from your tenant:

assign

ℹ️ Consider taking a moment to share your experience with us

Troubleshooting

Expand for troubleshooting info

Use Stack Overflow to get support from the community. Ask your questions on Stack Overflow first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [azure-active-directory dotnet ms-identity adal msal].

If you find a bug in the sample, raise the issue on GitHub Issues.

To debug the .NET Core web API that comes with this sample, install the C# extension for Visual Studio Code.

Learn more about using .NET Core with Visual Studio Code.

To provide feedback on or suggest features for Azure Active Directory, visit User Voice page.

About the code

Here we discuss some of the more important aspects of multi-tenant applications.

Testing the Application

To properly test this application, you need at least 2 tenants, and on each tenant, at least 1 administrator and 1 non-administrator account.

Before each test, you should delete your service principal for the tenant you are about to test, in order to remove any previously given consents and start the provisioning process from scratch.

How to delete Service Principals

You will find the entry under the Enterprise Applications blade. Read more about these blades in the How and why applications are added to Azure AD.

In the next screen, select Properties and then the Delete button on the upper side.

principal1

You have now deleted the service principal for that tenant. Next time, once a user successfully authenticates to your application, a new service principal will be created (i.e. provisioning) in the tenant from which that user belongs to. Note that only a user with admin privileges in a tenant can provision an app into that tenant.

Usage of /organizations endpoint

When registering an application with the Microsoft identity platform for developers, you are asked to select which account types your application supports to sign-in with, commonly referred as audience (see: Supported account types). Your MSAL configuration will reflect your choice of audience in the authority parameter. an application that targets accounts in any Azure AD directory will have its authority parameter set to https://login.microsoftonline.com/organizations, while for an application that targets Accounts in any Azure AD directory and personal Microsoft accounts (such as Skype, Xbox, Outlook.com) it will be https://login.microsoftonline.com/common. Here, /organizations and /common are not real tenants, but just multiplexers that will route the request to the relevant tenant:

export function MSALInstanceFactory(): IPublicClientApplication {
  return new PublicClientApplication({
    auth: {
        clientId: "<your-client-id>",
        authority: "https://login.microsoftonline.com/organizations",
        redirectUri: "http://localhost:4200/",
    },
  });
}

Please note that if you sign-in guest users at the /common (or /organizations) endpoint, they will be directed to their home tenant for signing-in. So, if your multi-tenant app cares about applying tenant specific conditional access policies, group assignments or app roles to be applied to the guest users, the app should sign-in the guest user on the tenanted endpoint (https://login.microsoftonline.com/{tenantId}) instead of the /common endpoint.

Dynamic token request

If organizations or common is used as the tenant, all tokens will be requested from the users' home tenant. However, this may not be the desired outcome. If a user is invited as a guest, the tokens may be from the wrong authority. Setting the authRequest in the MsalInterceptorConfiguration to a method allows you to dynamically change the auth request. For instance, you may set the authority based on the home tenant of the account when using guest users.

export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
    const protectedResourceMap = new Map<string, Array<string>>();
    protectedResourceMap.set("https://graph.microsoft.com/v1.0/me", ["user.read"]);
    
    return {
        interactionType: InteractionType.Popup,
        protectedResourceMap,
        authRequest: (msalService, httpReq, originalAuthRequest) => {
            return {
                ...originalAuthRequest,
                authority: `https://login.microsoftonline.com/${originalAuthRequest.account?.tenantId ?? 'organizations'}`
            };
        }
    };
}

Ways of providing admin consent

A service principal of your multi-tenant app is created via one of the following ways:

  1. When the first user signs-in to your app for the first time in a tenant.
  2. Manually or programmatically created by a tenant admin using one of the following
    1. Using the /adminconsent endpoint
    2. Using the PowerShell command.
  • Consent during sign-in:

This method requires the most minimal setup. The only thing needed is that the tenant admin signs-in first and optionally choose to consent on behalf of your organization during the AAD sign-in as shown in the screen below:

consent

  • Consent using the /adminconsent endpoint

This method provides a programmatic control over the consent process. To be able to consent as an admin with this method, there are two steps your application needs to carry out:

  1. Determine the tenantId of the signed-in (admin) user.
  2. Redirect the (admin) user to the correct /adminconsent endpoint. This is demonstrated in onboard.component.ts:
adminConsent() {
    const account = this.authService.instance.getActiveAccount()

    if (account) {
        // available only in HTTPS context
        const state = window.crypto.randomUUID(); // state parameter against csrf

        /**
         * Construct URL for admin consent endpoint. For more information, visit:
         * https://docs.microsoft.com/azure/active-directory/develop/v2-admin-consent
         */
        const adminConsentUri = "https://login.microsoftonline.com/" +
            `${account.tenantId}` + "/v2.0/adminconsent?client_id=" +
            `${msalConfig.auth.clientId}` + "&state=" + `${state}` + "&redirect_uri=" + `http://localhost:4200/adminconsent` +
            "&scope=" + `${protectedResources.todoListApi.scopes.read[0].split("/TodoList")[0]}/.default`;

        // redirect to admin consent endpoint
        window.location.replace(adminConsentUri);
    }
}

admin consent endpoint

The .default scope

Did you notice the scope here is set to .default? This is a built-in scope for every application that refers to the static list of permissions configured on the application registration. Basically, it bundles all the permissions in one scope. The /.default scope can be used in any OAuth 2.0 flow. Read more about scopes usage at Scopes and permissions in the Microsoft Identity Platform.

When redirected to the /adminconsent endpoint, the tenant admin will see:

consent

After you choose an admin account, it will lead to the following prompt:

consent

Once it finishes, your application's service principal will be provisioned in that tenant.

Provisioning and sign-in differences

When provisioning, you have to take care of the dependency in the topology if the client app (msal-angular-spa) is dependent on the service app (msal-dotnet-mt-api). For instance, if your client app needs to acquire tokens to call your service app and asks for consent to the necessary scopes during the sign-in stage, you would need to provision the msal-dotnet-mt-api before the msal-angular-spa. As such, only a user with admin privileges would be able to sign-in for the first time in a new tenant. After that, any user from that admin's tenant can sign-in and use the application.

This sample is configured to allow non-admin users to sign-in to the client SPA from any tenant, as it acquire tokens for the service web API at a later stage (i.e. when the user attempts to use the shared todoList after sign-in), which means the service web API can be provisioned later than the client SPA. You can configure this behavior by modifying the scopes of loginRequest object in auth-config.ts.

Custom token validation allowing only registered tenants

By marking your application as multi-tenant, your application will be able to sign-in users from any Azure AD tenant out there. Now you would want to restrict the tenants you want to work with. For this, we will now extend token validation to only those Azure AD tenants registered in the application database.

Below, the event handler OnTokenValidated was configured to grab the tenantId from the token claims and check if it has an entry on the records. If it doesn't, an exception is thrown, canceling the authentication. (See: Startup.cs)

   services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
   {
        options.Events.OnTokenValidated = async context =>
        {
            string[] allowedTenants = { /* list of tenant IDs to allow */ };
    
            string userTenantId = context?.Principal?.Claims
                .FirstOrDefault(x => x.Type == "tid")?.Value;
    
            if (!allowedTenants.Contains(userTenantId))
            {
                throw new System.Exception("This tenant is not allowed to call this web API");
            }
        };
   });

Dynamic token request

If organizations or common is used as the tenant in MSAL configuration, all tokens will be requested from the users' home tenant. However, this may not be the desired outcome. If a user is invited as a guest, the tokens may be from the wrong authority. To configure which tenant the tokens should be acquired from in a multi-tenant application, please refer to: Dynamic token request

Dynamic MSAL configuration

In certain scenarios, you might need to dynamically configure MSAL application object on the fly. To learn how to do so, please refer to: Dynamic configurations using Factory Providers and APP_INITIALIZER

Contributing

If you'd like to contribute to this sample, see CONTRIBUTING.MD.

This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Learn More