Configurer Asignio avec Azure Active Directory B2C pour l’authentification multifacteur

Article
01/26/2024

Apprenez à intégrer l'authentification Microsoft Entra ID (Azure AD B2C) avec Asignio. À l’aide de cette intégration, fournissez une expérience d’authentification multifacteur (MFA) sans mot de passe et de biométrie réversible aux clients. Asignio utilise la signature Asignio brevetée et de la vérification faciale dynamique pour l’authentification utilisateur. La signature biométrique modifiable permet de réduire les mots de passe, la fraude, le hameçonnage et la réutilisation des informations d’identification par le biais de l’authentification omnicanal.

Avant de commencer

Choisissez un sélecteur de type de stratégie pour indiquer la configuration du type de stratégie. Azure AD B2C propose deux méthodes pour définir la façon dont les utilisateurs interagissent avec vos applications :

Flux d’utilisateurs prédéfinis
Stratégies personnalisées configurables

Les étapes de cet article diffèrent pour chaque méthode.

En savoir plus :

Prérequis

Un abonnement Azure.
Le cas échéant, procurez-vous un compte Azure gratuit.

Un locataire Azure AD B2C associé à l’abonnement Azure
Voir, Tutoriel : Créer un locataire Azure Active Directory B2C
Un ID client et une clé secrète client Asignio émis par Asignio.
Ces jetons sont obtenus en inscrivant vos applications mobiles ou web auprès d’Asignio.

Pour les stratégies personnalisées

Complétez le Tutoriel : créer des flux d’utilisateurs et des stratégies personnalisées dans Azure AD B2C

Description du scénario

Cette intégration inclut les composants suivants :

Azure AD B2C : serveur d’autorisation qui vérifie les informations d’identification utilisateur
Applications web ou mobiles : à sécuriser avec Asignio MFA
Application web Asignio : collecte biométrique de signature sur l’appareil tactile de l’utilisateur

Le diagramme suivant illustre l’implémentation.

Diagramme illustrant l’architecture de l’implémentation.

L’utilisateur ouvre la page de connexion d’Azure AD B2C sur son application web ou mobile, puis se connecte ou s’inscrit.
Azure AD B2C redirige l’utilisateur vers Asignio à l’aide d’une requête OpenID Connect (OIDC).
L’utilisateur est redirigé vers l’application web Asignio pour la connexion biométrique. Si l’utilisateur n’a pas inscrit sa signature Asignio, il peut utiliser un mot de passe à usage unique (OTP) envoyé par SMS pour s’authentifier. Après l’authentification, l’utilisateur reçoit un lien d’inscription pour créer sa signature Asignio.
L’utilisateur s’authentifie à l’aide de sa signature Asignio et de la vérification faciale ou de la vérification vocale et faciale.
La réponse à la demande est envoyée à Asignio.
Asignio retourne la réponse OIDC à la connexion Azure AD B2C.
Azure AD B2C envoie une demande de vérification d’authentification à Asignio pour confirmer la réception des données d’authentification.
L’accès à l’application est accordé ou refusé à l’utilisateur.

Configurer une application avec Asignio

La configuration d’une application avec Asignio s’effectue avec le site d’administration des partenaires Asignio.

Accédez à asignio.com page Administration des partenaires Asignio pour demander l’accès à votre organisation.
Avec les informations d’identification, connectez-vous à Administration des partenaires Asignio.
Créez un enregistrement pour l’application Azure AD B2C à l’aide de votre locataire Azure AD B2C. Quand vous utilisez Azure AD B2C avec Asignio, Azure AD B2C gère les applications connectées. Les applications Asignio représentent les applications dans le Portail Azure.
Dans le site Administration des partenaires Asignio, générez un ID client et une clé secrète client.
Notez et stockez l’ID client et la clé secrète client. Vous les utiliserez plus tard. Asignio ne stocke pas les clés secrètes client.
Saisissez l'URI de redirection de votre site vers lequel l'utilisateur est renvoyé après l'authentification. Utilisez le modèle d’URI suivant.

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

Chargez un logo de société. Il apparaît sur l’authentification Asignio lorsque les utilisateurs se connectent.

Inscrire une application web dans Azure AD B2C

Pour que les applications puissent interagir avec Azure AD B2C, inscrivez-les dans un locataire que vous gérez.

En savoir plus : Types d’applications pouvant être utilisés dans Active Directory B2C

Pour ce tutoriel, vous inscrivez https://jwt.ms, une application web Microsoft avec un contenu de jeton décodé qui ne quitte pas votre navigateur.

Inscrivez une application web et activez l’octroi implicite de jeton d’ID

Complétez le Tutoriel : inscrire une application web dans Azure Active Directory B2C

Configurer Asignio comme fournisseur d’identité dans Azure AD B2C

Pour les instructions suivantes, utilisez le locataire Microsoft Entra avec l’abonnement Azure.

Connectez-vous au portail Azure en tant qu’administrateur général de votre abonné Azure AD B2C.
Dans la barre d’outils du Portail Azure, sélectionnez Répertoires + abonnements.
Sur les paramètres du portail | Répertoires + abonnements, dans la liste Nom du répertoire, localisez votre répertoire Microsoft Entra.
Sélectionnez Changer.
En haut à gauche du portail Azure, sélectionnez Tous les services.
Recherchez et sélectionnez Azure AD B2C.
Dans le portail Azure, recherchez et sélectionnez Azure AD B2C.
Dans le menu de gauche, sélectionnez Fournisseurs d’identité.
Sélectionnez Nouveau fournisseur OpenID Connect.
Sélectionnez Type de fournisseur d’identité>OpenID Connect.
Pour Nom, entrez la connexion Asignio ou le nom que vous choisissez.
Pour URL de métadonnées, entrez https://authorization.asignio.com/.well-known/openid-configuration.
Pour ID client, entrez l’ID client que vous avez généré.
Pour Clé secrète client, entrez la clé secrète client que vous avez générée.
Pour Étendue, utilisez l’adresse e-mail de profil OpenID.
Pour Type de réponse, utilisez code.
Pour Mode de réponse, utilisez requête.
Pour Indicateur de domaine, utilisez https://asignio.com.
Sélectionnez OK.
Sélectionnez Mapper les revendications de ce fournisseur d’identité.
Pour ID d’utilisateur, utilisez sub.
Pour Nom d’affichage, utilisez nom.
Pour Prénom, utilisez prénom.
Pour Nom de famille, utilisez nom de famille.
Pour Email, utilisez email.
Sélectionnez Enregistrer.

Créer une stratégie de flux utilisateur

Dans votre locataire Azure AD B2C, sélectionnez Flux d’utilisateurs sous Stratégies.
Sélectionnez Nouveau flux d’utilisateurs.
Sélectionnez le flux d’utilisateurs Inscription et connexion.
Sélectionnez Version recommandée.
Sélectionnez Create (Créer).
Saisissez un nom de flux d'utilisateurs, tel que AsignioSignupSignin.
Sous Fournisseurs d’identité, pour Comptes locaux, sélectionnez Aucun. Cette action désactive l’authentification par e-mail et par mot de passe.
Pour Fournisseurs d’identité personnalisés, sélectionnez le fournisseur D’identité Asignio créé.
Sélectionnez Create (Créer).

Tester votre flux d’utilisateur

Dans votre locataire Azure AD B2C, sélectionnez Flux d’utilisateur.
Sélectionnez le flux d’utilisateur créé.
Pour Application, sélectionnez l’application web que vous avez inscrite. L’URL de réponse est https://jwt.ms.
Sélectionnez Exécuter le flux utilisateur.
Le navigateur est redirigé vers la page de connexion Asignio.
Un écran de connexion s’affiche.
En bas, sélectionnez authentification Asignio.

Si vous avez une signature Asignio, renseignez l’invite pour vous authentifier. Si ce n’est pas le cas, indiquez le numéro de téléphone de l’appareil à authentifier via SMS OTP. Utilisez le lien pour inscrire votre signature Asignio.

Le navigateur est redirigé vers https://jwt.ms. Le contenu du jeton retourné par Azure AD B2C s’affiche.

Créer une clé de stratégie Asignio

Stockez la clé secrète client générée dans le locataire Azure AD B2C.
Connectez-vous au portail Azure.
Sélectionnez l’icône Répertoires + abonnements dans la barre d’outils du portail.
Sur Paramètres du portail | Répertoires + abonnements, dans la liste Nom de répertoire, repérez votre répertoire Azure AD B2C.
Sélectionnez Changer.
En haut à gauche du portail Azure, sélectionnez Tous les services.
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.
Sélectionnez Ajouter.
Pour Options, sélectionnez Manuel.
Entrez un nom de clé de stratégie pour la clé de stratégie. Le préfixe B2C_1A_ est ajouté au nom de clé.
Dans Secret, entrez la clé secrète client que vous avez notée.
Pour Utilisation de la clé, sélectionnez Signature.
Sélectionnez Create (Créer).

Configurer Asignio comme fournisseur d’identité

Conseil

Avant de commencer, vérifiez que la stratégie Azure AD B2C est configurée. Si ce n’est pas le cas, suivez les instructions du pack de démarrage de stratégie personnalisée.

Pour que les utilisateurs se connectent avec Asignio, définissez Asignio comme fournisseur de revendications avec lequel Azure AD B2C peut communiquer via un point de terminaison. Le point de terminaison fournit des revendications utilisées par Azure AD B2C pour vérifier l’authentification de l’utilisateur sur son appareil avec un ID numérique.

Ajouter Asignio 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 :

Téléchargez le fichier zip active-directory-b2c-custom-policy-starterpack ou clonez le référentiel :
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
Dans tous les fichiers du répertoire LocalAccounts, remplacez la chaîne yourtenant par le nom de votre locataire Azure AD B2C.
Open the LocalAccounts/ TrustFrameworkExtensions.xml.
Recherchez l’élément ClaimsProviders. S’il n’y en a pas, ajoutez-le sous l’élément racine, TrustFrameworkPolicy.

Ajoutez un nouveau ClaimsProvider semblable au fournisseur suivant :

 <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">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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>

Définissez client_id avec l’ID d’application Asignio que vous avez noté.
Mettez à jour la section client_secret avec la clé de stratégie créée. Par exemple, B2C_1A_AsignioSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
Enregistrez les changements.

Ajouter un parcours utilisateur

Le fournisseur d’identité ne figure pas sur les pages de connexion.

Si vous disposez d’un parcours utilisateur personnalisé , continuez à configurer la stratégie de partie de confiance. Sinon, copiez un modèle de parcours utilisateur :
Dans le pack de démarrage, ouvrez localAccounts/TrustFrameworkBase.xml.
Recherchez et copiez l’intégralité du contenu de l’élément UserJourney comprenant Id=SignUpOrSignIn.
Open the LocalAccounts/ TrustFrameworkExtensions.xml.
Repérez l’élément UserJourneys. S’il n’y en a pas, ajoutez-en un.
Collez le contenu de l’élément UserJourney en tant qu’enfant de l’élément UserJourneys.]
Renommez l’ID du parcours utilisateur. Par exemple : Id=AsignioSUSI.

En savoir plus : Parcours utilisateur

Ajoutez le fournisseur d’identité à un parcours utilisateur

Ajoutez le nouveau fournisseur d’identité au parcours utilisateur.

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 dispose d’une liste de fournisseurs d’identité utilisés pour la connexion. L’ordre des éléments contrôle l’ordre des boutons de connexion vus par l’utilisateur.
Ajoutez un élément XML ClaimsProviderSelection.
Définissez la valeur TargetClaimsExchangeId sur un nom convivial.
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 vers l’ID du profil technique que vous avez créé.

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

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

Configurer la stratégie de partie de confiance

La stratégie de la partie de confiance, par exemple SignUpSignIn.xml, spécifie le parcours utilisateur exécuté par Azure AD B2C.

Dans la partie de confiance, recherchez l’élément DefaultUserJourney.
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 AsignioSUSI, la valeur ReferenceId est définie sur 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>

Téléchargez la stratégie personnalisée

Connectez-vous au portail Azure.
Sélectionnez l’icône Répertoires + abonnements dans la barre d’outils du portail.
Sur Paramètres du portail | Répertoires + abonnements, dans la liste Nom de répertoire, repérez votre répertoire Azure AD B2C.
Sélectionnez Changer.
Dans la 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.
Chargez dans l’ordre suivant les deux fichiers de stratégie que vous avez modifiés :

Stratégie d’extension, par exemple TrustFrameworkExtensions.xml.
Stratégie de la partie de confiance, comme SignUpOrSignin.xml.

Tester votre stratégie personnalisée

Dans votre locataire Azure AD B2C, puis, sous Stratégies, sélectionnez Identity Experience Framework.
Sous Stratégies personnalisées, sélectionnez AsignioSUSI.
Pour Application, sélectionnez l’application web que vous avez inscrite. L’URL de réponse est https://jwt.ms.
Sélectionnez Exécuter maintenant.
Le navigateur est redirigé vers la page de connexion Asignio.
Un écran de connexion s’affiche.
En bas, sélectionnez authentification Asignio.

Si vous disposez d’une signature Asignio, vous êtes invité à vous authentifier à l’aide de celle-ci. Si ce n’est pas le cas, indiquez le numéro de téléphone de l’appareil à authentifier via SMS OTP. Utilisez le lien pour inscrire votre signature Asignio.

Le navigateur est redirigé vers https://jwt.ms. Le contenu du jeton retourné par Azure AD B2C s’affiche.

Partager via