Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
Découvrez comment intégrer l’authentification Azure Active Directory B2C (Azure AD B2C) à la technologie BioCatch pour augmenter votre posture de sécurité CIAM (Customer Identity and Access Management). Les produits BioCatch analysent les comportements numériques physiques et cognitifs des utilisateurs pour obtenir des insights qui permettent de distinguer les clients légitimes.
Accédez à biocatch.com pour en savoir plus sur BioCatch
Conditions préalables
Pour commencer, vous avez besoin des éléments suivants :
- Un abonnement Azure
- Si vous n’en avez pas, obtenez un compte gratuit Azure
- Un locataire Azure AD B2C lié à l’abonnement Azure
- Accédez à la page biocatch.com Contactez-nous pour demander un compte
- Mentionner l’intégration d’Azure AD B2C
Description du scénario
L’intégration de BioCatch inclut les composants suivants :
-
Une application web ou un service web : les utilisateurs accèdent à ce service web qui instancie un ID de session client unique qui accède à BioCatch
- L’ID de session transmet les caractéristiques de comportement de l’utilisateur à BioCatch
- Méthode : envoie l’ID de session à Azure AD B2C. Dans l’exemple, JavaScript entre la valeur dans un champ HTML masqué.
- Une interface utilisateur personnalisée Azure AD B2C - masque un champ HTML pour l’entrée d’ID de session à partir de JavaScript
-
Stratégie personnalisée Azure AD B2C :
- Prend l’ID de session comme revendication via un profil technique autodéclaré
- S’intègre à BioCatch via un fournisseur de revendications d’API REST et transmet l’ID de session à BioCatch
- Plusieurs revendications personnalisées sont retournées à partir de BioCatch pour la logique de stratégie personnalisée
- Un parcours utilisateur évalue une revendication retournée et exécute une action conditionnelle, telle que l’authentification multifacteur
Pour en savoir plus:
- Vue d’ensemble de la stratégie personnalisée Azure AD B2C
- Tutoriel : Créer des flux utilisateur et des stratégies personnalisées dans Azure AD B2C
Le diagramme suivant illustre les flux utilisateur avec des informations de session.
- L’utilisateur accède au service web, qui retourne des valeurs HTML, CSS ou JavaScript, puis charge le Kit de développement logiciel (SDK) JavaScript BioCatch. JavaScript côté client configure un ID de session client pour le Kit de développement logiciel (SDK) BioCatch. Sinon, le service web préconfigure l’ID de session client et l’envoie au client. Vous pouvez configurer le Kit de développement logiciel (SDK) JavaScript BioCatch instancié pour BioCatch, qui envoie le comportement utilisateur à BioCatch à partir de l’appareil client, à l’aide de l’ID de session client.
- L’utilisateur s’inscrit ou se connecte et est redirigé vers Azure AD B2C.
- Le parcours utilisateur inclut un fournisseur de déclarations auto-asserté, qui saisit l’ID de session client. Ce champ est masqué. Utilisez JavaScript pour entrer l’ID de session dans le champ. Sélectionnez Suivant pour continuer l’inscription ou la connexion. L’ID de session passe à BioCatch pour un score de risque. BioCatch retourne des informations de session et recommande d’autoriser ou de bloquer. Le parcours utilisateur comporte une vérification conditionnelle, qui agit sur les revendications retournées.
- En fonction du résultat de la vérification conditionnelle, une action est déclenchée.
- Le service web peut utiliser l’ID de session pour interroger l’API BioCatch pour déterminer les risques et les informations de session.
Commencer avec BioCatch
Accédez à la page biocatch.com Contactez-nous pour lancer un compte.
Configurer l’interface utilisateur personnalisée
Nous vous recommandons de masquer le champ ID de session client avec CSS, JavaScript ou une autre méthode. Pour le test, affichez le champ. Par exemple, JavaScript masque le champ d’entrée comme suit :
document.getElementById("clientSessionId").style.display = 'none';
Configurer des stratégies Azure AD B2C Identity Experience Framework
Pour commencer, consultez tutoriel : Créer des flux utilisateur et des stratégies personnalisées dans Azure AD B2C.
Créez un fichier qui hérite du fichier d’extensions.
<BasePolicy> <TenantId>tenant.onmicrosoft.com</TenantId> <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId> </BasePolicy>Créez une référence à l’interface utilisateur personnalisée pour masquer la zone d’entrée, sous la ressource BuildingBlocks.
<ContentDefinitions> <ContentDefinition Id="api.selfasserted"> <LoadUri>https://domain.com/path/to/selfAsserted.cshtml</LoadUri> <DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.0</DataUri> </ContentDefinition> </ContentDefinitions>Sous la ressource BuildingBlocks, ajoutez les revendications suivantes.
<ClaimsSchema> <ClaimType Id="riskLevel"> <DisplayName>Session risk level</DisplayName> <DataType>string</DataType> </ClaimType> <ClaimType Id="score"> <DisplayName>Session risk score</DisplayName> <DataType>int</DataType> </ClaimType> <ClaimType Id="clientSessionId"> <DisplayName>The ID of the client session</DisplayName> <DataType>string</DataType> <UserInputType>TextBox</UserInputType> </ClaimType> </ClaimsSchema>Configurez un fournisseur de revendications autodéclaré pour le champ ID de session client.
<ClaimsProvider> <DisplayName>Client Session ID Claims Provider</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="login-NonInteractive-clientSessionId"> <DisplayName>Client Session ID TP</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item> </Metadata> <CryptographicKeys> <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> </CryptographicKeys> <!—Claim we created earlier --> <OutputClaims> <OutputClaim ClaimTypeReferenceId="clientSessionId" Required="false" DefaultValue="100"/> </OutputClaims> <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" /> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>Configurez un fournisseur de revendications d’API REST pour BioCatch.
<TechnicalProfile Id="BioCatch-API-GETSCORE"> <DisplayName>Technical profile for BioCatch API to return session information</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="ServiceUrl">https://biocatch-url.com/api/v6/score?customerID=<customerid>&action=getScore&uuid=<uuid>&customerSessionID={clientSessionId}&solution=ATO&activtyType=<activity_type>&brand=<brand></Item> <Item Key="SendClaimsIn">Url</Item> <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item> <!-- Set AuthenticationType to Basic or ClientCertificate in production environments --> <Item Key="AuthenticationType">None</Item> <!-- REMOVE the following line in production environments --> <Item Key="AllowInsecureAuthInProduction">true</Item> </Metadata> <InputClaims> <InputClaim ClaimTypeReferenceId="clientsessionId" /> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="riskLevel" /> <OutputClaim ClaimTypeReferenceId="score" /> </OutputClaims> <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" /> </TechnicalProfile> </TechnicalProfiles>Remarque
BioCatch fournit l’URL, l’ID client et l’ID utilisateur unique (UUID). La revendication SessionID du client est transmise comme paramètre de chaîne de requête à BioCatch. Vous pouvez sélectionner le type d’activité, par exemple MAKE_PAYMENT.
Configurez le parcours utilisateur à l’aide de l’exemple suivant :
- Obtenez le clientSessionID en tant que revendication.
- Appelez l’API BioCatch pour obtenir les informations de session.
- Si le risque de réclamation renvoyé est faible, ignorez l'étape pour MFA, sinon appliquez MFA utilisateur.
<OrchestrationStep Order="8" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="clientSessionIdInput" TechnicalProfileReferenceId="login-NonInteractive-clientSessionId" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="9" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="BcGetScore" TechnicalProfileReferenceId=" BioCatch-API-GETSCORE" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="10" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>riskLevel</Value> <Value>LOW</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" /> </ClaimsExchanges>Configurer la partie prenante (facultatif). Vous pouvez transmettre les informations retournées par BioCatch à votre application en tant que revendications dans le jeton : niveau de risque et score.
<RelyingParty> <DefaultUserJourney ReferenceId="SignUpOrSignInMfa" /> <UserJourneyBehaviors> <SingleSignOn Scope="Tenant" KeepAliveInDays="30" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>1200</SessionExpiryInSeconds> <ScriptExecution>Allow</ScriptExecution> </UserJourneyBehaviors> <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="riskLevel" /> <OutputClaim ClaimTypeReferenceId="score" /> <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" /> </OutputClaims> <SubjectNamingInfo ClaimType="sub" /> </TechnicalProfile> </RelyingParty>
Intégrer avec Azure AD B2C
Ajoutez les fichiers de stratégie à Azure AD B2C. Pour les instructions ci-dessous, utilisez le répertoire avec le client Azure AD B2C.
- Connectez-vous au portail Azure en tant que, au minimum, administrateur de stratégie IEF B2C du locataire Azure AD B2C.
- Dans la barre d’outils du portail, sélectionnez Répertoires + abonnements.
- Dans les paramètres du portail, les répertoires + la page abonnements , dans la liste des noms d’annuaire , recherchez le répertoire Azure AD B2C.
- Sélectionnez Changer.
- Dans le coin supérieur gauche du portail Azure, sélectionnez Tous les services.
- Recherchez et sélectionnez Azure AD B2C.
- Accédez à Azure AD B2C>Identity Experience Framework.
- Chargez les fichiers de stratégie sur le locataire.
Test de la solution
Pour obtenir les instructions suivantes, consultez Tutoriel : Inscrire une application web dans Azure Active Directory B2C
Inscrivez une application factice qui redirige vers JWT.MS.
Sous Identity Experience Framework, sélectionnez la stratégie que vous avez créée.
Dans la fenêtre de stratégie, sélectionnez l’application JWT.MS factice
Sélectionnez Exécuter maintenant.
Effectuez un flux d’inscription et créez un compte.
Le jeton renvoyé à JWT.MS doit avoir 2 revendications pour riskLevel et score.
Utilisez l’exemple suivant.
{ "typ": "JWT", "alg": "RS256", "kid": "_keyid" }.{ "exp": 1615872580, "nbf": 1615868980, "ver": "1.0", "iss": "https://tenant.b2clogin.com/12345678-1234-1234-1234-123456789012/v2.0/", "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb", "aud": "00001111-aaaa-2222-bbbb-3333cccc4444", "acr": "b2c_1a_signup_signin_biocatch_policy", "nonce": "defaultNonce", "iat": 1615868980, "auth_time": 1615868980, "name": "John Smith", "email": "john.smith@contoso.com", "given_name": "John", "family_name": "Smith", "riskLevel": "LOW", "score": 275, "tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff" }.[Signature]