Adding Microsoft Entra ID as an Identity provider for an existing custom Azure B2C policy

August 18, 2024, Abdush Miah

Prefer to watch instead? Click below to watch the steps instead:

Prerequisites

If you haven't already you will need to follow my previous article detailing steps on how to configure / setup Azure AD B2C custom policies. Without those steps you will not be able to successfully complete this functionality.

Step 1 - Register an application

To enable sign-in for users with a Microsoft Entra account from a specific Microsoft Entra organization, in Azure Active Directory B2C (Azure AD B2C), you need to create an application in the Entra Organisation.

If not already navigate to https://portal.azure.com
If you have access to multiple tenants, select the Settings icon in the top menu to switch to your Microsoft Entra ID tenant from the Directories + subscriptions menu.
In the Azure portal, search for and select 'Microsoft Entra ID.'
In the left menu, under 'Manage', select 'App registrations.'
Select ' + New registration'.
Enter a 'Name' for your application. For example, 'Azure AD B2C App'.
Accept the default selection of 'Accounts in this organizational directory only (Default Directory only - Single tenant)' for this application.
For the 'Redirect URI', accept the value of 'Web', and enter the following URL in all lowercase letters, where your-B2C-tenant-name is replaced with the name of your Azure AD B2C tenant:

https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp

For example, https://apps365org.b2clogin.com/apps365org.onmicrosoft.com/oauth2/authresp.

If you use a custom domain, enter https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp. Replace your-domain-name with your custom domain, and your-tenant-name with the name of your tenant.

Select 'Register'. Record the Application (client) ID for use in a later step.
Select 'Certificates & secrets', and then select 'New client secret.'
Enter a 'Description' for the secret, select an expiration, and then select 'Add'. Record the Value of the secret for use in a later step.

Step 2 - Store the generated Client Secret in Azure B2C

You need to store the application key that you created in your Azure AD B2C tenant.

If you have access to multiple tenants, select the Settings icon in the top menu to switch to your Azure AD B2C tenant from the Directories + subscriptions menu.
Choose 'All services' in the top-left corner of the Azure portal, and then search for and select 'Azure AD B2C.'
Under 'Policies', select 'Identity Experience Framework.'
Select 'Policy keys' and then select 'Add'.
For 'Options', choose 'Manual'.
Enter a 'Name' for the policy key. For example, 'Apps365AppSecret'. The prefix B2C_1A_ is added automatically to the name of your key when it's created, so its reference in the XML in following section is to 'B2C_1A_Apps365AppSecret'
In 'Secret', enter your client secret value that you recorded earlier.
For 'Key usage', select 'Signature'.
Select 'Create.'

Step 3 - Configure custom policies

In a previous article we setup our custom policies to accommodate / support LocalAccount sign in only as we now are adding a new identity provider, we need our custom policies to reflect this.

Navigate to the Microsoft custom policy starterpack
Download the repo files if not already
Unzip the zip folder which contains your sample files
Make a copy of the 'SocialAndLocalAccounts' folder
Open SignUpOrSignin.xml file, TrustFrameworkBase.xml file and TrustFrameworkExtensions.xml file.

To make this article short and achieve our purpose, we will remove Facebook sign in capabilities.

In the 'TrustFrameworkBase.xml.' find the facebook ClaimsProvider element and remove it:

    <ClaimsProvider>
      <!-- The following Domain element allows this profile to be used if the request comes with domain_hint 
           query string parameter, e.g. domain_hint=facebook.com  -->
      <Domain>facebook.com</Domain>
      <DisplayName>Facebook</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Facebook-OAUTH">
          <!-- The text in the following DisplayName element is shown to the user on the claims provider 
               selection screen. -->
          <DisplayName>Facebook</DisplayName>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="ProviderName">facebook</Item>
            <Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
            <Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
            <Item Key="HttpBinding">GET</Item>
            <Item Key="UsePolicyInRedirectUri">0</Item>

            <!-- The Facebook required HTTP GET method, but the access token response is in JSON format from 3/27/2017 -->
            <Item Key="AccessTokenResponseFormat">json</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_FacebookSecret" />
          </CryptographicKeys>
          <InputClaims />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

In the same file find the facebook user journey references and remove them, you would need to remove the following lines:

<ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
<ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
<ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
<ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />

In the TrustFrameworkExtensions.xml file, Find the ClaimsProviders element.
Delete the facebook ClaimsProvider block in it's entirety:

<!-- Delete this block -->
    <ClaimsProvider>
      <DisplayName>Facebook</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Facebook-OAUTH">
          <Metadata>
            <Item Key="client_id">facebook_clientid</Item>
            <Item Key="scope">email public_profile</Item>
            <Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

Add a new ClaimsProvider to accommodate for your Entra ID sign in:

<ClaimsProvider>
  <Domain>Contoso</Domain>
  <DisplayName>Login using Contoso</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="AADContoso-OpenIdConnect">
      <DisplayName>Contoso Employee</DisplayName>
      <Description>Login with your Contoso account</Description>
      <Protocol Name="OpenIdConnect"/>
      <Metadata>
        <Item Key="METADATA">https://login.microsoftonline.com/tenant-name.onmicrosoft.com/v2.0/.well-known/openid-configuration</Item>
        <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="scope">openid profile</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="client_secret" StorageReferenceId="B2C_1A_ContosoAppSecret"/>
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Under the 'ClaimsProvider' element, update the value for 'Domain' to a unique value that can be used to distinguish it from other identity providers. For example 'Apps365'. You don't put a .com at the end of this domain setting.
Under the 'ClaimsProvider' element, update the value for 'DisplayName' to a friendly name for the claims provider. This value is not currently used.
Update the ID of the TechnicalProfile element. This ID is used to refer to this technical profile from other parts of the policy, for example 'AADApps365-OpenIdConnect'
Update the value for 'DisplayName.' This value will be displayed on the sign-in button on your sign-in screen.
Update the value for 'Description.'
Microsoft Entra ID uses the OpenID Connect protocol, so make sure that the value for Protocol is OpenIdConnect
Set value of the METADATA to:

https://login.microsoftonline.com/tenant-name.onmicrosoft.com/v2.0/.well-known/openid-configuration

where tenant-name is your Microsoft Entra tenant name. For example, https://login.microsoftonline.com/apps365.onmicrosoft.com/v2.0/.well-known/openid-configuration

Set client_id to the application ID you created in Step 1.
Under CryptographicKeys, update the value of 'StorageReferenceId' to the name of the policy key that you created earlier in Step 2. For example: 'B2C_1A_Apps365AppSecret'.
Open the 'TrustFrameworkBase.xml' file.
Find and copy the entire contents of the 'UserJourney' element that includes 'Id="SignUpOrSignIn"'.
Open the 'TrustFrameworkExtensions.xml' and find the UserJourneys element. If the element doesn't exist, add one.
Paste the entire content of the 'UserJourney' element that you copied as a child of the UserJourneys element.
Rename the Id of the user journey. For example, Id="CustomSignUpSignIn".
Find the orchestration step element that includes Type="CombinedSignInAndSignUp", or Type="ClaimsProviderSelection" in the user journey. It's usually the first orchestration step. The ClaimsProviderSelections element contains a list of identity providers that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a 'ClaimsProviderSelection' XML element and set the value of TargetClaimsExchangeId to a friendly name. e.g:

<ClaimsProviderSelection TargetClaimsExchangeId="AzureADApps365Exchange" />

In the next orchestration step OrchestrationStep Order="2", add a ClaimsExchange element. Set the Id to the value of the target claims exchange Id and update the value of TechnicalProfileReferenceId to the Id of the technical profile you created earlier e.g 'AADApps365-OpenIdConnect'

<ClaimsExchange Id="AzureADApps365Exchange" TechnicalProfileReferenceId="AADApps365-OpenIdConnect" />

Save the file
Open the 'SignUpSign.xml' file
Update the ReferenceId to match the user journey ID, you created above, e.g: 'CustomSignUpSignIn'
Save the file

Step 4 - Test the custom policy

Under Custom policies, select 'B2C_1A_signup_signin.' (this may be a different name if you changed this)
For Select application on the overview page of the custom policy, select the web application you wish to test, such as the one we registered in the previous article.
Make sure that the Reply URL is 'https://jwt.ms'.
Select 'Run now'.
Click on the new button which appears to allow you to use your Entra account.
Sign in with your entra crendentials.

References

https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-custom-policy