Criar a ramificação no percurso do usuário usando a política personalizada do Azure AD B2C

Artigo
01/11/2024

Diferentes usuários de um mesmo aplicativo podem seguir diferentes percursos do usuário, dependendo dos valores dos dados em uma política personalizada. As diretivas personalizadas do Azure AD B2C (AAD B2C) permitem que você habilite ou desabilite condicionalmente um perfil técnico para obter essa funcionalidade. Por exemplo, em Validar entradas de usuário usando a política personalizada do Azure AD B2C, usamos um 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 EnabledForUserJourneys para permitir que você especifique se um perfil técnico precisa ser executado. O elemento EnabledForUserJourneys contém um dos cinco valores, incluindo OnClaimsExistence , que você usa para especificar que um perfil técnico precisa ser executado somente quando existir uma determinada declaração especificada no perfil técnico. Saiba mais sobre o elemento EnabledForUserJourneys do perfil técnico.

Visão geral do cenário

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

A flowchart of branching in user journey.

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

Pré-requisitos

Se ainda não tiver um, você precisará criar um locatário do Azure AD B2C que esteja 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 em seu computador.
Conclua as etapas em Validar as entradas do usuário usando a política personalizada do Azure AD B2C. Este artigo faz parte da série de guias Criar e executar suas próprias políticas personalizadas.

Observação

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

Etapa 1 - Declarar as Declarações

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

No VS Code, abra o arquivo ContosoCustomPolicy.XML.

Na seção ClaimsSchema, declare as declarações AccessCode e isValidAccessCode usando o código a seguir:

    <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 as transformações da declaração

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

    <!---<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. O CheckIfIsValidAccessCode utiliza 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 (usaremos esse valor para testar) e atribui a declaração true ou false para isValidAccessCode. ThrowIfIsNotValidAccessCode verifica se dois valores booleanos de duas declarações são iguais ou não e gera uma exceção se não forem.

Etapa 3 - Configurar ou atualizar os 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 UserInformationCollector para evitar que ele colete o tipo de conta.

Localize o elemento ClaimsProviders e adicione um novo provedor de declarações usando o 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 a partir do perfil técnico AccessCodeInputCollector. CheckAccessCodeViaClaimsTransformationChecker em si é do tipo Perfil técnico de Transformação de Declarações, que executa as Transformações de Declarações definidas na etapa 2.

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

Localize o elemento ClaimsProviders e adicione um novo provedor de declarações usando o 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, AccountTypeInputCollector, que coleta o tipo de conta do usuário. É o valor dos tipos de conta que determina se o perfil técnico autodeclarado AccessCodeInputCollector precisa ser ativado.

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

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

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

Localize seu percurso de usuário HelloWorldJourney e adicione e substitua todas as etapas de orquestração pelo código a seguir:

    <!--<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 Order das etapas de orquestração. No entanto, o perfil técnico AccessCodeInputCollector será ativado se o usuário selecionar o tipo de conta Conta Pessoal.

Etapa 5 – Carregar arquivo de política personalizado

Siga as etapas em Fazer upload da política personalizada para fazer upload do seu arquivo de política. Se você estiver carregando um arquivo com o mesmo nome que o que já está no portal, selecione Substituir a política personalizada se ela já existir.

Etapa 6 – Testar a política personalizada

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

Na primeira tela, para Tipo de Conta, selecione Conta pessoal.
Para Código de Acesso, insira 88888 e selecione Continuar.
Insira o restante dos detalhes conforme necessário e, em seguida, selecione Continuar. Depois que a política concluir a execução, você será redirecionado para https://jwt.ms 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 solicitações.

Próximas etapas

Na etapa 3, o perfil técnico é habilitado ou desabilitado usando o elemento EnabledForUserJourneys. Alternativamente, você pode usar Pré-condições dentro das etapas de orquestração do percurso do usuário para executar ou ignorar uma etapa de orquestração, como vamos aprender mais adiante nesta série.

Em seguida, aprenda:

Compartilhar via