Erstellen von Verzweigungen in User Journeys mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie

Artikel
01/11/2024

Unterschiedliche Benutzer derselben Anwendung können je nach den Werten der Daten in einer benutzerdefinierten Richtlinie unterschiedliche User Journeys machen. Mit benutzerdefinierten Azure Active Directory B2C (Azure AD B2C)-Richtlinien können Sie ein technisches Profil bedingt aktivieren oder deaktivieren, um diese Funktionalität zu erreichen. Beispielsweise haben wir in Überprüfen von Benutzereingaben mithilfe der benutzerdefinierten Azure AD B2C-Richtlinie ein Precondition verwendet, um zu bestimmen, ob wir ein technisches Validierungsprofil basierend auf dem Wert des accountType-Anspruchs ausführen sollten.

Ein technisches Profil stellt auch ein EnabledForUserJourneys-Element bereit, mit dem Sie angeben können, ob ein technisches Profil ausgeführt werden soll oder nicht. Das Element EnabledForUserJourneys enthält einen von fünf Werten, einschließlich OnClaimsExistence, die Sie verwenden, um anzugeben, dass ein technisches Profil nur ausgeführt werden soll, wenn ein bestimmter Anspruch vorhanden ist, der im technischen Profil angegeben ist. Erfahren Sie mehr über das Element EnabledForUserJourneys des technischen Profils.

Übersicht über das Szenario

Im Artikel Überprüfen von Benutzereingaben mithilfe der benutzerdefinierten Azure AD B2C-Richtlinie gibt ein Benutzer seine Details auf einem einzigen Bildschirm ein. In diesem Artikel muss ein Benutzer zuerst seinen Kontotyp, sein Contoso-Mitarbeiterkonto oder sein persönliches Konto auswählen. Ein Benutzer, der Contoso-Mitarbeiterkonto auswählt, kann weitere Details angeben. Ein Benutzer, der persönliches Konto auswählt, muss jedoch einen gültigen Einladungszugriffscode angeben, bevor er weitere Details angeben kann. Daher sehen Benutzer, die den Kontotyp Persönliches Konto verwenden, eine zusätzliche Benutzeroberfläche, um ihre User Journey abzuschließen.

A flowchart of branching in user journey.

In diesem Artikel erfahren Sie, wie Sie das Element EnabledForUserJourneys innerhalb eines technischen Profils verwenden, um unterschiedliche Benutzeroberflächen basierend auf einem Anspruchswert zu erstellen.

Voraussetzungen

Wenn Sie noch nicht über einen Azure AD B2C-Mandanten verfügen, erstellen Sie einen, der mit Ihrem Azure-Abonnement verknüpft ist.
Registrieren Sie eine Webanwendung, und aktivieren Sie die implizite Gewährung von ID-Token. Verwenden Sie https://jwt.ms für den Umleitungs-URI.
Auf Ihrem Computer muss Visual Studio Code (VS Code) installiert sein.
Schließen Sie die Schritte unter Überprüfen von Benutzereingaben mithilfe der benutzerdefinierten Azure AD B2C-Richtlinie ab. Dieser Artikel ist Teil der Schrittanleitungsreihe „Erstellen und Ausführen eigener benutzerdefinierter Richtlinien“.

Hinweis

Dieser Artikel ist Teil der Schrittanleitungsreihe „Erstellen und Ausführen Ihrer eigenen benutzerdefinierten Richtlinien in Azure Active Directory B2C“. Wir empfehlen Ihnen, diese Reihe mit dem ersten Artikel zu beginnen.

Schritt 1: Deklarieren von Ansprüchen

Ein Benutzer, der persönliches Konto auswählt, muss einen gültigen Zugriffscode angeben. Daher benötigen wir einen Anspruch, um diesen Wert zu enthalten:

Öffnen Sie in VS Code die Datei ContosoCustomPolicy.XML.

Deklarieren Sie im Abschnitt ClaimsSchema accessCode- und isValidAccessCode-Ansprüche mithilfe des folgenden Codes:

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

Schritt 2: Definieren von Anspruchstransformationen

Finden Sie das Element ClaimsTransformations und fügen Sie die folgenden Anspruchstransformation hinzu:

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

Wir haben zwei Anspruchstransformationen definiert: CheckIfIsValidAccessCode und ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode verwendet die CompareClaimToValue-Transformationsmethode, um die Zugriffscodeeingabe des Benutzers mit dem statischen Wert 88888 (verwenden wir diesen Wert zum Testen) zu vergleichen und true oder false dem Anspruch isValidAccessCode zuzuordnen. ThrowIfIsNotValidAccessCode überprüft, ob zwei boolesche Werte von zwei Ansprüchen gleich sind, und löst eine Ausnahme aus, falls dies nicht der Fall ist.

Schritt 3: Konfigurieren oder Aktualisieren technischer Profile

Sie benötigen jetzt zwei neue selbstbestätigte technische Profile: eines zum Erfassen des Kontotyps, das andere zum Erfassen des Zugriffscodes vom Benutzer. Sie benötigen außerdem ein neues technisches Profil für die Anspruchstransformation, um den Zugriffscode des Benutzers zu überprüfen, indem Sie die Anspruchstransformationen ausführen, die Sie in Schritt 2 definiert haben. Nachdem wir nun den Kontotyp in einem anderen selbstbestätigten technischen Profil erfassen, müssen wir das selbstbestätigte technische Profil UserInformationCollector aktualisieren, um zu verhindern, dass es den Kontotyp erfasst.

Suchen Sie das Element ClaimsProviders, und fügen Sie dann mithilfe des folgenden Codes einen neuen Anspruchsanbieter hinzu:

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

Wir haben zwei technische Profile konfiguriert: AccessCodeInputCollector und CheckAccessCodeViaClaimsTransformationChecker. Wir bezeichnen das technische Profil CheckAccessCodeViaClaimsTransformationChecker als technisches Validierungsprofil aus dem technischen Profil AccessCodeInputCollector. Der CheckAccessCodeViaClaimsTransformationChecker selbst ist vom Typ ein technisches Profil der Anspruchstransformation, das die Anspruchstransformationen ausführt, die wir in Schritt 2 definiert haben.

AccessCodeInputCollector ist ein selbstbestätigtes technisches Profil, das zum Erfassen eines Zugriffscodes vom Benutzer verwendet wird. Es enthält ein EnabledForUserJourneys-Element, das auf OnClaimsExistence festgelegt ist. Sein Metadata-Element enthält einen Anspruch (accountType) und seinen Wert (persönlich), der dieses technische Profil aktiviert.

Suchen Sie das Element ClaimsProviders, und fügen Sie dann mithilfe des folgenden Codes einen neuen Anspruchsanbieter hinzu:

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

Wir haben ein selbstbestätigtes technisches Profil namens AccountTypeInputCollectorkonfiguriert, das den Kontotyp des Benutzers erfasst. Es ist der Wert der Kontotypen, der bestimmt, ob das selbstbestätigte technische Profil AccessCodeInputCollector aktiviert werden soll.

Um zu verhindern, dass das selbstbestätigte technische Profil UserInformationCollector den Kontotyp erfasst, suchen Sie nach dem selbstbestätigten technischen Profil UserInformationCollector, und tun Sie dann Folgendes:
1. Entfernen Sie den accountType Anzeigeanspruch <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> aus der DisplayClaims Auflistung.
2. Entfernen Sie den accountType Ausgabeanspruch <OutputClaim ClaimTypeReferenceId="accountType"/> aus der OutputClaims Auflistung.

Schritt 4: Aktualisieren der Schritte zur Orchestrierung der User Journey

Nachdem Sie nun Ihre technischen Profile eingerichtet haben, müssen Sie die Schritte zur Orchestrierung Ihrer User Journey aktualisieren:

Suchen Sie Ihre User Journey HelloWorldJourney, und fügen Sie alle Orchestrierungsschritte durch den folgenden Code hinzu:

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

Die Orchestrierungsschritte zeigen, dass wir das technische Profil in der Reihenfolge aufrufen, wie sie durch das Attribut Order der Orchestrierungsschritte angezeigt wird. Das technische Profil AccessCodeInputCollector wird jedoch aktiviert, wenn der Benutzer den Kontotyp Persönliches Konto auswählt.

Schritt 5: Hochladen der benutzerdefinierten Richtlinie

Führen Sie die Schritte unter Hochladen einer benutzerdefinierten Richtliniendatei aus, um Ihre Richtliniendatei hochzuladen. Wenn Sie eine Datei mit demselben Namen wie die Datei hochladen, die bereits im Portal vorhanden ist, stellen Sie sicher, dass Sie Überschreiben der benutzerdefinierten Richtlinie, sofern sie bereits vorhanden ist auswählen.

Schritt 6: Testen der benutzerdefinierten Richtlinie

Führen Sie die Schritte unter Testen der benutzerdefinierten Richtlinie aus, um Ihre benutzerdefinierte Richtlinie zu testen:

Wählen Sie auf dem ersten Bildschirm unter Kontotyp die Option Persönliches Konto aus.
Geben Sie unter Zugriffscode88888 ein, und wählen Sie dann Weiter aus.
Geben Sie die restlichen Details nach Bedarf ein, und wählen Sie dann Weiter aus. Nachdem die Ausführung der Richtlinie abgeschlossen ist, werden Sie zu https://jwt.ms weitergeleitet, und es wird ein decodiertes JWT-Token angezeigt.
Wiederholen Sie Schritt 5, wählen Sie aber diesmal bei KontotypContoso-Mitarbeiterkonto aus, und folgen Sie dann den Anweisungen.

Nächste Schritte

In Schritt 3 wurde das technische Profil mithilfe des Elements EnabledForUserJourneys aktiviert oder deaktiviert. Alternativ können Sie die Voraussetzungen in den Orchestrierungsschritten der User Journey verwenden, um einen Orchestrierungsschritt auszuführen oder zu überspringen, wie weiter unten in dieser Reihe erläutert wird.

Erfahren Sie als Nächstes:

Informationen zu Voraussetzungen für die Orchestrierungsschritte von User Journeys.
Informationen zum Verwenden der TrustFrameworkPolicy-Schemadatei zum Überprüfen von Azure AD B2C-Richtliniendateien.

Teilen über