Tworzenie rozgałęziania w podróży użytkownika przy użyciu niestandardowych zasad usługi Azure Active Directory B2C
Różni użytkownicy tej samej aplikacji mogą śledzić różne podróże użytkowników w zależności od wartości danych w zasadach niestandardowych. 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 artykule Validate user inputs by using Azure AD B2C custom policy (Weryfikowanie danych wejściowych użytkownika przy użyciu zasad niestandardowych usługi Azure AD B2C) użyliśmy elementu , Precondition aby określić, czy należy uruchomić profil techniczny weryfikacji na podstawie wartości oświadczenia accountType .
Profil techniczny udostępnia EnabledForUserJourneys również element umożliwiający określenie, czy profil techniczny powinien być uruchamiany. 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 profilu technicznego.
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ć EnabledForUserJourneys elementu w profilu technicznym do tworzenia różnych środowisk użytkownika na podstawie wartości oświadczenia.
Wymagania wstępne
Jeśli jeszcze go nie masz, utwórz dzierżawę usługi Azure AD B2C połączoną z subskrypcją platformy Azure.
Zarejestruj aplikację internetową i włącz niejawne przyznanie tokenu identyfikatora. W przypadku identyfikatora URI przekierowania użyj polecenia https://jwt.ms.
Na komputerze musi być zainstalowany program Visual Studio Code (VS Code ).
Wykonaj kroki opisane w artykule Weryfikowanie danych wejściowych użytkownika przy użyciu niestandardowych zasad usługi Azure AD B2C. Ten artykuł jest częścią serii Instrukcje tworzenia i uruchamiania własnych zasad niestandardowych.
Uwaga
Ten artykuł jest częścią serii Instrukcje tworzenia i uruchamiania własnych zasad niestandardowych 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 zadeklaruj
ClaimsSchemakod accessCode i oświadczenia 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ń
ClaimsTransformations Znajdź element i dodaj następujące przekształcenia 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 dwa przekształcenia oświadczeń: CheckIfIsValidAccessCode i ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode używa metody przekształcania CompareClaimToValue , aby porównać dane wejściowe kodu dostępu przez użytkownika z wartością statyczną 88888 (użyjemy tej wartości do testowania) i przypisuje true lub false do oświadczenia isValidAccessCode . ThrowIfIsNotValidAccessCode sprawdza, czy dwie wartości logiczne dwóch oświadczeń są równe 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 profilu technicznego typu przekształcenia oświadczeń, aby zweryfikować kod dostępu użytkownika, wykonując przekształcenia oświadczeń zdefiniowane w kroku 2. Teraz, gdy zbieramy typ konta w innym własnym profilu technicznym, musimy zaktualizować UserInformationCollector własny 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 . Sam element CheckAccessCodeViaClaimsTransformationChecker jest typem Profil techniczny przekształcania oświadczeń, który wykonuje przekształcenia oświadczeń zdefiniowane w kroku 2.
AccessCodeInputCollector to samodzielny profil techniczny używany do zbierania kodu dostępu od użytkownika. Zawiera
EnabledForUserJourneyselement, który jest ustawiony na OnClaimsExistence. JegoMetadataelement zawiera oświadczenie (accountType) i jego wartość (osobistą), 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,
AccountTypeInputCollectorktó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
UserInformationCollectortypu konta przez siebie asertywnego profilu technicznego, znajdźUserInformationCollectorwłasny profil techniczny, a następnie:Usuń oświadczenie wyświetlania
accountTypez kolekcjiDisplayClaims.<DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>accountTypeUsuń oświadczenie wyjściowe ,<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:
HelloWorldJourneyZnajdź podróż użytkownika i dodaj zastąp wszystkie kroki orkiestracji następującym kodem:<!--<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 aranżacji pokazują, że nazywamy profil techniczny w kolejności wyświetlanej przez atrybut kroków
Orderaranżacji. Jednak profil techniczny jest aktywowany,AccessCodeInputCollectorjeśli użytkownik wybierze typ konta osobistego.
Krok 5. Przekazywanie pliku zasad niestandardowych
Wykonaj kroki opisane w temacie Przekazywanie pliku zasad niestandardowych, aby przekazać plik zasad. Jeśli przekazujesz plik o tej samej nazwie co plik już w portalu, upewnij się, że wybierzesz pozycję Zastąp zasady niestandardowe, jeśli już istnieje.
Krok 6. Testowanie zasad niestandardowych
Wykonaj kroki opisane w artykule Testowanie zasad niestandardowych, aby przetestować zasady niestandardowe:
- Na pierwszym ekranie w polu Typ konta wybierz pozycję Konto osobiste.
- W polu Kod dostępu wprowadź wartość 88888, a następnie wybierz pozycję Kontynuuj.
- Wprowadź pozostałe szczegóły zgodnie z potrzebami, a następnie wybierz pozycję Kontynuuj. Po zakończeniu wykonywania zasad nastąpi przekierowanie do
https://jwt.mselementu i zostanie wyświetlony zdekodowany token 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.
Następne kroki
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 aranżacji podróży użytkownika, aby wykonać lub pominąć krok aranżacji, jak nauczymy się w dalszej części tej serii.
Następnie dowiedz się:
Informacje o krokach aranżacji podróży użytkownika.
Jak użyć pliku schematu TrustFrameworkPolicy w celu zweryfikowania plików zasad usługi Azure AD B2C.