Criar ramificação na jornada do usuário usando a política personalizada do Azure Ative Directory B2C

Artigo
01/11/2024

Diferentes usuários do mesmo aplicativo podem seguir diferentes jornadas de usuário, dependendo dos valores dos dados em uma política personalizada. As políticas personalizadas do Azure Ative Directory B2C (Azure AD B2C) permitem habilitar ou desabilitar condicionalmente um perfil técnico para alcançar esse recurso. Por exemplo, em Validar entradas de usuário usando a política personalizada do Azure AD B2C, usamos a Precondition para determinar se devemos ou não executar um perfil técnico de validação com base no valor da declaração accountType .

Um perfil técnico também fornece um elemento para permitir que você especifique se um EnabledForUserJourneys perfil técnico deve ou não ser executado. O EnabledForUserJourneys elemento contém um dos cinco valores, incluindo OnClaimsExistence, que você usa para especificar que um perfil técnico deve ser executado somente quando uma determinada declaração especificada no perfil técnico existe. Saiba mais sobre o elemento EnabledForUserJourneys do perfil técnico.

Descrição geral do cenário

No artigo de política personalizada Validar entradas de usuário usando o Azure AD B2C, um usuário insere seus detalhes em uma única tela. Neste artigo, um usuário precisa primeiro selecionar seu tipo de conta, Conta de Funcionário da Contoso ou Conta Pessoal. Um usuário que seleciona Conta de Funcionário da Contoso pode continuar a fornecer mais detalhes. No entanto, um usuário que seleciona Conta Pessoal precisa fornecer um código de acesso de convite válido antes de poder continuar a fornecer mais detalhes. Assim, os usuários que usam o tipo de conta Conta Pessoal veem uma interface de usuário extra para concluir sua jornada.

A flowchart of branching in user journey.

Neste artigo, você aprenderá a usar EnabledForUserJourneys o elemento dentro de um perfil técnico para criar diferentes experiências de usuário com base em um valor de declaração.

Pré-requisitos

Se você ainda não tiver um, crie um locatário do Azure AD B2C vinculado à sua assinatura do Azure.
Registre um aplicativo Web e habilite a concessão implícita de token de ID. Para o URI de redirecionamento, use https://jwt.ms.
Você deve ter o Visual Studio Code (VS Code) instalado no seu computador.
Conclua as etapas em Validar entradas de usuário usando a política personalizada do Azure AD B2C. Este artigo faz parte da série de guias de instruções Criar e executar suas próprias políticas personalizadas.

Nota

Este artigo faz parte da série de guias de instruções Criar e executar suas próprias políticas personalizadas no Azure Ative Directory B2C. Recomendamos que comece esta série desde o primeiro artigo.

Etapa 1 - Declarar reclamações

Um usuário que seleciona Conta Pessoal precisa fornecer um código de acesso válido. Então, precisamos de uma reivindicação para manter esse valor:

No VS Code, abra o ContosoCustomPolicy.XML arquivo.

ClaimsSchema Na seção , declare as declarações accessCode e isValidAccessCode usando o seguinte código:

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

Etapa 2 - Definir transformações de declarações

Localize o ClaimsTransformations elemento e adicione as seguintes transformações de declarações:

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

Definimos duas transformações de declarações, CheckIfIsValidAccessCode e ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode usa o método de transformação CompareClaimToValue para comparar a entrada do código de acesso pelo usuário com um valor estático 88888 (vamos usar esse valor para teste) e atribui true ou false à declaração isValidAccessCode. ThrowIfIsNotValidAccessCode verifica se dois valores booleanos de duas declarações são iguais e lança uma exceção se não forem.

Etapa 3 - Configurar ou atualizar perfis técnicos

Agora você precisa de dois novos perfis técnicos autodeclarados, um para coletar o tipo de conta e outro para coletar o código de acesso do usuário. Você também precisa de um novo perfil técnico de tipo de transformação de declarações para validar o código de acesso do usuário executando as transformações de declarações definidas na etapa 2. Agora que estamos coletando o tipo de conta em um perfil técnico autodeclarado diferente, precisamos atualizar o perfil técnico autodeclarado para evitar que ele colete o UserInformationCollector tipo de conta.

Localize o elemento e, em seguida, adicione um novo provedor de declarações usando o ClaimsProviders seguinte código:

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

Configuramos dois perfis técnicos, AccessCodeInputCollector e CheckAccessCodeViaClaimsTransformationChecker. Chamamos o perfil técnico CheckAccessCodeViaClaimsTransformationChecker como um perfil técnico de validação de dentro do perfil técnico AccessCodeInputCollector . O próprio CheckAccessCodeViaClaimsTransformationChecker é do tipo Perfil técnico de Transformação de Declarações, que executa as Transformações de Declarações que definimos na etapa 2.

AccessCodeInputCollector é um perfil técnico autodeclarado usado para coletar um código de acesso do usuário. EnabledForUserJourneys Inclui um elemento definido como OnClaimsExistence. Seu Metadata elemento inclui uma declaração (accountType) e seu valor (pessoal) que ativa esse perfil técnico.

Localize o elemento e, em seguida, adicione um novo provedor de declarações usando o ClaimsProviders seguinte código:

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

Configuramos um perfil técnico autodeclarado, AccountTypeInputCollectorque coleta o tipo de conta do usuário. É o valor dos tipos de conta que determina se o AccessCodeInputCollector perfil técnico autodeclarado deve ser ativado.

Para evitar que o perfil técnico autodeclarado colete o tipo de conta, localize o UserInformationCollector UserInformationCollector perfil técnico autodeclarado e, em seguida:
1. Remova a accountType declaração <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> de exibição da DisplayClaims coleção.
2. Remova a accountType declaração de saída, , <OutputClaim ClaimTypeReferenceId="accountType"/>da OutputClaims coleção.

Etapa 4 - Atualizar as etapas de orquestração da jornada do usuário

Agora que você configurou seus perfis técnicos, precisa atualizar suas etapas de orquestração da jornada do usuário:

Localize sua HelloWorldJourney jornada de usuário e adicione substituir todas as etapas de orquestração com o seguinte código:

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

As etapas de orquestração mostram que chamamos o perfil técnico na ordem mostrada pelo atributo das etapas de Order orquestração. No entanto, o perfil técnico é ativado se o AccessCodeInputCollector usuário selecionar o tipo de conta pessoal .

Etapa 5 - Carregar arquivo de política personalizado

Siga as etapas em Carregar arquivo de política personalizado para carregar seu arquivo de política. Se estiver a carregar um ficheiro com o mesmo nome que o que já se encontra no portal, certifique-se de que seleciona Substituir a política personalizada, caso já exista.

Etapa 6 - Testar a política personalizada

Siga as etapas em Testar a política personalizada para testar sua política personalizada:

Na primeira tela, em Tipo de Conta, selecione Conta Pessoal.
Para Código de Acesso, digite 88888 e selecione Continuar.
Introduza os restantes detalhes conforme necessário e, em seguida, selecione Continuar. Depois que a política terminar a execução, você será redirecionado para https://jwt.mso , e verá um token JWT decodificado.
Repita a etapa 5, mas, desta vez, selecione Tipo de Conta, selecione Conta de Funcionário da Contoso e siga as instruções.

Próximos passos

Na etapa 3, ativamos ou desabilitamos o perfil técnico usando o EnabledForUserJourneys elemento . Como alternativa, você pode usar Pré-condições dentro das etapas de orquestração da jornada do usuário para executar ou pular uma etapa de orquestração, conforme aprendemos mais adiante nesta série.

A seguir, aprenda:

Sobre as pré-condições das etapas de orquestração da jornada do usuário.
Como usar o arquivo de esquema TrustFrameworkPolicy para validar arquivos de política do Azure AD B2C.

Partilhar via