Utwórz rozgałęzienia w ścieżce użytkownika przy użyciu polityki niestandardowej usługi Azure Active Directory B2C
Różni użytkownicy tej samej aplikacji mogą śledzić różne ścieżki użytkowników w zależności od wartości danych w polityce niestandardowej. Niestandardowe zasady usługi Azure Active Directory B2C (Azure AD B2C) umożliwiają warunkowe włączanie lub wyłączanie profilu technicznego w celu osiągnięcia tej możliwości. Na przykład w Validate user inputs by using Azure AD B2C custom policy użyliśmy elementu Precondition aby określić, czy należy uruchomić profil techniczny weryfikacji na podstawie wartości atrybutu accountType.
Profil techniczny zawiera również element EnabledForUserJourneys, który pozwala określić, czy profil techniczny ma być uruchomiony. Element EnabledForUserJourneys zawiera jedną z pięciu wartości, w tym OnClaimsExistence, która służy do określenia, że profil techniczny powinien być uruchamiany tylko wtedy, gdy istnieje określone oświadczenie określone w profilu technicznym. Dowiedz się więcej na temat elementu EnabledForUserJourneys w profilu technicznym.
Omówienie scenariusza
W artykule Zweryfikuj dane wejściowe użytkownika przy użyciu zasad niestandardowych usługi Azure AD B2C użytkownik wprowadza szczegóły na jednym ekranie. W tym artykule użytkownik musi najpierw wybrać typ konta, konto pracownika firmy Contoso lub konto osobiste. Użytkownik, który wybierze konto pracownika firmy Contoso , może przejść do dalszych szczegółów. Jednak użytkownik, który wybiera konto osobiste , musi podać prawidłowy kod dostępu z zaproszeniem, zanim będzie mógł podać dalsze szczegóły. W związku z tym użytkownicy korzystający z typu konta osobistego widzą dodatkowy interfejs użytkownika, aby ukończyć swoją podróż.
Z tego artykułu dowiesz się, jak używać elementu EnabledForUserJourneys w profilu technicznym do tworzenia różnych doświadczeń użytkownika, opierając się na wartości świadczenia.
Wymagania wstępne
Jeśli jeszcze go nie masz, utwórz dzierżawę Azure AD B2C powiązaną z Twoją subskrypcją Azure.
Rejestrowanie aplikacji internetowej.
Na komputerze musi być zainstalowany Visual Studio Code (VS Code).
Wykonaj kroki opisane w Weryfikowanie danych wejściowych użytkownika przy użyciu zasad niestandardowych usługi Azure AD B2C. Niniejszy artykuł jest częścią serii Tworzenie i uruchamianie własnych niestandardowych zasad w ramach przewodnika.
Uwaga
Ten artykuł jest częścią serii przewodników Jak tworzyć i uruchamiać własne polityki niestandardowe w usłudze Azure Active Directory B2C . Zalecamy rozpoczęcie tej serii od pierwszego artykułu.
Krok 1. Deklarowanie oświadczeń
Użytkownik, który wybiera konto osobiste , musi podać prawidłowy kod dostępu. Dlatego potrzebujemy oświadczenia do przechowywania tej wartości:
W programie VS Code otwórz
ContosoCustomPolicy.XMLplik.W sekcji
ClaimsSchemazadeklaruj accessCode i roszczenia isValidAccessCode przy użyciu następującego kodu:<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>
Krok 2. Definiowanie przekształceń oświadczeń
Znajdź element ClaimsTransformations i dodaj następujące transformacje oświadczeń:
<!---<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>-->
Zdefiniowaliśmy dwie transformacje roszczeń: CheckIfIsValidAccessCode i ThrowIfIsNotValidAccessCode.
CheckIfIsValidAccessCode używa metody przekształcania CompareClaimToValue do porównania kodu dostępu wprowadzonego przez użytkownika z wartością statyczną 88888 (użyjemy tej wartości do testowania) i przypisuje true lub false do parametru isValidAccessCode.
ThrowIfIsNotValidAccessCode sprawdza, czy dwie wartości logiczne dwóch twierdzeń są identyczne, i zgłasza wyjątek, jeśli nie są.
Krok 3. Konfigurowanie lub aktualizowanie profilów technicznych
Teraz potrzebne są dwa nowe własne profile techniczne, jeden do zbierania typu konta, a drugi do zbierania kodu dostępu od użytkownika. Potrzebujesz również nowego technicznego profilu typu transformacja roszczeń, aby zweryfikować kod dostępu użytkownika, wykonując transformacje roszczeń zdefiniowane w kroku 2. Teraz, gdy zbieramy typ konta w innym samoasetowanym profilu technicznym, musimy zaktualizować UserInformationCollector samoasetowany profil techniczny, aby zapobiec zbieraniu typu konta.
ClaimsProvidersZnajdź element, a następnie dodaj nowego dostawcę oświadczeń przy użyciu następującego kodu:<!--<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>-->Skonfigurowaliśmy dwa profile techniczne, AccessCodeInputCollector i CheckAccessCodeViaClaimsTransformationChecker. Nazywamy profil techniczny CheckAccessCodeViaClaimsTransformationChecker jako profil techniczny weryfikacji z poziomu profilu technicznego AccessCodeInputCollector . Element CheckAccessCodeViaClaimsTransformationChecker sam w sobie jest technicznym profilem przekształcania roszczeń, który wykonuje przekształcenia roszczeń zdefiniowane w kroku 2.
AccessCodeInputCollector to profil techniczny Self-Asserted używany do zbierania kodu dostępu od użytkownika. Zawiera
EnabledForUserJourneyselement, który jest ustawiony na OnClaimsExistence. JegoMetadataelement zawiera oświadczenie (accountType) oraz wartość (personalna), która aktywuje ten profil techniczny.ClaimsProvidersZnajdź element, a następnie dodaj nowego dostawcę oświadczeń przy użyciu następującego kodu:<!--<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>-->Skonfigurowaliśmy własny profil techniczny,
AccountTypeInputCollector, który zbiera typ konta użytkownika. Jest to wartość typów kont, która określa, czyAccessCodeInputCollectornależy aktywować własny profil techniczny.Aby zapobiec zbieraniu typu konta przez profil techniczny samoasertywny, zlokalizuj profil techniczny samoasertywny, a następnie:
Usuń oświadczenie wyświetlania
accountType,<DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>z kolekcjiDisplayClaims.Usuń oświadczenie wyjściowe
accountType,<OutputClaim ClaimTypeReferenceId="accountType"/>, z kolekcjiOutputClaims.
Krok 4. Aktualizowanie kroków orkiestracji podróży użytkownika
Po skonfigurowaniu profilów technicznych należy zaktualizować kroki orkiestracji podróży użytkownika:
Zlokalizuj swoją ścieżkę użytkownika i zamień wszystkie kroki orkiestracji na następujący 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>-->Kroki orkiestracji pokazują, że wywołujemy profil techniczny w kolejności określonej przez atrybut kroków
Orderorkiestracji. JednakAccessCodeInputCollectorprofil techniczny jest aktywowany, jeśli użytkownik wybierze typ konta osobistego.
Krok 5 - Prześlij plik niestandardowej polityki
Wykonaj kroki zawarte w Przekaż plik polityki niestandardowej, aby przesłać swój plik polityki. Jeśli przesyłasz plik o tej samej nazwie co plik już znajdujący się w portalu, upewnij się, że wybrano opcję Zastąp zasady niestandardowe, jeśli już one istnieją.
Krok 6 - Przetestuj zasady niestandardowe
Wykonaj kroki w Testowanie zasad niestandardowych, aby przetestować swoją niestandardową zasadę:
- Na pierwszym ekranie w polu Typ konta wybierz pozycję Konto osobiste.
- Dla kodu dostępu wprowadź 88888, a następnie wybierz Kontynuuj.
- Wprowadź pozostałe szczegóły, a następnie wybierz opcję Kontynuuj. Po zakończeniu wykonywania polityki nastąpi przekierowanie do
https://jwt.ms, i zostanie wyświetlony zdekodowany JWT. - Powtórz krok 5, ale tym razem wybierz pozycję Typ konta, wybierz pozycję Konto pracownika firmy Contoso, a następnie postępuj zgodnie z monitami.
Powiązana zawartość
W kroku 3 włączamy lub wyłączamy profil techniczny przy użyciu EnabledForUserJourneys elementu . Alternatywnie możesz użyć warunków wstępnych wewnątrz kroków koordynacji podróży użytkownika, aby wykonać lub pominąć krok koordynacji, jak dowiemy się później w tej serii.
Następnie dowiedz się: