Configure Transmit Security with Azure Active Directory B2C for passwordless authentication

Article
03/16/2022
9 minutes to read

Before you begin, use the Choose a policy type selector to choose the type of policy you’re setting up. Azure Active Directory B2C offers two methods to define how users interact with your applications: through predefined user flows or through fully configurable custom policies. The steps required in this article are different for each method.

In this sample tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with Transmit Security's passwordless authentication solution BindID. BindID is a passwordless authentication service that uses strong Fast Identity Online (FIDO2) biometric authentication for a reliable omni-channel authentication experience. The solution ensures a smooth sign in experience for all customers across every device and channel, and it eliminates fraud, phishing, and credential reuse.

Scenario description

The following architecture diagram shows the implementation.

Screenshot showing the bindid and Azure AD B2C architecture diagram

Step	Description
1.	User opens Azure AD B2C's sign in page, and then signs in or signs up by entering their username.
2.	Azure AD B2C redirects the user to BindID using an OpenID Connect (OIDC) request.
3.	BindID authenticates the user using appless FIDO2 biometrics, such as fingerprint.
4.	A decentralized authentication response is returned to BindID.
5.	The OIDC response is passed on to Azure AD B2C.
6.	User is either granted or denied access to the customer application based on the verification results.

Prerequisites

To get started, you'll need:

An Azure AD subscription. If you don't have a subscription, you can get a free account.
An Azure AD B2C tenant that's linked to your Azure subscription.
A BindID tenant. You can sign up for free.
If you haven't already done so, register a web application in the Azure portal.

Ability to use Azure AD B2C custom policies. If you can't, complete the steps in Get started with custom policies in Azure Active Directory B2C to learn how to use custom policies.

Step 1: Register an app in BindID

Follow the steps in Configure Your Application to add you an application in BindID Admin Portal. The following information is needed:

Property	Description
Name	Name of your application such as `Azure AD B2C BindID app`
Domain	Enter `your-B2C-tenant-name.onmicrosoft.com`. Replace `your-B2C-tenant` with the name of your Azure AD B2C tenant.
Redirect URIs	https://jwt.ms/
Redirect URLs	Enter `https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp`. Replace `your-B2C-tenant` with the name of your Azure AD B2C tenant. If you use a custom domain, replace `your-B2C-tenant-name.b2clogin.com` with your custom domain such as `contoso.com`.

After you register the app in BindID, you'll get a Client ID and a Client Secret. Record the values as you'll need them later to configure BindID as an identity provider in Azure AD B2C.

Step 2: Configure BindID as an identity provider in Azure AD B2C

Sign in to the Azure portal as the global administrator of your Azure AD B2C tenant.
Make sure you're using the directory that contains your Azure AD B2C tenant:
1. Select the Directories + subscriptions icon in the portal toolbar.
2. On the Portal settings | Directories + subscriptions page, find your Azure AD B2C directory in the Directory name list, and then select Switch.
In the top-left corner of the Azure portal, select All services, and then search for and select Azure AD B2C.
Select Identity providers, and then select New OpenID Connect provider.
Enter a Name. For example, enter Login with BindID.
For Metadata url, enter https://signin.bindid-sandbox.io/.well-known/openid-configuration.
For Client ID, enter the client ID that you previously recorded in step 1.
For Client secret, enter the Client secret that you previously recorded in step 1.
For the Scope, enter the openid email.
For Response type, select code.
For Response mode, select form_post.
Under Identity provider claims mapping, select the following claims:
1. User ID: sub
2. Email: email
Select Save.

Step 3: Create a user flow

In your Azure AD B2C tenant, under Policies, select User flows.
Select New user flow.
Select Sign up and sign in user flow type,and then select Create.
Enter a Name for your user flow such as signupsignin.
Under Identity providers:
1. For Local Accounts, select None to disable email and password-based authentication.
2. For Custom identity providers, select your newly created BindID Identity provider such as Login with BindID.
Select Create

Step 4: Test your user flow

In your Azure AD B2C tenant, select User flows.
Select the newly created user flow such as B2C_1_signupsignin.
For Application, select the web application that you previously registered as part of this article's prerequisites. The Reply URL should show https://jwt.ms.
Select the Run user flow button. Your browser should be redirected to the BindID sign in page.
Enter the registered account email and authenticates using appless FIDO2 biometrics, such as fingerprint. Once the authentication challenge is accepted, your browser should be redirect to https://jwt.ms which displays the contents of the token returned by Azure AD B2C.

Step 2: Create a BindID policy key

Add your BindID application's client Secret as a policy key:

Sign in to the Azure portal.
Make sure you're using the directory that contains your Azure AD B2C tenant:
1. Select the Directories + subscriptions icon in the portal toolbar.
2. On the Portal settings | Directories + subscriptions page, find your Azure AD B2C directory in the Directory name list, and then select Switch.
On the Overview page, 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, BindIDClientSecret. The prefix B2C_1A_ is added automatically to the name of your key.
In Secret, enter your client secret that you previously recorded in step 1.
For Key usage, select Signature.
Select Create.

Step 3: Configure BindID as an Identity provider

To enable users to sign in using BindID, you need to define BindID as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify that a specific user has authenticated using digital identity available on their device, proving the user’s identity.

Use the following steps to add BindID as a claims provider:

Get the custom policy starter packs from GitHub, then update the XML files in the SocialAndLocalAccounts starter pack with your Azure AD B2C tenant name:
1. Download the .zip file or clone the repository:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. In all of the files in the LocalAccounts directory, replace the string yourtenant with the name of your Azure AD B2C tenant. For example, if the name of your B2C tenant is contoso, all instances of yourtenant.onmicrosoft.com become contoso.onmicrosoft.com.
Open the LocalAccounts/ TrustFrameworkExtensions.xml.
Find the ClaimsProviders element. If it doesn't exist, add it under the root element.

Add a new ClaimsProvider similar to the one shown below:

 <ClaimsProvider>
     <Domain>signin.bindid-sandbox.io</Domain>
     <DisplayName>BindID</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="BindID-OpenIdConnect">
         <DisplayName>BindID</DisplayName>
         <Protocol Name="OpenIdConnect" />
         <Metadata>
           <Item Key="METADATA">https://signin.bindid-sandbox.io/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the BindID Application ID -->
           <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
           <Item Key="response_types">code</Item>
           <Item Key="scope">openid email</Item>
           <Item Key="response_mode">form_post</Item>
           <Item Key="HttpBinding">POST</Item>
           <Item Key="UsePolicyInRedirectUri">false</Item>
           <Item Key="AccessTokenResponseFormat">json</Item>
         </Metadata>
         <CryptographicKeys>
           <Key Id="client_secret" StorageReferenceId="B2C_1A_BindIDClientSecret" />
         </CryptographicKeys>
         <OutputClaims>
           <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
           <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
           <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
           <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>

Set client_id with the BindID Application ID that you previously recorded in step 1.
Save the changes.

Step 4: Add a user journey

At this point, you've set up the identity provider, but it's not yet available in any of the sign in pages. If you've your own custom user journey continue to step 5, otherwise, create a duplicate of an existing template user journey as follows:

Open the LocalAccounts/ TrustFrameworkBase.xml file from the starter pack.
Find and copy the entire contents of the UserJourney element that includes Id=SignUpOrSignIn.
Open the LocalAccounts/ 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

Step 5: Add the identity provider to a user journey

Now that you have a user journey, add the new identity provider to the user journey.

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. Set the value of TargetClaimsExchangeId to a friendly name, such as BindIDExchange.
In the next orchestration step, add a ClaimsExchange element. Set the Id to the value of the target claims exchange ID to link the BindID button to BindID-SignIn action. Update the value of TechnicalProfileReferenceId to the ID of the technical profile you created earlier while adding the claims provider.

The following XML demonstrates orchestration steps of a user journey with the identity provider:

    <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      <ClaimsProviderSelections>
        ...
        <ClaimsProviderSelection TargetClaimsExchangeId="BindIDExchange" />
      </ClaimsProviderSelections>
      ...
    </OrchestrationStep>

    <OrchestrationStep Order="2" Type="ClaimsExchange">
      ...
      <ClaimsExchanges>
        <ClaimsExchange Id="BindIDExchange" TechnicalProfileReferenceId="BindID-OpenIdConnect" />
      </ClaimsExchanges>
    </OrchestrationStep>

Step 6: Configure the relying party policy

The relying party policy, for example SignUpOrSignIn.xml, specifies the user journey which Azure AD B2C will execute. You can also control what claims are passed to your application by adjusting the OutputClaims element of the PolicyProfile TechnicalProfile element. In this sample, the application receives the user attributes such as display name, given name, surname, email, objectId, identity provider, and tenantId.

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignInWithBindID" />
    <TechnicalProfile Id="BindID-OpenIdConnect">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
        <OutputClaim ClaimTypeReferenceId="identityProvider" />
        <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>

Step 7: Upload the custom policy

Sign in to the Azure portal.
Make sure you're using the directory that contains your Azure AD B2C tenant:
1. Select the Directories + subscriptions icon in the portal toolbar.
2. On the Portal settings | Directories + subscriptions page, find your Azure AD B2C directory in the Directory name list, and then select Switch.
In the Azure portal, search for and select Azure AD B2C.
Under Policies, select Identity Experience Framework.
Select Upload Custom Policy, and then upload the files in the LocalAccounts starter pack in the following order: the base policy, for example TrustFrameworkBase.xml, the localization policy, for example TrustFrameworkLocalization.xml, the extension policy, for example TrustFrameworkExtensions.xml, and the relying party policy, such as SignUpOrSignIn.xml.

Step 8: Test your custom policy

In your Azure AD B2C tenant blade, and under Policies, select Identity Experience Framework.
Under Custom policies, select B2C_1A_signup_signin.
For Application, select the web application that you previously registered as part of this article's prerequisites. The Reply URL should show https://jwt.ms.
Select Run now. Your browser should be redirected to the BindID sign in page.
Enter the registered account email and authenticates using appless FIDO2 biometrics, such as fingerprint. Once the authentication challenge is accepted, your browser should be redirect to https://jwt.ms which displays the contents of the token returned by Azure AD B2C.

Next steps

For additional information, review the following articles: