UserJourneys

Artykuł
01/17/2024

Uwaga

W usłudze Azure Active Directory B2C zasady niestandardowe są przeznaczone głównie do rozwiązywania złożonych scenariuszy. W przypadku większości scenariuszy zalecamy używanie wbudowanych przepływów użytkownika. Jeśli nie zostało to zrobione, dowiedz się więcej o niestandardowym pakiecie startowym zasad w temacie Wprowadzenie do zasad niestandardowych w usłudze Active Directory B2C.

Podróże użytkownika określają jawne ścieżki, za pośrednictwem których zasady umożliwiają aplikacji jednostki zależnej uzyskanie żądanych oświadczeń dla użytkownika. Użytkownik jest prowadzony przez te ścieżki w celu pobrania oświadczeń, które mają być prezentowane jednostce zależnej. Innymi słowy, podróże użytkowników definiują logikę biznesową tego, co użytkownik końcowy przechodzi, gdy platforma Azure AD B2C Identity Experience Framework przetwarza żądanie.

Te podróże użytkowników można uznać za szablony dostępne, aby zaspokoić podstawową potrzebę różnych jednostek uzależnionych w interesie społeczności. Podróże użytkowników ułatwiają definiowanie części jednostki uzależnionej zasad. Zasady mogą definiować wiele podróży użytkowników. Każda podróż użytkownika to sekwencja kroków aranżacji.

Aby zdefiniować podróże użytkowników obsługiwane przez zasady, UserJourneys element jest dodawany w ramach elementu najwyższego poziomu TrustFrameworkPolicy pliku zasad.

<TrustFrameworkPolicy  ...>
  ...
  <UserJourneys>
    ...
  </UserJourneys>
</TrustFrameworkPolicy>

Element UserJourneys zawiera następujący element:

Element	Wystąpień	opis
UserJourney	1:n	Podróż użytkownika, która definiuje wszystkie konstrukcje niezbędne do pełnego przepływu użytkownika.

Element UserJourney zawiera następujący atrybut:

Atrybut	Wymagania	Opis
Id	Tak	Identyfikator podróży użytkownika, który może służyć do odwołowania się do niego z innych elementów w zasadach. Element DefaultUserJourney zasad jednostki uzależnionej wskazuje ten atrybut.
DefaultCpimIssuerTechnicalProfileReferenceId	Nie.	Identyfikator referencyjny domyślnego profilu technicznego wystawcy tokenu. Na przykład wystawca tokenu JWT, wystawca tokenu SAML lub niestandardowy błąd OAuth2. Jeśli podróż użytkownika lub podróż podrzędna ma już inny `SendClaims` krok aranżacji, ustaw `DefaultCpimIssuerTechnicalProfileReferenceId` atrybut na profil techniczny wystawcy tokenu podróży użytkownika.

Element UserJourney zawiera następujące elementy:

Element	Wystąpień	opis
AuthorizationTechnicalProfiles	0:1	Lista profilów technicznych autoryzacji.
OrchestrationSteps	1:n	Sekwencja aranżacji, którą należy wykonać w celu pomyślnej transakcji. Każda podróż użytkownika składa się z uporządkowanej listy kroków aranżacji, które są wykonywane w sekwencji. Jeśli jakikolwiek krok zakończy się niepowodzeniem, transakcja zakończy się niepowodzeniem.

AuthorizationTechnicalProfiles

Załóżmy, że użytkownik ukończył użytkownika UserJourney i uzyskał dostęp lub token identyfikatora. Aby zarządzać dodatkowymi zasobami, takim jak punkt końcowy UserInfo, należy zidentyfikować użytkownika. Aby rozpocząć ten proces, użytkownik musi przedstawić token dostępu wystawiony wcześniej jako dowód, że zostały one pierwotnie uwierzytelnione przez prawidłowe zasady usługi Azure AD B2C. Prawidłowy token dla użytkownika musi być zawsze obecny podczas tego procesu, aby upewnić się, że użytkownik może wysłać to żądanie. Profile techniczne autoryzacji weryfikują token przychodzący i wyodrębniają oświadczenia z tokenu.

Element AuthorizationTechnicalProfiles zawiera następujący element:

Element	Wystąpień	opis
AuthorizationTechnicalProfile	0:1	Dokumentacja profilu technicznego używana do autoryzowania użytkownika.

Element AuthorizationTechnicalProfile zawiera następujący atrybut:

Atrybut	Wymagania	opis
Identyfikator odwołania	Tak	Identyfikator profilu technicznego, który ma zostać wykonany.

W poniższym przykładzie przedstawiono element podróży użytkownika z profilami technicznymi autoryzacji:

<UserJourney Id="UserInfoJourney" DefaultCpimIssuerTechnicalProfileReferenceId="UserInfoIssuer">
  <Authorization>
    <AuthorizationTechnicalProfiles>
      <AuthorizationTechnicalProfile ReferenceId="UserInfoAuthorization" />
    </AuthorizationTechnicalProfiles>
  </Authorization>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
     ...

OrchestrationSteps

Podróż użytkownika jest reprezentowana jako sekwencja aranżacji, którą należy wykonać w celu pomyślnej transakcji. Jeśli jakikolwiek krok zakończy się niepowodzeniem, transakcja zakończy się niepowodzeniem. Te kroki aranżacji odwołują się zarówno do bloków konstrukcyjnych, jak i dostawców oświadczeń dozwolonych w pliku zasad. Każdy krok aranżacji, który jest odpowiedzialny za wyświetlanie lub renderowanie środowiska użytkownika, ma również odwołanie do odpowiedniego identyfikatora definicji zawartości.

Kroki orkiestracji można wykonać warunkowo na podstawie warunków wstępnych zdefiniowanych w elemecie kroku aranżacji. Na przykład możesz sprawdzić, czy wykonać krok aranżacji tylko wtedy, gdy istnieje określone oświadczenie, lub jeśli oświadczenie jest równe lub nie do określonej wartości.

Aby określić uporządkowaną listę kroków aranżacji, element OrchestrationSteps jest dodawany jako część zasad. Ten element jest wymagany.

<UserJourney Id="SignUpOrSignIn">
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      ...

Element OrchestrationSteps zawiera następujący element:

Element	Wystąpień	opis
OrchestrationStep	1:n	Uporządkowany krok aranżacji.

Element OrchestrationStep zawiera następujące atrybuty:

Atrybut	Wymagania	opis
`Order`	Tak	Kolejność kroków aranżacji. Wartość atrybutu `Order` zaczyna się od `1` `N`. Jeśli więc masz 10 kroków i usuniesz drugi krok, musisz ponownie ponumerować kroki od trzech do 10, aby stać się od dwóch do dziewięciu.
`Type`	Tak	Typ kroku aranżacji. Możliwe wartości: ClaimsProviderSelection — wskazuje, że krok aranżacji przedstawia różnych dostawców oświadczeń użytkownikowi do wybrania. CombinedSignInAndSignUp — wskazuje, że krok aranżacji przedstawia połączoną stronę logowania dostawcy społecznościowego i konto lokalne. ClaimsExchange — wskazuje, że krok aranżacji wymienia oświadczenia z dostawcą oświadczeń. GetClaims — określa, że krok aranżacji powinien przetwarzać dane oświadczeń wysyłane do usługi Azure AD B2C z jednostki uzależnionej za pośrednictwem konfiguracji `InputClaims` . InvokeSubJourney — wskazuje, że krok aranżacji wymienia oświadczenia z podjeżdżającą podróżą. SendClaims — wskazuje, że krok aranżacji wysyła oświadczenia do jednostki uzależnionej z tokenem wystawionym przez wystawcę oświadczeń.
ContentDefinitionReferenceId	Nie.	Identyfikator definicji zawartości skojarzonej z tym krokiem aranżacji. Zazwyczaj identyfikator odwołania do definicji zawartości jest definiowany w profilu technicznym samozwańczości. Jednak w niektórych przypadkach usługa Azure AD B2C musi wyświetlać coś bez profilu technicznego. Istnieją dwa przykłady — jeśli typ kroku aranżacji jest jednym z następujących: `ClaimsProviderSelection` lub `CombinedSignInAndSignUp`usługa Azure AD B2C musi wyświetlić wybór dostawcy tożsamości bez posiadania profilu technicznego.
CpimIssuerTechnicalProfileReferenceId	Nie.	Typ kroku aranżacji to `SendClaims`. Ta właściwość definiuje identyfikator profilu technicznego dostawcy oświadczeń, który wystawia token dla jednostki uzależnionej. Jeśli jest nieobecny, nie jest tworzony token jednostki uzależnionej.

Element OrchestrationStep może zawierać następujące elementy:

Element	Wystąpień	opis
Warunki wstępne	0:n	Lista warunków wstępnych, które muszą być spełnione, aby wykonać krok aranżacji.
ClaimsProviderS wybory	0:n	Lista opcji dostawcy oświadczeń dla kroku aranżacji.
ClaimsExchanges	0:n	Lista oświadczeń wymiany dla kroku aranżacji.
Lista podróży	0:1	Lista kandydatów do podróży podrzędnych dla kroku aranżacji.

Warunki wstępne

Kroki orkiestracji można wykonać warunkowo na podstawie warunków wstępnych zdefiniowanych w kroku aranżacji. Element Preconditions zawiera listę warunków wstępnych do oceny. Gdy ocena warunków wstępnych zostanie spełniona, skojarzony krok aranżacji zostanie pominięty w następnym kroku aranżacji.

Usługa Azure AD B2C ocenia warunki wstępne w kolejności listy. Warunki wstępne oparte na kolejności umożliwiają ustawienie kolejności, w jakiej są stosowane warunki wstępne. Pierwszy warunek wstępny, który spełnia wszystkie kolejne warunki wstępne. Krok aranżacji jest wykonywany tylko wtedy, gdy wszystkie warunki wstępne nie są spełnione.

Element Warunek wstępny zawiera następujący element:

Element	Wystąpień	opis
Warunek wstępny	1:n	Warunek wstępny do oceny.

Warunek wstępny

Element Warunek wstępny zawiera następujące atrybuty:

Atrybut	Wymagania	opis
`Type`	Tak	Typ sprawdzania lub zapytania do wykonania dla tego warunku wstępnego. Wartość może być ClaimsExist, która określa, że akcje powinny być wykonywane, jeśli określone oświadczenia istnieją w bieżącym zestawie oświadczeń użytkownika lub ClaimEquals, który określa, że akcje należy wykonać, jeśli określone oświadczenie istnieje, a jego wartość jest równa określonej wartości.
`ExecuteActionsIf`	Tak	Decyduje, w jaki sposób warunek wstępny jest uznawany za spełniony. Możliwe wartości: `true`, lub `false`. Jeśli wartość jest ustawiona na `true`, jest uważana za spełnioną, gdy oświadczenie pasuje do warunku wstępnego. Jeśli wartość jest ustawiona na `false`, jest uważana za spełnioną, gdy oświadczenie nie jest zgodne z warunkiem wstępnym.

Elementy warunków wstępnych zawierają następujące elementy:

Element	Wystąpień	Opis
Wartość	1:2	Identyfikator typu oświadczenia. Oświadczenie jest już zdefiniowane w sekcji schematu oświadczeń w pliku zasad lub pliku zasad nadrzędnych. Gdy warunek wstępny jest typem `ClaimEquals`, drugi `Value` element zawiera wartość do sprawdzenia.
Akcja	1:1	Działanie, które należy wykonać, jeśli ocena warunków wstępnych jest spełniona. Możliwa wartość: `SkipThisOrchestrationStep`. Skojarzony krok aranżacji zostanie pominięty w następnym kroku.

Każdy warunek wstępny ocenia pojedyncze oświadczenie. Istnieją dwa typy warunków wstępnych:

ClaimsExist — określa, że akcje powinny być wykonywane, jeśli określone oświadczenia istnieją w bieżącej torbie oświadczenia użytkownika.
ClaimEquals — określa, że akcje powinny być wykonywane, jeśli określone oświadczenie istnieje, a jego wartość jest równa określonej wartości. Sprawdzanie wykonuje porównanie porządkowe z uwzględnieniem wielkości liter. Podczas sprawdzania typu oświadczenia logicznego użyj wartości True, lub False.

Jeśli oświadczenie ma wartość null lub jest niezainicjowane, warunek wstępny jest ignorowany, niezależnie od tego, czy jest trueto ExecuteActionsIf , czy false. Najlepszym rozwiązaniem jest sprawdzenie, czy oświadczenie istnieje, i równa się wartości.

Przykładowym scenariuszem może być wyzwanie dla użytkownika usługi MFA, jeśli użytkownik ustawił MfaPreference wartość Phone. Aby wykonać tę logikę warunkową, sprawdź, czy MfaPreference oświadczenie istnieje, a także sprawdź wartość oświadczenia równą Phone. Poniższy kod XML pokazuje, jak zaimplementować tę logikę z warunkami wstępnymi.

<Preconditions>
  <!-- Skip this orchestration step if MfaPreference doesn't exist. -->
  <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
    <Value>MfaPreference</Value>
    <Action>SkipThisOrchestrationStep</Action>
  </Precondition>
  <!-- Skip this orchestration step if MfaPreference doesn't equal to Phone. -->
  <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
    <Value>MfaPreference</Value>
    <Value>Phone</Value>
    <Action>SkipThisOrchestrationStep</Action>
  </Precondition>
</Preconditions>

Przykłady warunków wstępnych

Następujące warunki wstępne sprawdzają, czy istnieje identyfikator objectId użytkownika. W podróży użytkownika użytkownik wybrał opcję logowania przy użyciu konta lokalnego. Jeśli identyfikator objectId istnieje, pomiń ten krok aranżacji.

<OrchestrationStep Order="2" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

Następujące warunki wstępne sprawdzają, czy użytkownik zalogował się przy użyciu konta społecznościowego. Podjęto próbę znalezienia konta użytkownika w katalogu. Jeśli użytkownik zaloguje się lub zarejestruje się przy użyciu konta lokalnego, pomiń ten krok aranżacji.

<OrchestrationStep Order="3" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
  </ClaimsExchanges>
</OrchestrationStep>

Warunki wstępne mogą sprawdzać wiele warunków wstępnych. Poniższy przykład sprawdza, czy istnieje element "objectId", czy "email". Jeśli pierwszy warunek ma wartość true, podróż zostanie pominięta w następnym kroku aranżacji.

<OrchestrationStep Order="4" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>email</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="SelfAsserted-SocialEmail" TechnicalProfileReferenceId="SelfAsserted-SocialEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

Wybór dostawcy oświadczeń

Wybór dostawcy oświadczeń umożliwia użytkownikom wybranie akcji z listy opcji. Wybór dostawcy tożsamości składa się z pary dwóch kroków aranżacji:

Przyciski — zaczyna się od typu ClaimsProviderSelection, lub CombinedSignInAndSignUp zawiera listę opcji, z których użytkownik może wybrać. Kolejność opcji wewnątrz ClaimsProviderSelections elementu kontroluje kolejność przycisków przedstawionych użytkownikowi.
Akcje — po nim typ ClaimsExchange. Obiekt ClaimsExchange zawiera listę akcji. Akcja jest odwołaniem do profilu technicznego, takiego jak OAuth2, OpenID Connect, transformacja oświadczeń lub samozwańczość. Gdy użytkownik kliknie jeden z przycisków, zostanie wykonana odpowiednia akcja.

Element ClaimsProviderSelections zawiera następujący element:

Element	Wystąpień	opis
ClaimsProviderSelection	1:n	Zawiera listę dostawców oświadczeń, które można wybrać.

Element ClaimsProviderSelections zawiera następujące atrybuty:

Atrybut	Wymagania	opis
DisplayOption	Nie.	Steruje zachowaniem przypadku, w którym dostępny jest wybór pojedynczego dostawcy oświadczeń. Możliwe wartości: `DoNotShowSingleProvider` (wartość domyślna) — użytkownik jest natychmiast przekierowywany do dostawcy tożsamości federacyjnej. Lub `ShowSingleProvider` usługa Azure AD B2C przedstawia stronę logowania z wyborem pojedynczego dostawcy tożsamości. Aby użyć tego atrybutu , wersja definicji zawartości musi być `urn:com:microsoft:aad:b2c:elements:contract:providerselection:1.0.0` i wyższa.

Element ClaimsProviderSelection zawiera następujące atrybuty:

Atrybut	Wymagania	opis
TargetClaimsExchangeId	Nie.	Identyfikator wymiany oświadczeń, który jest wykonywany w następnym kroku aranżacji wyboru dostawcy oświadczeń. Ten atrybut lub atrybut ValidationClaimsExchangeId musi być określony, ale nie oba.
ValidationClaimsExchangeId	Nie.	Identyfikator wymiany oświadczeń, który jest wykonywany w bieżącym kroku aranżacji w celu zweryfikowania wyboru dostawcy oświadczeń. Ten atrybut lub atrybut TargetClaimsExchangeId musi być określony, ale nie oba.

Przykład wyboru dostawcy oświadczeń

W poniższym kroku aranżacji użytkownik może zdecydować się na zalogowanie się za pomocą serwisu Facebook, LinkedIn, X, Google lub konta lokalnego. Jeśli użytkownik wybierze jednego z dostawców tożsamości społecznościowych, drugi krok aranżacji zostanie wykonany z wybraną wymianą oświadczeń określoną w atrybucie TargetClaimsExchangeId . Drugi krok aranżacji przekierowuje użytkownika do dostawcy tożsamości społecznościowych, aby ukończyć proces logowania. Jeśli użytkownik zdecyduje się zalogować przy użyciu konta lokalnego, usługa Azure AD B2C pozostaje w tym samym kroku aranżacji (na tej samej stronie rejestracji lub stronie logowania) i pomija drugi krok aranżacji.

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="LinkedInExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="TwitterExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
    <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
  </ClaimsProviderSelections>
  <ClaimsExchanges>
  <ClaimsExchange Id="LocalAccountSigninEmailExchange"
        TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
  </ClaimsExchanges>
</OrchestrationStep>


<OrchestrationStep Order="2" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
    <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
    <ClaimsExchange Id="LinkedInExchange" TechnicalProfileReferenceId="LinkedIn-OAUTH" />
    <ClaimsExchange Id="TwitterExchange" TechnicalProfileReferenceId="Twitter-OAUTH1" />
  </ClaimsExchanges>
</OrchestrationStep>

ClaimsExchanges

Element ClaimsExchanges zawiera następujący element:

Element	Wystąpień	opis
ClaimsExchange	1:n	W zależności od używanego profilu technicznego klient przekierowuje klienta zgodnie z wybraną pozycją ClaimsProviderSelection lub wywołuje serwer w celu wymiany oświadczeń.

Element ClaimsExchange zawiera następujące atrybuty:

Atrybut	Wymagania	Opis
Id	Tak	Identyfikator kroku wymiany oświadczeń. Identyfikator służy do odwołowania się do wymiany oświadczeń z kroku wyboru dostawcy oświadczeń w zasadach.
TechnicalProfileReferenceId	Tak	Identyfikator profilu technicznego, który ma zostać wykonany.

Lista podróży

Element JourneyList zawiera następujący element:

Element	Wystąpień	opis
Kandydat	1:1	Odwołanie do podróży podrzędnej, która ma zostać wywołana.

Kandydat

Element Candidate zawiera następujące atrybuty:

Atrybut	Wymagania	opis
SubJourneyReferenceId	Tak	Identyfikator podrzędnej podróży , która ma zostać wykonana.

Udostępnij za pośrednictwem