Configure Trusona Authentication Cloud with Azure Active Directory B2C

• Complete the steps in the article get started with custom policies in Azure AD B2C.

Step 3: Configure Trusona Authentication Cloud as an IdP in Azure AD B2C

1. Sign in to the Azure portal as the External Identity Provider Administrator and B2C User Flow Administrator roles in your Azure AD B2C tenant.

2. 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.

3. Choose All services in the top-left corner of the Azure portal, search for and select Azure AD B2C.

4. Navigate to Dashboard > Azure Active Directory B2C > Identity providers.

5. Select Identity providers.

6. Select Add.

Configure an IdP

1. Select Identity provider type > OpenID Connect (Preview).

2. Fill out the form to set up the IdP:

   Property	Value
   Metadata URL	https://authcloud.trusona.net/.well-known/openid-configuration
   Client ID	available on the Trusona Authentication Cloud portal
   Client secret	available on the Trusona Authentication Cloud portal
   Scope	OpenID profile email
   Response type	code
   Response mode	form_post

3. Select OK.

4. Select Map this identity provider’s claims.

5. To map the IdP, fill out the form:

   Property	Value
   UserID	sub
   Display name	nickname
   Given name	given_name
   Surname	family_name
   Response mode	email

6. Select OK to complete the setup for your new OIDC IdP.

Step 4: Create a user flow policy

You should now see Trusona as a new OpenID Connect Identity Provider listed within your B2C IdPs.

1. In your Azure AD B2C tenant, under Policies, select User flows.

2. Select New user flow.

3. Select Sign up and sign in, select a version, and then select Create.

4. Enter a Name for your policy.

5. In the Identity providers section, select your newly created Trusona Authentication Cloud-Identity Provider.

   Note

   Because Trusona is inherently multi-factor, it's best to leave multi-factor authentication disabled.

6. Select Create.

7. Under User Attributes and Claims, choose Show more. In the form, select at least one attribute that you specified during the setup of your identity provider in earlier section.

8. Select OK.

Step 5: Test your user flow

1. Select the policy you created.

2. Select Run user flow, and then select the settings:

   a. Application: Select the registered app, for example, jwt ms.

   b. Reply URL: Select the redirect URL, for example, https://jwt.ms.

3. Select Run user flow. You should be redirected to the Trusona Authentication Cloud. The user is presented with a sign-in web page that asks for their username – typically an email address. If the user's account isn't found in Trusona Authentication Cloud, then a response is sent to the browser that initiates a WebAuthn registration process on the device. Otherwise a response is sent to the browser that begins a WebAuthn authentication process. The user is asked to select a credential to use. The passkey is associated with the domain of the web application or a hardware security key. Once the user selects a credential, the OS requests the user to use a biometric, passcode, or PIN to confirm their identity. This unlocks the Secure Enclave/Trusted Execution environment, which generates an authentication assertion signed by the private key associated with the selected credential. Azure AD B2C validates the Trusona authentication response and issues an OIDC token. It redirects the user back to the initiating application, for example, https://jwt.ms, which displays the contents of the token returned by Azure AD B2C.

Step 3: Create Trusona Authentication Cloud policy key

Store the client secret that you previously generated in step 1 in your Azure AD B2C tenant.

1. Sign in to the Azure portal.

2. 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.

3. Choose All services in the top-left corner of the Azure portal, and then search for and select Azure AD B2C.

4. On the Overview page, select Identity Experience Framework.

5. Select Policy Keys and then select Add.

6. For Options, choose Manual.

7. Enter a Name for the policy key. For example, TrusonaTacClientSecret. The prefix B2C_1A_ is added automatically to the name of your key.

8. In Secret, enter your client secret that you previously recorded.

9. For Key usage, select Signature.

10. Select Create.

Step 4: Configure Trusona Authentication Cloud as an IdP

To enable users to sign in using Trusona Authentication Cloud, you need to define Trusona 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 a specific user has authenticated using a passkey or a hardware security key available on their device, proving the user’s identity.

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

1. 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:

   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.

2. Open the LocalAccounts/TrustFrameworkExtensions.xml.

3. Find the ClaimsProviders element. If it doesn't exist, add it under the root element, TrustFrameworkPolicy.

4. Add a new ClaimsProvider similar to the one shown as follows:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</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="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

1. Set client_id with the Trusona Authentication Cloud application ID that you previously recorded in step 1.

2. Update client_secret section with the name of the policy key created in Step 3. For example, B2C_1A_TrusonaTacClientSecret:

   <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
   

3. Save the changes.

Step 5: Add a user journey

At this point, you set up the IdP, but it's not yet available in any of the sign-in pages. If you have your own custom user journey continue to Step 6, otherwise, create a duplicate of an existing template user journey as follows:

1. Open the LocalAccounts/TrustFrameworkBase.xml file from the starter pack.

2. Find and copy the entire contents of the UserJourney element that includes Id=SignUpOrSignIn.

3. Open the LocalAccounts/TrustFrameworkExtensions.xml and find the UserJourneys element. If the element doesn't exist, add one.

4. Paste the entire content of the UserJourney element that you copied as a child of the UserJourneys element.

5. Rename the Id of the user journey. For example, Id=TrusonaTacSUSI.

Step 6: Add the IdP to a user journey

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

1. 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 IdPs 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 TrusonaTacExchange.

2. In the next orchestration step, 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 earlier while adding the claims provider, for example, TrusonaTAC-OpenIdConnect.

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

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

Learn more about User Journeys.

Step 7: Configure the relying party policy

The relying party policy, for example SignUpSignIn.xml, specifies the user journey which Azure AD B2C executes. Find the DefaultUserJourney element within relying party. Update the ReferenceId to match the user journey ID, in which you added the identity provider.

In the following example, for the Trusona Authentication Cloud user journey, the ReferenceId is set to TrusonaTacSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

Step 8: Upload the custom policy

1. Sign in to the Azure portal.

2. 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.

3. In the Azure portal, search for and select Azure AD B2C.

4. Under Policies, select Identity Experience Framework.

5. Select Upload Custom Policy, and then upload the two policy files that you changed, in the following order: the extension policy, for example TrustFrameworkExtensions.xml, then the relying party policy, such as SignUpOrSignin.xml.

Step 9: Test your custom policy

1. In your Azure AD B2C tenant, under Policies, select Identity Experience Framework.

2. Under Custom policies, select TrusonaTacSUSI.

3. For Application, select the web application that you previously registered as part of this article's prerequisites. for example jwt ms. The Reply URL should show https://jwt.ms.

4. Select Run now. Your browser should be redirected to the Trusona Authentication Cloud sign-in page.

5. A sign in screen is shown; at the bottom should be a button to use Trusona Authentication Cloud authentication.

6. You should be redirected to Trusona Authentication Cloud. The user is presented with a sign-in web page that asks for their username – typically an email address. If the user's account isn't found in the Trusona Authentication Cloud, then a response is sent to the browser that initiates a WebAuthn registration process on the device. Otherwise a response is sent to the browser that begins a WebAuthn authentication process. The user is asked to select a credential to use. The passkey is associated with the domain of the web application or a hardware security key. Once the user selects a credential, the OS requests the user to use a biometric, passcode, or PIN to confirm their identity. This unlocks the Secure Enclave/Trusted Execution environment, which generates an authentication assertion signed by the private key associated with the selected credential.

7. If the sign-in process is successful, your browser is redirected to https://jwt.ms, which displays the contents of the token returned by Azure AD B2C.