Configurer Trusona Authentication Cloud avec Azure Active Directory B2C

Article
01/26/2024

Dans cet exemple de tutoriel, vous découvrez comment intégrer l’authentification Azure AD B2C à Trusona Authentication Cloud. Ce service informatique permet aux utilisateurs de s’authentifier par une fonctionnalité tap-and-go, sans avoir besoin d’une application authentificateur sur mobile.

L’intégration de Trusona Authentication Cloud dans Azure AD B2C présente les avantages suivants :

Offre une authentification forte avec une meilleure expérience utilisateur
- Des utilisateurs plus heureux qui passent plus de temps plus en ligne
- Diminution du taux d’attrition et d’abandon, augmentation des revenus
- Rétention supérieure, valeur de durée de vie (LTV)
Réduction des coûts d’exploitation de l’entreprise
- Réduction des prises de contrôle et du partage de compte
- Réduction de la fraude et diminution des actions manuelles d’analyse de fraude
- Réduction des dépenses consacrées à l’externalisation des révisions manuelles
Élimination des mots de passe
- Plus besoin de réinitialiser les mots de passe
- Réduction des réclamations au centre d’appels
- Connexions rapides, simples et sans friction à l’aide de clés d’accès

Prérequis

Pour commencer, vous avez besoin des éléments suivants :

Un compte d’essai Trusona Authentication Cloud. Pour demander un compte, contactez Trusona.
Un abonnement Azure. Si vous ne disposez d’aucun abonnement, vous pouvez obtenir un compte gratuit.
Un locataire Azure AD B2C lié à votre abonnement Azure.

Suivez les étapes décrites dans l’article Bien démarrer avec les stratégies personnalisées Azure AD B2C.

Description du scénario

Norme d’authentification web : WebAuthn implémente des systèmes d’exploitation et des navigateurs modernes pour prendre en charge l’authentification par empreinte digitale, Windows Hello ou des appareils FIDO externes tels que des USB, le Bluetooth et le mot de passe à usage unique (OTP).

Dans ce scénario, Trusona joue le rôle d’un Fournisseur d’identité (IdP) dans Azure AD B2C pour activer l’authentification sans mot de passe. La solution se compose des éléments suivants :

Une stratégie combinée de connexion et d’inscription Azure AD B2C.
Trusona Authentication Cloud ajouté à Azure AD B2C en tant que fournisseur d'identité.

Screenshot shows Trusona architecture diagram.

Étapes	Description
1.	Un utilisateur tente de se connecter à l’application web via son navigateur.
2.	L’application web redirige vers la stratégie d’inscription et de connexion Azure AD B2C.
3.	Pour authentifier l’utilisateur, Azure AD B2C le redirige vers Trusona Authentication Cloud, le fournisseur d’identité OpenID Connect (OIDC).
4.	L’utilisateur reçoit une page web de connexion lui demandant son nom d’utilisateur, généralement une adresse e-mail.
5.	L’utilisateur entre son adresse e-mail et sélectionne le bouton Continuer. Si Trusona Authentication Cloud ne trouve pas le compte de l’utilisateur, une réponse est envoyée au navigateur qui initie un processus d’inscription WebAuthn sur l’appareil. Sinon, une réponse est envoyée au navigateur qui commence un processus d’authentification WebAuthn.
6.	L’utilisateur est invité à sélectionner les informations d’identification à utiliser. La clé d’accès est associée au domaine de l’application web ou à une clé de sécurité matérielle. Une fois que l’utilisateur a sélectionné les informations d’identification, le système d’exploitation lui demande d’utiliser une donnée biométrique, un code secret ou un code PIN pour confirmer son identité. Cela déverrouille l’environnement Enclave sécurisée/Exécution approuvée, qui génère une assertion d’authentification signée par la clé privée associée aux informations d’identification sélectionnées.
7.	L’assertion d’authentification est renvoyée au service cloud Trusona pour vérification.
8.	Une fois vérifiée, Trusona Authentication Cloud (fournisseur d’identité) crée un jeton d’ID OIDC, puis le transfère à Azure AD B2C (fournisseur de services). Azure AD B2C valide la signature du jeton et l’émetteur selon les valeurs du document de découverte OpenID de Trusona. Ces informations ont été définies lors de la configuration du fournisseur d’identité. Une fois vérifiées Azure AD B2C émet un jeton OIDC id_token (selon l’étendue) et redirige l’utilisateur vers l’application initiale en joignant le jeton.
9.	L’application web (ou les bibliothèques de développement qu’elle utilise pour implémenter l’authentification) récupère le jeton puis vérifie l’authenticité du jeton Azure AD B2C. Si l’authentification est vérifiée, elle extrait les revendications et les transmet pour utilisation à l’application web.
10.	Après vérification, l’accès est accordé/refusé à l’utilisateur.

Étape 1 : Intégration dans Trusona Authentication Cloud

Connectez-vous au portail Trusona.
Dans le volet de navigation de gauche, sélectionnez Paramètres
Dans le menu Paramètres, faites glisser le curseur sur Activer OIDC.
Sélectionnez les entrées appropriées et fournissez l’URL de redirectionhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp.
Générez une clé secrète et copiez la clé à utiliser dans votre configuration Azure AD B2C.
Notes
1. Le portail Trusona prend en charge l’inscription en libre-service. Lors de l’inscription, vous serez affecté à un compte Trusona avec des droits de lecture seule. Ensuite, Trusona vous affectera le compte approprié et vous accordera des droits de lecture-écriture selon la stratégie de contrôle d’accès des utilisateurs du portail de votre organisation.
2. Le nom de domaine initial de Microsoft Entra ID est utilisé comme hôte de redirection du client.

Étape 2 : Inscrire une application web dans Azure AD B2C

Pour que vos applications puissent interagir avec Azure AD B2C, elles doivent être inscrites dans le locataire de votre client. Ce tutoriel vous montre comment inscrire une application web à l’aide du portail Azure. À des fins de test comme dans ce didacticiel, vous pouvez inscrire https://jwt.ms, une application web Microsoft qui affiche le contenu décodé d’un jeton (le contenu du jeton ne quitte jamais votre navigateur). Pour inscrire une application dans votre locataire Azure AD B2C, utilisez notre nouvelle fonctionnalité d’inscription d’application unifiée.

Connectez-vous au portail Azure.
Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Annuaires + abonnements.
Dans le portail Azure, recherchez et sélectionnez Azure AD B2C.
Sélectionnez Inscriptions d’applications, puis Nouvelle inscription.
Entrez un Nom pour l’application. Par exemple, jwt ms.
Sous Types de comptes pris en charge, sélectionnez Comptes dans un fournisseur d’identité ou annuaire organisationnel (pour authentifier les utilisateurs avec des flux d’utilisateurs) .
Sous URI de redirection, sélectionnez Web, puis entrez https://jwt.ms dans la zone de texte de l’URL.

L’URL de redirection est le point de terminaison sur lequel le serveur d’autorisation, Azure AD B2C dans ce cas, redirige l’utilisateur. Une fois son interaction avec l’utilisateur terminée, un jeton d’accès ou un code d’autorisation est envoyé si l’autorisation est accordée. Dans une application de production, il s’agit généralement d’un point de terminaison accessible publiquement dans lequel votre application s’exécute, comme https://contoso.com/auth-response. À des fins de test comme dans ce didacticiel, vous pouvez le définir sur https://jwt.ms, une application web Microsoft qui affiche le contenu décodé d’un jeton (le contenu du jeton ne quitte jamais votre navigateur). Pendant le développement d’une application, vous pouvez ajouter le point de terminaison sur lequel votre application écoute localement, comme https://localhost:5000. Vous pouvez ajouter des URI de redirection à vos applications inscrites à tout moment et les modifier.

Les restrictions suivantes s’appliquent aux URI de redirection :
- L’URL de réponse doit commencer par le schéma https, sauf si vous utilisez une URL de redirection localhost.
- L’URL de réponse respecte la casse. Sa casse doit correspondre à celle du chemin d’URL de votre application en cours d’exécution. Par exemple, si votre application comprend .../abc/response-oidc dans son chemin d’accès, ne spécifiez pas .../ABC/response-oidc dans l’URL de réponse. Étant donné que le navigateur web considère que les chemins respectent la casse, les cookies associés à .../abc/response-oidc peuvent être exclus s’ils sont redirigés vers l’URL .../ABC/response-oidc qui ne correspond pas à la casse.
- L’URL de réponse doit inclure ou exclure la barre oblique de fin, car votre application l’attend. Par exemple, les chemins d’accès https://contoso.com/auth-response et https://contoso.com/auth-response/ pourraient être traités comme des URL sans correspondance pas dans votre application.
Sous Autorisations, activez la case à cocher Accorder le consentement administrateur aux autorisations openid et offline_access.
Sélectionnez Inscription.

Activer l’octroi implicite du jeton d’ID

Si vous inscrivez cette application et la configurez avec l’application https://jwt.ms/ pour tester un flux utilisateur ou une stratégie personnalisée, vous devez activer le flux d’octroi implicite dans l’inscription de l’application :

Dans le menu de gauche, sous Gérer, sélectionnez Authentification.
Sous Flux d’octroi implicite et flux hybride, sélectionnez les cases à cocher des Jetons d’ID (utilisés pour les flux implicites et hybrides).
Sélectionnez Enregistrer.

Étape 3 : Configurer Trusona Authentication Cloud en tant que fournisseur d’identité dans Azure AD B2C

Connectez-vous au portail Azure en tant qu’administrateur général de votre locataire Azure AD B2C.
Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Annuaires + abonnements.
Choisissez Tous les services dans le coin supérieur gauche du Portail Azure, recherchez et sélectionnez Azure Active Directory B2C.
Accédez à Tableau de bord>Azure Active Directory B2C>Fournisseurs d’identité.
Sélectionnez Fournisseurs d’identité.
Sélectionnez Ajouter.

Configurer un fournisseur d’identité

Sélectionnez Type de fournisseur d’identité>OpenID Connect (préversion) .

Remplissez le formulaire pour configurer le fournisseur d’identité :

Propriété	Valeur
URL de métadonnées	`https://authcloud.trusona.net/.well-known/openid-configuration`
ID client	disponible sur le portail Trusona Authentication Cloud
Clé secrète client	disponible sur le portail Trusona Authentication Cloud
Étendue	E-mail du profil OpenID
Type de réponse	code
Mode de réponse	form_post

Sélectionnez OK.
Sélectionnez Mapper les revendications de ce fournisseur d’identité.
Remplissez le formulaire pour mapper le fournisseur d’identité :

Propriété Valeur

UserID sub

Nom d’affichage nickname

Prénom given_name

Surname family_name

Mode de réponse email
Sélectionnez OK pour terminer la configuration de votre nouveau fournisseur d’identité OIDC.

Propriété	Valeur
UserID	sub
Nom d’affichage	nickname
Prénom	given_name
Surname	family_name
Mode de réponse	email

Étape 4 : Créer une stratégie de flux utilisateur

Trusona apparaît maintenant dans la liste de vos fournisseurs d’identité B2C en tant quenouveau fournisseur d’identité OpenID Connect.

Dans votre locataire Azure AD B2C, sélectionnez Flux d’utilisateurs sous Stratégies.
Sélectionnez Nouveau flux d’utilisateurs.
Sélectionnez successivement Inscription et connexion, une version, puis Créer.
Sous Nom, spécifiez un nom pour votre stratégie.
Dans la section Fournisseurs d’identité, sélectionnez le fournisseur d’identité Trusona Authentication Cloud que vous venez de créer.

Notes

Étant donné que Trusona est intrinsèquement multifacteur, il est préférable de conserver l’authentification multifacteur désactivée.
Sélectionnez Create (Créer).
Sous Attributs utilisateur et revendications, choisissez Afficher plus. Dans le formulaire, sélectionnez au moins un attribut que vous avez spécifié lors de la configuration de votre fournisseur d’identité dans la section précédente.
Sélectionnez OK.

Étape 5 : Tester votre flux d’utilisateurs

Sélectionnez la stratégie créée.
Sélectionnez Exécuter le flux d’utilisateurs, puis sélectionnez les paramètres :

a. Application : sélectionnez l’application inscrite, par exemple, jwt.ms.

b. URL de réponse : sélectionnez l’URL de redirection, par exemple, https://jwt.ms.
Sélectionnez Exécuter le flux utilisateur. Vous êtes redirigé vers Trusona Authentication Cloud. L’utilisateur reçoit une page web de connexion lui demandant son nom d’utilisateur, généralement une adresse e-mail. Si Trusona Authentication Cloud ne trouve pas le compte de l’utilisateur, une réponse est envoyée au navigateur qui initie un processus d’inscription WebAuthn sur l’appareil. Sinon, une réponse est envoyée au navigateur qui commence un processus d’authentification WebAuthn. L’utilisateur est invité à sélectionner les informations d’identification à utiliser. La clé d’accès est associée au domaine de l’application web ou à une clé de sécurité matérielle. Une fois que l’utilisateur a sélectionné les informations d’identification, le système d’exploitation lui demande d’utiliser une donnée biométrique, un code secret ou un code PIN pour confirmer son identité. Cela déverrouille l’environnement Enclave sécurisée/Exécution approuvée, qui génère une assertion d’authentification signée par la clé privée associée aux informations d’identification sélectionnées. Azure AD B2C valide la réponse d’authentification Trusona et émet un jeton OIDC. L’utilisateur est redirigé vers l’application initiale, par exemple, https://jwt.ms, qui affiche le contenu du jeton retourné par Azure AD B2C.

Étape 3 : Créer la clé de stratégie Trusona Authentication Cloud

Stockez la clé secrète client que vous avez générée à l’étape 1 dans votre locataire Azure AD B2C.

Connectez-vous au portail Azure.
Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Annuaires + abonnements.
Choisissez Tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
Dans la page de vue d’ensemble, sélectionnez Infrastructure d’expérience d’identité.
Sélectionnez Clés de stratégie, puis Ajouter.
Dans Options, choisissez Manuel.
Entrez un nom pour la clé de stratégie. Par exemple : TrusonaTacClientSecret. Le préfixe B2C_1A_ est ajouté automatiquement au nom de votre clé.
Dans Secret, entrez la clé secrète client que vous avez enregistrée.
Pour Utilisation de la clé, sélectionnez Signature.
Sélectionnez Create (Créer).

Étape 4 : Configurer Trusona Authentication Cloud en tant que fournisseur d’identité

Conseil

Vous devez avoir configuré la stratégie Azure AD B2C à ce stade. Si ce n’est pas le cas, suivez les instructions sur la configuration de votre client Azure AD B2C et de stratégies.

Pour permettre aux utilisateurs de se connecter avec Trusona Authentication Cloud, vous devez définir Trusona en tant que fournisseur de revendications avec lequel Azure AD B2C peut communiquer via un point de terminaison. Le point de terminaison fournit un ensemble de revendications utilisées par Azure AD B2C pour vérifier qu’un utilisateur spécifique s’est authentifié avec une clé d’accès ou une clé de sécurité matérielle disponible sur son appareil, prouvant ainsi son identité.

Procédez comme suit pour ajouter Trusona en tant que fournisseur de revendications :

Récupérez les packs de démarrage de stratégie personnalisés à partir de GitHub, puis mettez à jour les fichiers XML dans le pack de démarrage LocalAccounts avec votre nom de locataire Azure AD B2C :
1. Téléchargez le fichier .zip ou clonez le référentiel :
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. Dans tous les fichiers du répertoire LocalAccounts, remplacez la chaîne yourtenant par le nom de votre locataire Azure AD B2C. Par exemple, si le nom de votre locataire B2C est contoso, toutes les instances de yourtenant.onmicrosoft.com deviennent contoso.onmicrosoft.com.
Ouvrez le fichier LocalAccounts/TrustFrameworkExtensions.xml.
Recherchez l’élément ClaimsProviders. S’il n’existe pas, ajoutez-le sous l’élément racine, TrustFrameworkPolicy.
Ajoutez un nouveau ClaimsProvider semblable au fournisseur suivant :

<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">00000000-0000-0000-0000-000000000000</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: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></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/11111111-1111-1111-1111-111111111111</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>

Paramétrez client_id avec l’ID d’application de Trusona Authentication Cloud que vous avez enregistré précédemment à l’Étape 1.
Mettez à jour la section client_secret avec le nom de la clé de stratégie créée à l’Étape 3. Par exemple, B2C_1A_TrusonaTacClientSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Enregistrez les changements.

Étape 5 : Ajouter un parcours utilisateur

À ce stade, vous avez défini le fournisseur d’identité, mais il n’est pas encore disponible dans les pages de connexion. Si vous avez votre propre parcours utilisateur personnalisé, passez à l’Étape 6 ; sinon, créez un double d’un modèle de parcours utilisateur existant, comme suit :

Ouvrez le fichier LocalAccounts/TrustFrameworkBase.xml à partir du pack de démarrage.
Recherchez et copiez l’intégralité du contenu de l’élément UserJourney comprenant Id=SignUpOrSignIn.
Ouvrez LocalAccounts/TrustFrameworkExtensions.xml et recherchez l’élément UserJourneys. Si l’élément n’existe pas, ajoutez-en un.
Collez l’intégralité du contenu de l’élément UserJourney que vous avez copié en tant qu’enfant de l’élément UserJourneys.
Renommez l’Id du parcours utilisateur. Par exemple : Id=TrusonaTacSUSI.

Étape 6 : Ajouter le fournisseur d’identité à un parcours utilisateur

Maintenant que vous disposez d’un parcours utilisateur, ajoutez-y le nouveau fournisseur d’identité.

Recherchez l’élément d’étape d’orchestration comprenant Type=CombinedSignInAndSignUp ou Type=ClaimsProviderSelection dans le parcours utilisateur. Il s’agit généralement de la première étape d’orchestration. L’élément ClaimsProviderSelections contient une liste de fournisseurs d’identité avec lesquels un utilisateur peut se connecter. L’ordre des éléments détermine l’ordre des boutons de connexion présentés à l’utilisateur. Ajoutez un élément XML ClaimsProviderSelection. Définissez la valeur TargetClaimsExchangeId sur un nom convivial, tel que TrusonaTacExchange.
À la prochaine étape d’orchestration, ajoutez un élément ClaimsExchange. Définissez l’ID sur la valeur de l’ID cible d’échange des revendications. Mettez à jour la valeur de TechnicalProfileReferenceId sur l’ID du profil technique que vous avez créé précédemment quand vous ajoutiez le fournisseur de revendications, par exemple,TrusonaTAC-OpenIdConnect.

Le code XML suivant montre les étapes d’orchestration d’un parcours utilisateur avec le fournisseur d’identité :

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

En savoir plus sur les parcours utilisateur.

Étape 7 : Configurer la stratégie de partie de confiance

La stratégie relative à un partie de confiance, par exemple SignUpSignIn.xml, spécifie le parcours utilisateur exécuté par Azure AD B2C. Recherchez l’élément DefaultUserJourney dans la partie de confiance. Mettez à jour la valeur ReferenceId afin qu’elle corresponde à l’ID du parcours utilisateur auquel vous avez ajouté le fournisseur d'identité.

Dans l’exemple suivant, pour le parcours utilisateur Trusona Authentication Cloud, la valeur ReferenceId est définie sur 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>

Étape 8 : Charger la stratégie personnalisée

Connectez-vous au portail Azure.
Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Annuaires + abonnements.
Dans le portail Azure, recherchez et sélectionnez Azure AD B2C.
Sous Stratégies, sélectionnez Identity Experience Framework.
Sélectionnez Charger une stratégie personnalisée, puis chargez les deux fichiers de stratégie que vous avez modifiés, dans l’ordre suivant : la stratégie d’extension, par exemple TrustFrameworkExtensions.xml, puis la stratégie de la partie de confiance, par exemple SignUpOrSignin.xml.

Étape 9 : Tester votre stratégie personnalisée

Dans votre locataire Azure AD B2C, sous Stratégies, sélectionnez Identity Experience Framework.
Sous Stratégies personnalisées, sélectionnez TrusonaTacSUSI.
Pour Application, sélectionnez l’application web que vous avez précédemment enregistrée dans le cadre des conditions préalables de cet article. par exemple jwt ms. L’URL de réponse doit être https://jwt.ms.
Sélectionnez Exécuter maintenant. Votre navigateur est redirigé vers la page de connexion de Trusona Authentication Cloud.
Un écran de connexion s’affiche, sur lequel vous trouverez dans la partie inférieure un bouton permettant d’utiliser l’authentification Trusona Authentication Cloud.
Vous êtes redirigé vers Trusona Authentication Cloud. L’utilisateur reçoit une page web de connexion lui demandant son nom d’utilisateur, généralement une adresse e-mail. Si Trusona Authentication Cloud ne trouve pas le compte de l’utilisateur, une réponse est envoyée au navigateur qui initie un processus d’inscription WebAuthn sur l’appareil. Sinon, une réponse est envoyée au navigateur qui commence un processus d’authentification WebAuthn. L’utilisateur est invité à sélectionner les informations d’identification à utiliser. La clé d’accès est associée au domaine de l’application web ou à une clé de sécurité matérielle. Une fois que l’utilisateur a sélectionné les informations d’identification, le système d’exploitation lui demande d’utiliser une donnée biométrique, un code secret ou un code PIN pour confirmer son identité. Cela déverrouille l’environnement Enclave sécurisée/Exécution approuvée, qui génère une assertion d’authentification signée par la clé privée associée aux informations d’identification sélectionnées.
Si le processus de connexion réussit, votre navigateur est redirigé vers https://jwt.ms, qui affiche le contenu du jeton retourné par Azure AD B2C.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :