Créer une branche dans le parcours utilisateur à l’aide d’une stratégie Azure Active Directory B2C personnalisée

Article
01/11/2024

Différents utilisateurs de la même application peuvent suivre des parcours utilisateur différents en fonction des valeurs des données d’une stratégie personnalisée. Les stratégies Azure Active Directory B2C (Azure AD B2C) personnalisées vous permettent d’activer ou de désactiver de manière conditionnelle un profil technique pour atteindre cette fonctionnalité. Par exemple, dans la fonction Valider les entrées utilisateur à l’aide d’une stratégie Azure AD B2C personnalisée, nous avons utilisé un Precondition pour déterminer si nous devons exécuter ou non un profil technique de validation en fonction de la valeur de la revendication accountType.

Un profil technique fournit également un élément EnabledForUserJourneys pour vous permettre de spécifier si un profil technique doit s’exécuter ou non. L’élément EnabledForUserJourneys contient l’une des cinq valeurs, y compris OnClaimsExistence, que vous utilisez pour spécifier qu’un profil technique ne doit s’exécuter que lorsqu’il existe une certaine revendication spécifiée dans le profil technique. En savoir plus sur l’élément EnabledForUserJourneys du profil technique.

Présentation du scénario

Dans l’article Valider les entrées utilisateur à l’aide de la stratégie Azure AD B2C personnalisée, un utilisateur entre ses informations dans un seul écran. Dans cet article, un utilisateur doit d’abord sélectionner son type de compte, Compte d’employé Contoso ou Compte personnel. Un utilisateur qui sélectionne le Compte d’employé Contoso peut continuer à fournir d’autres détails. Toutefois, un utilisateur qui sélectionne le Compte personnel doit fournir un code d’accès d’invitation valide avant de pouvoir fournir d’autres détails. Par conséquent, les utilisateurs qui utilisent le type de compte Compte personnel voient une interface utilisateur supplémentaire pour terminer leur parcours.

A flowchart of branching in user journey.

Dans cet article, vous apprenez à utiliser l’élément EnabledForUserJourneys au sein d’un profil technique pour créer différentes expériences utilisateur basées sur une valeur de revendication.

Prérequis

Si vous n’en avez pas, créez un locataire Azure AD B2C qui est lié à votre abonnement Azure.
Inscrivez une application web et activez l’octroi implicite de jeton d’ID. Pour l’URI de redirection, utilisez https://jwt.ms.
Visual Studio Code (VS Code) doit être installé sur votre ordinateur.
Effectuez les étapes décrites dans Valider des entrées utilisateur à l’aide de la stratégie Azure AD B2C personnalisée. Cet article fait partie de la série de guides pratiques Créer et exécuter vos propres stratégies personnalisées.

Notes

Cet article fait partie de la série de guides pratiques Créer et exécuter vos propres stratégies personnalisées dans Azure Active Directory B2C. Nous vous recommandons de commencer cette série par le premier article.

Étape 1 : Déclarer des revendications

Un utilisateur qui sélectionne un Compte personnel doit fournir un code d’accès valide. Nous avons donc besoin d’une revendication pour contenir cette valeur :

Dans VS Code, ouvrez le fichier ContosoCustomPolicy.XML.

Dans la section ClaimsSchema, déclarez les revendications accessCode et isValidAccessCode à l’aide du code suivant :

    <ClaimType Id="accessCode">
        <DisplayName>Access Code</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Enter your invitation access code.</UserHelpText>
        <UserInputType>Password</UserInputType>
        <Restriction>
            <Pattern RegularExpression="[0-9][0-9][0-9][0-9][0-9]" HelpText="Please enter your invitation access code. It's a 5-digit number, something like 95765"/>
        </Restriction>
    </ClaimType>
    <ClaimType Id="isValidAccessCode">
        <DataType>boolean</DataType>
    </ClaimType>

Étape 2 : Définir les transformations de revendications

Localisez l’élément ClaimsTransformations et ajoutez les transformations des revendications suivantes :

    <!---<ClaimsTransformations>-->
        <ClaimsTransformation Id="CheckIfIsValidAccessCode" TransformationMethod="CompareClaimToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="accessCode" TransformationClaimType="inputClaim1"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="compareTo" DataType="string" Value="88888"/>
                <InputParameter Id="operator" DataType="string" Value="equal"/>
                <InputParameter Id="ignoreCase" DataType="string" Value="true"/>
            </InputParameters>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="outputClaim"/>
            </OutputClaims>
        </ClaimsTransformation>
        <ClaimsTransformation Id="ThrowIfIsNotValidAccessCode" TransformationMethod="AssertBooleanClaimIsEqualToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="inputClaim"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="valueToCompareTo" DataType="boolean" Value="true"/>
            </InputParameters>
        </ClaimsTransformation>
    <!---</ClaimsTransformations>-->

Nous avons défini deux transformations de revendications, CheckIfIsValidAccessCode et ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode utilise la méthode de transformation CompareClaimToValue pour comparer l’entrée du code d’accès par l’utilisateur à une valeur statique de 88888 (nous allons utiliser cette valeur pour les tests) et affecte true ou false à la revendication isValidAccessCode. ThrowIfIsNotValidAccessCode vérifie si deux valeurs booléennes de deux revendications sont égales et lève une exception dans le cas contraire.

Étape 3 : Configurer ou mettre à jour des profils techniques

Vous avez maintenant besoin de deux nouveaux profils techniques déclarés automatiquement, l’un pour collecter le type de compte et l’autre pour collecter le code d’accès de l’utilisateur. Vous avez également besoin d’un nouveau profil technique de type de transformation des revendications pour valider le code d’accès de l’utilisateur en exécutant les transformations des revendications que vous avez définies à l’étape 2. Maintenant que nous collectons le type de compte dans un profil technique autodéclaré différent, nous devons mettre à jour le profil technique déclaré automatiquement UserInformationCollector pour l’empêcher de collecter le type de compte.

Recherchez l’élément ClaimsProviders, puis ajoutez un nouveau fournisseur de revendications à l’aide du code suivant :

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profiles to collect user's access code</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccessCodeInputCollector">
                    <DisplayName>Collect Access Code Input from user Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                        <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">The access code is invalid.</Item>
                        <Item Key="ClaimTypeOnWhichToEnable">accountType</Item>
                        <Item Key="ClaimValueOnWhichToEnable">personal</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accessCode" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accessCode"/>
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                        <ValidationTechnicalProfile ReferenceId="CheckAccessCodeViaClaimsTransformationChecker"/>
                    </ValidationTechnicalProfiles>
                    <EnabledForUserJourneys>OnClaimsExistence</EnabledForUserJourneys>
                </TechnicalProfile>
                <TechnicalProfile Id="CheckAccessCodeViaClaimsTransformationChecker">
                    <DisplayName>A Claims Transformations to check user's access code validity</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="isValidAccessCode"/>
                    </OutputClaims>
                    <OutputClaimsTransformations>
                        <OutputClaimsTransformation ReferenceId="CheckIfIsValidAccessCode"/>
                        <OutputClaimsTransformation ReferenceId="ThrowIfIsNotValidAccessCode"/>
                    </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Nous avons configuré deux profils techniques, AccessCodeInputCollector et CheckAccessCodeViaClaimsTransformationChecker. Nous appelons le profil technique CheckAccessCodeViaClaimsTransformationChecker comme profil technique de validation à partir du profil technique AccessCodeInputCollector . Le profil CheckAccessCodeViaClaimsTransformationChecker lui-même est de type Profil technique de transformation des revendications, qui exécute les transformations des revendications que nous avons définies à l’étape 2.

AccessCodeInputCollector est un profil technique autodéclaré utilisé pour collecter un code d’accès auprès de l’utilisateur. Il inclut l’élément EnabledForUserJourneys défini sur OnClaimsExistence. Son élément Metadata inclut une revendication (accountType) et sa valeur (personnel) qui active ce profil technique.

Recherchez l’élément ClaimsProviders, puis ajoutez un nouveau fournisseur de revendications à l’aide du code suivant :

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profile to collect user's accountType</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccountTypeInputCollector">
                    <DisplayName>Collect User Input Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accountType"/>
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Nous avons configuré un profil technique déclaré automatiquement, AccountTypeInputCollector, qui collecte le type de compte de l’utilisateur. C’est la valeur des types de compte qui détermine si le profil technique autodéclaré AccessCodeInputCollector doit être activé.

Pour empêcher le profil technique autodéclaré UserInformationCollector de collecter le type de compte, localisez le profil technique autodéclaré UserInformationCollector, puis :
1. Supprimez la revendication d’affichage accountType, <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> de la collection DisplayClaims.
2. Supprimez la revendication de sortie accountType, <OutputClaim ClaimTypeReferenceId="accountType"/>, de la collection OutputClaims.

Étape 4 : Mettre à jour les étapes d’orchestration du parcours utilisateur

Vous avez maintenant configuré vos profils techniques et vous devez mettre à jour vos étapes d’orchestration du parcours utilisateur :

Localisez votre parcours utilisateur HelloWorldJourney et ajoutez remplacer toutes les étapes d’orchestration par le code suivant :

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="ClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

Les étapes d’orchestration montrent que nous appelons le profil technique dans l’ordre indiqué par l’attribut Order des étapes d’orchestration. Toutefois, le profil technique AccessCodeInputCollector est activé si l’utilisateur sélectionne le type de compte Compte personnel.

Étape 5 : Charger le fichier de stratégie personnalisée

Suivez les étapes décrites dans Charger un fichier de stratégie personnalisée pour charger votre fichier de stratégie. Si vous chargez un fichier portant le même nom que celui déjà présent dans le portail, veillez à sélectionner Remplacer la stratégie personnalisée si elle existe déjà.

Étape 6 : Tester la stratégie personnalisée

Suivez les étapes décrites dans Tester la stratégie personnalisée pour tester votre stratégie personnalisée :

Sur le premier écran, pour Type de compte, sélectionnez Compte personnel.
Pour le Code d’accès, entrez 88888, puis sélectionnez Continuer.
Entrez le reste des détails en fonction des besoins, puis sélectionnez Continuer. Une fois l’exécution de la stratégie terminée, vous êtes redirigé vers https://jwt.ms et le jeton JWT décodé s’affiche.
Répétez l’étape 5, mais cette fois, sélectionnez Type de compte, Compte d’employé Contoso, puis suivez les invites.

Étapes suivantes

À l’étape 3, nous activons ou désactivons le profil technique à l’aide de l’élément EnabledForUserJourneys. Vous pouvez également utiliser des conditions préalables dans les étapes d’orchestration du parcours utilisateur pour exécuter ou ignorer une étape d’orchestration, comme nous le découvrirons plus loin dans cette série.

Découvrez ensuite :

Share via