Skapa förgrening i användarresan med hjälp av en anpassad azure Active Directory B2C-princip

Artikel
01/11/2024

Olika användare av samma app kan följa olika användarresor beroende på värdena för data i en anpassad princip. Med anpassade principer för Azure Active Directory B2C (Azure AD B2C) kan du villkorligt aktivera eller inaktivera en teknisk profil för att uppnå den här funktionen. I Verifiera användarindata med hjälp av anpassad Azure AD B2C-princip använde vi till exempel en Precondition för att avgöra om vi ska köra en teknisk valideringsprofil baserat på värdet för accountType-anspråket.

En teknisk profil innehåller också ett EnabledForUserJourneys element som gör att du kan ange om en teknisk profil ska köras eller inte. Elementet EnabledForUserJourneys innehåller ett av fem värden, inklusive OnClaimsExistence, som du använder för att ange att en teknisk profil endast ska köras när ett visst anspråk som anges i den tekniska profilen finns. Läs mer om den tekniska profilens EnabledForUserJourneys-element .

Scenarioöversikt

I artikeln Verifiera användarindata med hjälp av anpassad princip i Azure AD B2C anger en användare sin information på en enda skärm. I den här artikeln måste en användare först välja sin kontotyp, Contosos personalkonto eller personliga konto. En användare som väljer Contosos personalkonto kan fortsätta med att ange ytterligare information. En användare som väljer Personligt konto måste dock ange en giltig kod för åtkomst till inbjudan innan de kan fortsätta med att ange ytterligare information. Därför kan användare som använder kontotypen Personligt konto se ett extra användargränssnitt för att slutföra sin resa.

A flowchart of branching in user journey.

I den här artikeln får du lära dig hur du använder EnabledForUserJourneys element i en teknisk profil för att skapa olika användarupplevelser baserat på ett anspråksvärde.

Förutsättningar

Om du inte redan har en skapar du en Azure AD B2C-klientorganisation som är länkad till din Azure-prenumeration.
Registrera ett webbprogram och aktivera implicit beviljande av ID-token. För omdirigerings-URI använder du https://jwt.ms.
Visual Studio Code (VS Code) måste vara installerat på datorn.
Slutför stegen i Verifiera användarindata med hjälp av en anpassad Azure AD B2C-princip. Den här artikeln är en del av guideserien Skapa och kör egna anpassade principer.

Kommentar

Den här artikeln är en del av guideserien Skapa och köra egna anpassade principer i Azure Active Directory B2C. Vi rekommenderar att du startar den här serien från den första artikeln.

Steg 1 – Deklarera anspråk

En användare som väljer Personligt konto måste ange en giltig åtkomstkod. Därför behöver vi ett anspråk för att lagra det här värdet:

Öppna filen i ContosoCustomPolicy.XML VS Code.

I avsnittet ClaimsSchema deklarerar du accessCode- och isValidAccessCode-anspråk med hjälp av följande kod:

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

Steg 2 – Definiera anspråkstransformeringar

Leta upp elementet ClaimsTransformations och lägg till följande anspråkstransformeringar:

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

Vi har definierat två anspråkstransformeringar, CheckIfIsValidAccessCode och ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode använder transformeringsmetoden CompareClaimToValue för att jämföra användarens åtkomstkodsindata med ett statiskt värde 88888 (vi använder det här värdet för testning) och tilldelar true eller false till isValidAccessCode-anspråk . ThrowIfIsNotValidAccessCode kontrollerar om två booleska värden för två anspråk är lika med eller inte och utlöser ett undantag om de inte är det.

Steg 3 – Konfigurera eller uppdatera tekniska profiler

Nu behöver du två nya självsäkra tekniska profiler, en för att samla in kontotypen och den andra för att samla in åtkomstkod från användaren. Du behöver också en ny teknisk profil för anspråkstransformeringstyp för att verifiera användarens åtkomstkod genom att köra anspråkstransformeringar som du definierade i steg 2. Nu när vi samlar in kontotypen i en annan självsäkrad teknisk profil måste vi uppdatera den UserInformationCollector självsäkra tekniska profilen för att förhindra att den samlar in kontotypen.

Leta upp elementet ClaimsProviders och lägg sedan till en ny anspråksprovider med hjälp av följande kod:

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

Vi har konfigurerat två tekniska profiler, AccessCodeInputCollector och CheckAccessCodeViaClaimsTransformationChecker. Vi anropar den tekniska profilen CheckAccessCodeViaClaimsTransformationChecker som en teknisk valideringsprofil från den tekniska profilen AccessCodeInputCollector . CheckAccessCodeViaClaimsTransformationChecker är av typen Teknisk profil för anspråksomvandling, som kör de anspråksomvandlingar som vi definierade i steg 2.

AccessCodeInputCollector är en självsäkrad teknisk profil som används för att samla in en åtkomstkod från användaren. Den innehåller EnabledForUserJourneys element som är inställt på OnClaimsExistence. Dess Metadata element innehåller ett anspråk (accountType) och dess värde (personligt) som aktiverar den här tekniska profilen.

Leta upp elementet ClaimsProviders och lägg sedan till en ny anspråksprovider med hjälp av följande kod:

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

Vi har konfigurerat en egensäkrad teknisk profil, AccountTypeInputCollector, som samlar in användarens kontotyp. Det är kontotypernas värde som avgör om den AccessCodeInputCollector självsäkra tekniska profilen ska aktiveras.

Om du vill förhindra att den UserInformationCollector självsäkra tekniska profilen samlar in kontotypen letar du upp den UserInformationCollector självsäkra tekniska profilen och sedan:
1. Ta bort visningsanspråket accountType <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> DisplayClaims från samlingen.
2. Ta bort utdataanspråket accountType , <OutputClaim ClaimTypeReferenceId="accountType"/>från OutputClaims samlingen.

Steg 4 – Uppdatera orkestreringsstegen för användarens resa

Nu när du har konfigurerat dina tekniska profiler måste du uppdatera orkestreringsstegen för användarresan:

Leta upp din HelloWorldJourney användarresa och lägg till ersätt alla orkestreringssteg med följande kod:

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

Orkestreringsstegen visar att vi anropar den tekniska profilen i den ordning som visas av orkestreringsstegens Order attribut. Den tekniska profilen aktiveras dock AccessCodeInputCollector om användaren väljer typ av personligt konto .

Steg 5 – Ladda upp anpassad principfil

Följ stegen i Ladda upp en anpassad principfil för att ladda upp principfilen. Om du laddar upp en fil med samma namn som den som redan finns i portalen kontrollerar du att du väljer Skriv över den anpassade principen om den redan finns.

Steg 6 – Testa den anpassade principen

Följ stegen i Testa den anpassade principen för att testa din anpassade princip:

På den första skärmen väljer du Personligt konto för Kontotyp.
För Åtkomstkod anger du 88888 och väljer sedan Fortsätt.
Ange resten av informationen efter behov och välj sedan Fortsätt. När principen har slutfört körningen omdirigeras du till https://jwt.msoch du ser en avkodad JWT-token.
Upprepa steg 5, men den här gången väljer du Kontotyp, väljer Contoso Employee Account och följer sedan anvisningarna.

Nästa steg

I steg 3 aktiverar eller inaktiverar vi den tekniska profilen med hjälp av elementet EnabledForUserJourneys . Du kan också använda Förhandsvillkor i orkestreringsstegen för användarresan för att köra eller hoppa över ett orkestreringssteg som vi lär oss senare i den här serien.

Lär dig sedan:

Om förhandsvillkor för orkestrering av användarresor.
Så här använder du schemafilen TrustFrameworkPolicy för att verifiera Azure AD B2C-principfiler.

Dela via