UserJourneys

Les parcours utilisateur spécifient des chemins explicites par le biais desquels une stratégie autorise une application par partie de confiance à obtenir les revendications souhaitées pour un utilisateur. L’utilisateur est guidé par ces chemins pour récupérer les revendications qui doivent être présentés à la partie de confiance. Autrement dit, les parcours utilisateur définissent la logique métier de ce par quoi passe un utilisateur final pendant que l’Infrastructure d’expérience d’identité Azure AD B2C traite la requête.

Ces parcours utilisateur peuvent être considérés comme des modèles disponibles pour répondre aux besoins fondamentaux des différentes parties de confiance de la communauté d’intérêt. Les parcours utilisateur facilitent la définition de la portion « partie de confiance » d’une stratégie. Une stratégie peut définir plusieurs parcours utilisateur. Chaque parcours utilisateur est une séquence d’étapes d’orchestration.

Pour définir les parcours utilisateur pris en charge par la stratégie, un élément UserJourneys est ajouté sous l’élément TrustFrameworkPolicy de niveau supérieur du fichier de stratégie.

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

L’élément UserJourneys contient l’élément suivant :

L’élément UserJourney contient l’attribut suivant :

L’élément UserJourney contient les éléments suivants :

AuthorizationTechnicalProfiles

Supposons qu’un utilisateur ait terminé un UserJourney et qu’il ait obtenu un jeton d’accès ou d’ID. Pour gérer des ressources supplémentaires, telles que le point de terminaison UserInfo, l’utilisateur doit être identifié. Pour commencer ce processus, l’utilisateur doit présenter le jeton d’accès émis précédemment comme preuve qu’il a été initialement authentifié par une stratégie Azure AD B2C valide. Un jeton valide pour l’utilisateur doit toujours être présent pendant ce processus pour garantir que l’utilisateur est autorisé à effectuer cette demande. Les profils techniques d’autorisation valident le jeton entrant et extraient les revendications du jeton.

L’élément AuthorizationTechnicalProfiles contient l’élément suivant :

L’élément AuthorizationTechnicalProfile contient l’attribut suivant :

L’exemple suivant illustre un élément de parcours utilisateur avec des profils techniques d’autorisation :

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

OrchestrationSteps

Un parcours utilisateur est représenté en tant que séquence d’orchestration qui doit être suivie pour que la transaction réussisse. Si une étape échoue, la transaction échoue. Ces étapes d’orchestration référencent à la fois les composants et les fournisseurs de revendications autorisés dans le fichier de stratégie. Toute étape d’orchestration responsable de l’affichage d’une expérience utilisateur a également une référence à l’identificateur de définition de contenu correspondant.

Les étapes d’orchestration peuvent être exécutées de manière conditionnelle, en fonction de conditions préalables définies dans l’élément d’étape d’orchestration. Par exemple, vous pouvez effectuer une étape d’orchestration uniquement si une revendication spécifique existe, ou si une revendication est égale ou non à la valeur spécifiée.

Pour spécifier la liste ordonnée d’étapes d’orchestration, un élément OrchestrationSteps est ajouté à la stratégie. Cet élément est obligatoire.

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

L’élément OrchestrationSteps contient l’élément suivant :

L’élément OrchestrationSteps contient les attributs suivants :

L’élément OrchestrationStep peut contenir les éléments suivants :

Preconditions

Des étapes d’orchestration peuvent être exécutées de manière conditionnelle, en fonction de conditions préalables définies dans l’étape d’orchestration. L’élément Preconditions contient une liste de conditions préalables à évaluer. Si l’évaluation est satisfaisante, l’étape d’orchestration associée passe à l’étape d’orchestration suivante.

Azure AD B2C évalue les conditions préalables dans l’ordre de la liste. Les conditions préalables basées sur l’ordre vous permettent de définir l’ordre dans lequel les conditions préalables doivent être appliquées. La première condition préalable qui est remplie remplace toutes les conditions préalables suivantes. L’étape d’orchestration est exécutée uniquement si toutes les conditions préalables ne sont pas remplies.

L’élément Preconditions contient l’élément suivant :

Precondition

L’élément Precondition contient les attributs suivants :

L’élément Precondition contient les éléments suivants :

Chaque condition préalable évalue une seule revendication. Il existe deux types de conditions préalables :

• Les revendications existent : les actions doivent être exécutées si les revendications indiquées existent dans le jeu de revendications actuel de l’utilisateur.

• Les revendications sont égales : les actions doivent être exécutées si la revendication indiquée existe et que sa valeur est égale à la valeur spécifiée. La vérification effectue une comparaison ordinale respectant la casse. Lors de la vérification du type de revendication booléenne, utilisez True ou False.

  Si la revendication est null ou non initialisée, la condition préalable est ignorée, que ExecuteActionsIf est true , ou false . Il est recommandé de vérifier que la revendication existe et qu’elle est égale à une valeur.

Un exemple de scénario serait de défier l’utilisateur pour l’authentification MFA si l’utilisateur a MfaPreference défini sur Phone. Pour exécuter cette logique conditionnelle, vérifiez si la MfaPreference revendication existe, et vérifiez également que la valeur de la revendication est égale à Phone. Le code XML suivant montre comment implémenter cette logique avec des conditions préalables.  

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

Exemples de conditions préalables

Les conditions préalables suivantes vérifient l’existence de l’objectId de l’utilisateur. Dans le parcours utilisateur, l’utilisateur a choisi de se connecter à l’aide d’un compte local. Si l’objectId existe, ignorez cette étape d’orchestration.

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

Les conditions préalables suivantes vérifient si l’utilisateur s’est connecté avec un compte social. Une tentative est effectuée pour trouver le compte d’utilisateur dans l’annuaire. Si l’utilisateur se connecte ou s’inscrit avec un compte local, ignorez cette étape d’orchestration.

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

Plusieurs conditions préalables peuvent être vérifiées. L’exemple suivant vérifie l’existence d’« objectId » et d’« email ». Si la première condition est true, le parcours passe à l’étape d’orchestration suivante.

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

Sélection du fournisseur de revendications

La sélection du fournisseur de revendications permet aux utilisateurs de sélectionner une action dans une liste d’options. La sélection du fournisseur d’identité consiste en deux étapes d’orchestration :

1. Boutons : il commence par le type ClaimsProviderSelection, ou CombinedSignInAndSignUp contient une liste d’options parmi lesquelles un utilisateur peut choisir. L’ordre des options dans l’élément ClaimsProviderSelections contrôle l’ordre des boutons présentés à l’utilisateur.
2. Actions : suivi par le type de ClaimsExchange. ClaimsExchange contient la liste des actions. L’action fait référence à un profil technique, comme OAuth2, OpenID Connect, une transformation de revendicationsou l’auto-déclaration. Lorsqu’un utilisateur clique sur l’un des boutons, l’action correspondante est exécutée.

L’élément ClaimsProviderSelections contient l’élément suivant :

L’élément ClaimsProviderSelections contient les attributs suivants :

L’élément ClaimsProviderSelection contient les attributs suivants :

Exemple de sélection du fournisseur de revendications

À l’étape d’orchestration suivante, l’utilisateur peut choisir de se connecter avec Facebook, LinkedIn, X, Google ou un compte local. Si l’utilisateur sélectionne l’un des fournisseurs d’identité sociale, la deuxième étape d’orchestration s’exécute avec l’échange de revendication sélectionné spécifié dans l’attribut TargetClaimsExchangeId. La deuxième étape d’orchestration redirige l’utilisateur vers le fournisseur d’identité sociale pour terminer le processus de connexion. Si l’utilisateur choisit de se connecter avec le compte local, Azure AD B2C reste à la même étape d’orchestration (la même page d’inscription ou de connexion) et ignore la deuxième étape d’orchestration.

<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

L’élément ClaimsExchanges contient l’élément suivant :

L’élément ClaimsExchange contient les attributs suivants :

JourneyList

L’élément JourneyList contient l’élément suivant :

Candidat

L’élément Candidate contient les attributs suivants :