Configure Asignio with Azure Active Directory B2C for multifactor authentication

Article
10/11/2024

Learn to integrate Microsoft Entra ID (Azure AD B2C) authentication with Asignio. With this integration, provide passwordless, soft biometric, and multifactor authentication experience to customers. Asignio uses patented Asignio Signature and live facial verification for user authentication. The changeable biometric signature helps to reduce passwords, fraud, phishing, and credential reuse through omni-channel authentication.

Before you begin

Choose a policy type selector to indicate the policy type setup. Azure AD B2C has two methods to define how users interact with your applications:

Predefined user flows
Configurable custom policies

The steps in this article differ for each method.

Learn more:

Prerequisites

An Azure subscription.
If you don't have on, get an Azure free account

An Azure AD B2C tenant linked to the Azure subscription
See, Tutorial: Create an Azure Active Directory B2C tenant
An Asignio Client ID and Client Secret issued by Asignio.
These tokens are obtained by registering your mobile or web applications with Asignio.

For custom policies

Complete Tutorial: Create user flows and custom policies in Azure AD B2C

Scenario description

This integration includes the following components:

Azure AD B2C - authorization server that verifies user credentials
Web or mobile applications - to secure with Asignio MFA
Asignio web application - signature biometric collection on the user touch device

The following diagram illustrates the implementation.

Diagram showing the implementation architecture.

User opens Azure AD B2C sign in page on their mobile or web application, and then signs in or signs up.
Azure AD B2C redirects the user to Asignio using an OpenID Connect (OIDC) request.
The user is redirected to the Asignio web application for biometric sign in. If the user didn't register their Asignio Signature, they can use an SMS One-Time-Password (OTP) to authenticate. After authentication, user receives a registration link to create their Asignio Signature.
The user authenticates with Asignio Signature and facial verification, or voice and facial verification.
The challenge response goes to Asignio.
Asignio returns the OIDC response to Azure AD B2C sign in.
Azure AD B2C sends an authentication verification request to Asignio to confirm receipt of the authentication data.
The user is granted or denied access to the application.

Configure an application with Asignio

Configurating an application with Asignio is with the Asignio Partner Administration site.

To request access for your organization, go to asignio.com Asignio Partner Administration page.
With credentials, sign into Asignio Partner Administration.
Create a record for the Azure AD B2C application using your Azure AD B2C tenant. When you use Azure AD B2C with Asignio, Azure AD B2C manages connected applications. Asignio apps represent apps in the Azure portal.
In the Asignio Partner Administration site, generate a Client ID and Client Secret.
Note and store Client ID and Client Secret. You use them later. Asignio doesn't store Client Secrets.
Enter the redirect URI in your site the user is returned to after authentication. Use the following URI pattern.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

Upload a company logo. It appears on Asignio authentication when users sign in.

Register a web application in Azure AD B2C

Learn more: Application types that can be used in Active Directory B2C

For this tutorial, you're registering https://jwt.ms, a Microsoft web application with decoded token contents that don't leave your browser.

Register a web application

Complete the steps in Tutorial: Register a web application in Azure Active Directory B2C article.

Configure Asignio as an identity provider in Azure AD B2C

For the following instructions, use the Microsoft Entra tenant with the Azure subscription.

Sign in to the Azure portal as at least B2C IEF Policy Administrator of the Azure AD B2C tenant.
In the Azure portal toolbar, select Directories + subscriptions.
On Portal settings | Directories + subscriptions, in the Directory name list, locate your Microsoft Entra directory.
Select Switch.
In the top-left corner of the Azure portal, select All services.
Search for and select Azure AD B2C.
In the Azure portal, search for and select Azure AD B2C.
In the left menu, select Identity providers.
Select New OpenID Connect Provider.
Select Identity provider type > OpenID Connect.
For Name, enter the Asignio sign in, or a name you choose.
For Metadata URL, enter https://authorization.asignio.com/.well-known/openid-configuration.
For Client ID, enter the Client ID you generated.
For Client Secret, enter the Client Secret you generated.
For Scope, use openid email profile.
For Response type, use code.
For Response mode, use query.
For Domain hint, use https://asignio.com.
Select OK.
Select Map this identity provider's claims.
For User ID, use sub.
For Display Name, use name.
For Given Name, use given_name.
For Surname, use family_name.
For Email, use email.
Select Save.

Create a user flow policy

In your Azure AD B2C tenant, under Policies, select User flows.
Select New user flow.
Select Sign up and sign in user flow type.
Select Version Recommended.
Select Create.
Enter a user flow Name, such as AsignioSignupSignin.
Under Identity providers, for Local Accounts, select None. This action disables email and password authentication.
For Custom identity providers, select the created Asignio Identity provider.
Select Create.

Test your user flow

In your Azure AD B2C tenant, select User flows.
Select the created user flow.
For Application, select the web application you registered. The Reply URL is https://jwt.ms.
Select Run user flow.
The browser is redirected to the Asignio sign in page.
A sign in screen appears.
At the bottom, select Asignio authentication.

If you have an Asignio Signature, complete the prompt to authenticate. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

The browser is redirected to https://jwt.ms. The token contents returned by Azure AD B2C appear.

Create Asignio policy key

Store the generated Client Secret in the Azure AD B2C tenant.
Sign in to the Azure portal.
In the portal toolbar, select the Directories + subscriptions.
On Portal settings | Directories + subscriptions, in the Directory name list, locate your Azure AD B2C directory.
Select Switch.
In the top-left corner of the Azure portal, select All services.
Search for and select Azure AD B2C.
On the Overview page, select Identity Experience Framework.
Select Policy Keys.
Select Add.
For Options, select Manual.
Enter a policy key Name for the policy key. The prefix B2C_1A_ is appended to the key name.
In Secret, enter the Client Secret that you noted.
For Key usage, select Signature.
Select Create.

Configure Asignio as an Identity provider

Tip

Before you begin, ensure the Azure AD B2C policy is configured. If not, follow the instructions in Custom policy starter pack.

For users to sign in with Asignio, define Asignio as a claims provider that Azure AD B2C communicates with through an endpoint. The endpoint provides claims Azure AD B2C uses to verify user authentication with using digital ID on the device.

Add Asignio as a claims provider

Get the custom policy starter packs from GitHub, then update the XML files in the LocalAccounts starter pack with your Azure AD B2C tenant name:

Download the zip active-directory-b2c-custom-policy-starterpack or clone the repository:

    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

In the files in the LocalAccounts directory, replace the string yourtenant with the Azure AD B2C tenant name.
Open the LocalAccounts/ TrustFrameworkExtensions.xml.
Find the ClaimsProviders element. If there isn't one, add it under the root element, TrustFrameworkPolicy.

Add a new ClaimsProvider similar to the following example:

 <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
         <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
         <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

Set client_id with the Asignio Application ID you noted.
Update client_secret section with the policy key you created. For example, B2C_1A_AsignioSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
Save the changes.

Add a user journey

The identity provider isn't in the sign in pages.

If you have a custom user journey continue to Configure the relying party policy, otherwise, copy a template user journey:
From the starter pack, open the LocalAccounts/ TrustFrameworkBase.xml.
Locate and copy the contents of the UserJourney element that include Id=SignUpOrSignIn.
Open the LocalAccounts/ TrustFrameworkExtensions.xml.
Locate the UserJourneys element. If there isn't one, add one.
Paste the UserJourney element contents as a child of the UserJourneys element.]
Rename the user journey ID. For example, Id=AsignioSUSI.

Learn more: User journeys

Add the identity provider to 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 has an identity provider list that users sign in with. The order of the elements controls the order of the sign in buttons.
Add a ClaimsProviderSelection XML element.
Set the value of TargetClaimsExchangeId to a friendly name.
Add a ClaimsExchange element.
Set the Id to the value of the target claims exchange ID.
Update the value of TechnicalProfileReferenceId to the ID of the technical profile you created.

The following XML demonstrates user journey orchestration with the identity provider.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

Configure the relying party policy

The relying party policy, for example SignUpSignIn.xml, specifies the user journey Azure AD B2C executes.

In the relying party, locate the DefaultUserJourney element.
Update the ReferenceId to match the user journey ID, in which you added the identity provider.

In the following example, for the AsignioSUSI user journey, the ReferenceId is set to AsignioSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <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}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Upload the custom policy

Sign in to the Azure portal.
In the portal toolbar, select the Directories + subscriptions.
On Portal settings | Directories + subscriptions, in the Directory name list, locate your Azure AD B2C directory.
Select Switch.
In the Azure portal, search for and select Azure AD B2C.
Under Policies, select Identity Experience Framework.
Select Upload Custom Policy.
Upload the two policy files you changed in the following order:

Extension policy, for example TrustFrameworkExtensions.xml
Relying party policy, such as SignUpOrSignin.xml

Test your custom policy

In your Azure AD B2C tenant, and under Policies, select Identity Experience Framework.
Under Custom policies, select AsignioSUSI.
For Application, select the web application that you registered. The Reply URL is https://jwt.ms.
Select Run now.
The browser is redirected to the Asignio sign in page.
A sign in screen appears.
At the bottom, select Asignio authentication.

If you have an Asignio Signature, you're prompted to authenticate with your Asignio Signature. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

The browser is redirected to https://jwt.ms. The token contents returned by Azure AD B2C appear.

Share via