UserJourneys

Os percursos do utilizador especificam caminhos explícitos através dos quais uma política permite que uma aplicação de entidade confiadora obtenha as afirmações desejadas para um utilizador. O utilizador utiliza estes caminhos para obter as afirmações que devem ser apresentadas à entidade confiadora. Em outras palavras, as jornadas do usuário definem a lógica de negócios do que um usuário final passa à medida que a Estrutura de Experiência de Identidade B2C do Azure AD processa a solicitação.

Essas jornadas do usuário podem ser consideradas como modelos disponíveis para satisfazer a necessidade central das várias partes confiáveis da comunidade de interesse. As jornadas do usuário facilitam a definição da parte confiável de uma política. Uma política pode definir várias jornadas de usuário. Cada jornada do usuário é uma sequência de etapas de orquestração.

Para definir as jornadas do usuário suportadas pela política, um UserJourneys elemento é adicionado sob o elemento de nível TrustFrameworkPolicy superior do arquivo de política.

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

O elemento UserJourneys contém o seguinte elemento :

O elemento UserJourney contém o seguinte atributo:

O elemento UserJourney contém os seguintes elementos:

AutorizaçãoPerfis Técnicos

Suponha que um usuário tenha concluído uma UserJourney e obtido um acesso ou um token de ID. Para gerenciar recursos adicionais, como o ponto de extremidade UserInfo, o usuário deve ser identificado. Para iniciar esse processo, o usuário deve apresentar o token de acesso emitido anteriormente como prova de que foi originalmente autenticado por uma política válida do Azure AD B2C. Um token válido para o usuário deve estar sempre presente durante esse processo para garantir que o usuário tenha permissão para fazer essa solicitação. Os perfis técnicos de autorização validam o token de entrada e extraem declarações do token.

O elemento AuthorizationTechnicalProfiles contém o seguinte elemento:

O elemento AuthorizationTechnicalProfile contém o seguinte atributo:

O exemplo a seguir mostra um elemento de jornada do usuário com perfis técnicos de autorização:

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

OrchestrationSteps

Uma jornada do usuário é representada como uma sequência de orquestração que deve ser seguida para uma transação bem-sucedida. Se alguma etapa falhar, a transação falhará. Essas etapas de orquestração fazem referência aos blocos de construção e aos provedores de declarações permitidos no arquivo de política. Qualquer etapa de orquestração responsável por mostrar ou renderizar uma experiência do usuário também tem uma referência ao identificador de definição de conteúdo correspondente.

As etapas de orquestração podem ser executadas condicionalmente com base em pré-condições definidas no elemento da etapa de orquestração. Por exemplo, você pode verificar a execução de uma etapa de orquestração somente se existir uma declaração específica ou se uma declaração for igual ou não ao valor especificado.

Para especificar a lista ordenada de etapas de orquestração, um elemento OrchestrationSteps é adicionado como parte da política. Este elemento é obrigatório.

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

O elemento OrchestrationSteps contém o seguinte elemento :

O elemento OrchestrationStep contém os seguintes atributos:

O elemento OrchestrationStep pode conter os seguintes elementos:

Pré-condições

As etapas de orquestração podem ser executadas condicionalmente com base nas pré-condições definidas na etapa de orquestração. O Preconditions elemento contém uma lista de pré-condições a avaliar. Quando a avaliação de pré-condição é satisfeita, a etapa de orquestração associada pula para a próxima etapa de orquestração.

O Azure AD B2C avalia as pré-condições em ordem de lista. As pré-condições baseadas em ordem permitem definir a ordem na qual as pré-condições são aplicadas. A primeira condição prévia satisfeita sobrepõe-se a todas as condições prévias subsequentes. A etapa de orquestração é executada somente se todas as pré-condições não forem satisfeitas.

O elemento Preconditions contém o seguinte elemento:

Condição prévia

O elemento Precondition contém os seguintes atributos:

Os elementos Precondition contêm os seguintes elementos:

Cada pré-condição avalia uma única reivindicação. Existem dois tipos de pré-condições:

• ClaimsExist - Especifica que as ações devem ser executadas se as declarações especificadas existirem no pacote de declarações atual do usuário.

• ClaimEquals - Especifica que as ações devem ser executadas se a declaração especificada existir e seu valor for igual ao valor especificado. A verificação executa uma comparação ordinal que diferencia maiúsculas de minúsculas. Ao verificar o tipo de declaração booleana, use Trueou False.

  Se a declaração for nula ou não inicializada, a pré-condição será ignorada, seja a ExecuteActionsIf , trueou false. Como prática recomendada, verifique se a reivindicação existe e se é igual a um valor.

Um cenário de exemplo seria desafiar o usuário para MFA se o usuário tiver MfaPreference definido como Phone. Para executar essa lógica condicional, verifique se a MfaPreference declaração existe e também verifique se o valor da declaração é igual a Phone. O XML a seguir demonstra como implementar essa lógica com pré-condições.  

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

Exemplos de pré-condições

As pré-condições a seguir verificam se o objectId do usuário existe. Na jornada do usuário, o usuário selecionou entrar usando a conta local. Se o objectId existir, ignore esta etapa de orquestração.

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

As pré-condições a seguir verificam se o usuário entrou com uma conta social. É feita uma tentativa para encontrar a conta de usuário no diretório. Se o usuário entrar ou se inscrever com uma conta local, ignore esta etapa de orquestração.

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

As pré-condições podem verificar várias pré-condições. O exemplo a seguir verifica se 'objectId' ou 'email' existe. Se a primeira condição for verdadeira, a jornada pula para a próxima etapa de orquestração.

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

Seleção do fornecedor de sinistros

A seleção do provedor de declarações permite que os usuários selecionem uma ação em uma lista de opções. A seleção do provedor de identidade consiste em duas etapas de orquestração:

1. Botões - Começa com o tipo de ClaimsProviderSelection, ou CombinedSignInAndSignUp que contém uma lista de opções que um usuário pode escolher. A ordem das opções dentro do elemento controla ClaimsProviderSelections a ordem dos botões apresentados ao usuário.
2. Ações - Seguido por tipo de ClaimsExchange. O ClaimsExchange contém uma lista de ações. A ação é uma referência a um perfil técnico, como OAuth2, OpenID Connect, transformação de declarações ou autoafirmação. Quando um usuário clica em um dos botões, a ação correspondente é executada.

O elemento ClaimsProviderSelections contém o seguinte elemento:

O elemento ClaimsProviderSelections contém os seguintes atributos:

O elemento ClaimsProviderSelection contém os seguintes atributos:

Exemplo de seleção do provedor de declarações

Na etapa de orquestração a seguir, o usuário pode optar por entrar com o Facebook, LinkedIn, X, Google ou uma conta local. Se o usuário selecionar um dos provedores de identidade social, a segunda etapa de orquestração será executada com a troca de declarações selecionada especificada no TargetClaimsExchangeId atributo. A segunda etapa de orquestração redireciona o usuário para o provedor de identidade social para concluir o processo de login. Se o usuário optar por entrar com a conta local, o Azure AD B2C permanecerá na mesma etapa de orquestração (a mesma página de inscrição ou página de entrada) e ignorará a segunda etapa de orquestração.

<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

O elemento ClaimsExchanges contém o seguinte elemento :

O elemento ClaimsExchange contém os seguintes atributos:

Lista de Viagens

O elemento JourneyList contém o seguinte elemento :

Candidato

O elemento Candidate contém os seguintes atributos: