Configuring Microsoft Entra ID as an OIDC Identity Provider

This topic tells you how to integrate Microsoft Entra ID as an identity provider for a Single Sign‑On for VMware Tanzu Application Service plan, by configuring OpenID Connect (OIDC) in both Single Sign‑On and Microsoft Entra ID.

Overview

Microsoft Entra ID is Microsoft’s multi-tenant cloud-based directory and identity management service. It is one of several identity providers you can use in a Single Sign‑On service plan.

To set up the integration:

1. Set up a Relying Party in Microsoft Entra ID
2. Locate the OIDC Metadata
3. Set up the OIDC Identity Provider in Single Sign‑On

Prerequisites

Before you can set up a relying party in Microsoft Entra ID, you must:

• Meet the prerequisites listed in the Microsoft Entra ID OIDC Integration Guide Overview.
• Create a Service Plan in Single Sign‑On. This is required to have the values for AUTH-DOMAIN and ORIGIN-KEY that are used to construct the Redirect URI necessary for the Azure Relying Party configuration.

Set up a relying party in Microsoft Entra ID

Here are some helpful Azure guides that can assist with any questions. Note that Azure functionality, UI, and documentation can change frequently. The text and screenshots below are included for reference only. If there is a discrepancy or issue in the guidance below, raise an issue on GitHub using the link at the bottom of the page.

• OAuth 2.0 and OpenID Connect protocols on Microsoft identity platform
• Quickstart: Register an application with the Microsoft identity platform

Azure Active Directory (Microsoft Entra ID) v1 and v2 have slightly different integration instructions. This guide is written for v2. Notes such as this one will call out when v1 is different than v2.

Follow the procedures below to set up a relying party in Microsoft Entra ID:

1. Register a New App
2. Generate a Relying Party OAuth Client Secret
3. Configure Redirect URIs

Register a New App

To register a new app:

1. Log in to your Azure account and navigate to Microsoft Entra ID > App registrations.

2. Select + New registration to create a New application registration.

   

3. Enter a name of your choice in the Name field.

4. Select an option for Supported account types. To make an appropriate selection, consult your security organization and the Azure documentation. Record this choice because your OIDC Discovery Metadata URL depends on this choice.

5. Leave Redirect URI (optional) blank. You provide this later.

6. Click Register. This redirects you to the app configuration page.

7. Copy the Application (client) ID from the app configuration page. This is the Relying Party OAuth Client ID that you will enter into the SSO Operator Dashboard in a later step.

Generate a Relying Party OAuth Client Secret

To generate a relying party OAuth client secret:

1. Navigate to the app’s configuration page. If you just completed the previous step, you should already be on this page. Otherwise, search for your app name in the App registrations list.

2. Select Certificates & secrets.

3. Select + New client secret. Provide a description and an expiration length that follows your security organization’s guidelines. Then click Add.

4. Copy the Value corresponding to the newly-created client secret. This is the Relying Party OAuth Client Secret that you will enter into the SSO Operator Dashboard in a later step.

Configure Redirect URIs

To configure redirect URIs:

1. Navigate to the app’s configuration page. If you just completed the previous step, you should already be on this page. Otherwise, search for your application name in the App registrations list.

2. Select Authentication.

3. Under Platform configuration select + Add a platform.

   

4. Under Web Applications, choose Web.

5. Under Redirect URIs, specify a URL using the following pattern:

   https://AUTH-DOMAIN.login.SYSTEM-DOMAIN/login/callback/ORIGIN-KEY
   

   Where:

   • AUTH-DOMAIN is the Auth Domain you entered in Create or Edit Service Plans.
   • SYSTEM-DOMAIN is the domain for system-level components you chose when installing the TAS for VMs tile.
   • ORIGIN-KEY is based on the Identity Provider Name you set in the SSO Operator Dashboard in Set Up the OIDC Identity Provider in Single Sign‑On below. Do not use spaces or uppercase letters in this value.

   The origin key does not change after it is assigned, even if the Identity Provider Name is modified.

6. Leave Logout URL and Implicit grant empty, and click Configure.

   

Locate the OIDC Metadata

The Azure Active Directory (Microsoft Entra ID) v2 metadata URL takes the form of https://login.microsoftonline.com/TENANT/v2.0/.well-known/openid-configuration.

Azure Active Directory (Microsoft Entra ID) v1 metadata URLs take the form of https://login.microsoftonline.com/TENANT/.well-known/openid-configuration

To locate your OIDC metadata:

1. Determine the value of TENANT for your app.

   The value depends on the Supported account type that you selected in Register a New App above. For more information, see the Microsoft Documentation.

2. If the TENANT value is the domain name or the GUID, then find those values as follows:

   1. Navigate to Azure Active Directory (Microsoft Entra ID).

   2. Record the Tenant ID or the Primary domain shown.

   3. Use either value as TENANT in the metadata URL.

Set Up the OIDC Identity Provider in Single Sign‑On

Take the following steps to set up an OIDC provider for Single Sign‑On:

1. Follow steps in Add an OIDC Provider, using the option DISCOVER OIDC CONFIGURATION.

   Azure Active Directory (Microsoft Entra ID) v1 might require the option MANUALLY ENTER OIDC CONFIGURATION.

2. When selecting supported scopes, select at least openid and profile. For an explanation of what each scope means, see the Azure documentation.
   
   VMware recommends using scope profile so that Azure includes preferred_username in the ID token, as shown in the Azure documentation.

   Azure Active Directory (Microsoft Entra ID) v1 only requires scope openid, although other scopes can be requested.

3. Under Advanced Settings > Attribute Mappings (optional) > User Attributes, select user_name as the User Schema Attribute and enter preferred_username as the Attribute Name. This enables Single Sign‑On to identify the authenticated user.

   Azure Active Directory (Microsoft Entra ID) v1 uses unique_name instead of preferred_username.

4. (Optional) Configure additional attribute mappings.

5. Click Create Identity Provider to save your settings.

6. (Optional) Enable identity provider discovery for the service plan.