Compartilhar via


Crie e leia uma conta de usuário usando a política personalizada do Azure Active Directory B2C

O Azure Active Directory B2C (Azure AD B2C) é criado no Microsoft Entra ID e, portanto, usa o armazenamento do Microsoft Entra ID para armazenar contas de usuário. O perfil de usuário do diretório do Azure AD B2C vem com um conjunto interno de atributos, como nome, sobrenome, cidade, cep e número de telefone, mas você pode ampliar o perfil do usuário com seus próprios atributos personalizados sem exigir um armazenamento de dados externo.

Sua política personalizada pode se conectar ao armazenamento do Microsoft Entra ID usando o perfil técnico do Microsoft Entra ID para armazenar, atualizar ou excluir informações do usuário. Neste artigo, você aprenderá a configurar um conjunto de perfis técnicos do Microsoft Entra ID para armazenar e ler uma conta de usuários antes que um token JWT seja retornado.

Visão geral do cenário

No artigo Chamar uma API REST usando a política personalizada do Azure Active Directory B2C, coletamos informações do usuário, validamos os dados, chamamos uma API REST e, por fim, retornamos um JWT sem armazenar uma conta de usuário. Devemos armazenar as informações dos usuários para não perdermos as informações depois que a política terminar a execução. Desta vez, depois que coletamos as informações do usuário e as validamos, precisamos armazenar as informações do usuário no armazenamento Azure AD B2C e ler antes de retornarmos o token JWT. O processo completo é mostrado no diagrama a seguir.

A flowchart of creating a user account in Azure AD.

Pré-requisitos

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 – Fazer declarações

Você precisa fazer mais duas declarações, userPrincipalName e passwordPolicies:

  1. ContosoCustomPolicy.XML No arquivo, localize o elemento ClaimsSchema e declare userPrincipalName e passwordPolicies usando o seguinte código:

        <ClaimType Id="userPrincipalName">
            <DisplayName>UserPrincipalName</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
        </ClaimType>
        <ClaimType Id="passwordPolicies">
            <DisplayName>Password Policies</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
        </ClaimType>
    

    Saiba mais sobre os usos das declarações userPrincipalName e passwordPolicies no artigo Atributos de perfil de usuário.

Etapa 2 – Criar perfis técnicos do Microsoft Entra ID

Você precisa configurar dois perfis técnicos do Microsoft Entra ID. Um perfil técnico grava os detalhes do usuário no armazenamento do Microsoft Entra ID e o outro lê uma conta de usuário do armazenamento do Microsoft Entra ID.

  1. No arquivo ContosoCustomPolicy.XML, localize o elemento ClaimsProviders e adicione um novo provedor de declarações usando o código abaixo. Esse provedor de declarações contém os perfis técnicos do Microsoft Entra ID:

        <ClaimsProvider>
            <DisplayName>Azure AD Technical Profiles</DisplayName>
            <TechnicalProfiles>
                <!--You'll add you Azure AD Technical Profiles here-->
            </TechnicalProfiles>
        </ClaimsProvider>
    
  2. Adicione um perfil técnico do Microsoft Entra ID no provedor de declarações que você acabou de criar, usando o seguinte código:

        <TechnicalProfile Id="AAD-UserWrite">
            <DisplayName>Write user information to AAD</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">Write</Item>
                <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
                <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
            </InputClaims>
            <PersistedClaims>
                <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
                <PersistedClaim ClaimTypeReferenceId="displayName" />
                <PersistedClaim ClaimTypeReferenceId="givenName" />
                <PersistedClaim ClaimTypeReferenceId="surname" />
                <PersistedClaim ClaimTypeReferenceId="password"/>
                <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
            </PersistedClaims>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="objectId" />
                <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
                <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
            </OutputClaims>
        </TechnicalProfile>
    

    Adicionamos um novo perfil técnico do Microsoft Entra ID, AAD-UserWrite. Você precisa tomar nota das seguintes partes importantes do perfil técnico:

  3. No arquivo ContosoCustomPolicy.XML, localize o perfil técnico AAD-UserWrite e adicione um novo perfil técnico depois dele usando o seguinte código:

        <TechnicalProfile Id="AAD-UserRead">
            <DisplayName>Read user from Azure AD storage</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">Read</Item>
                <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
                <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
            </InputClaims>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="objectId" />
                <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
                <OutputClaim ClaimTypeReferenceId="givenName"/>
                <OutputClaim ClaimTypeReferenceId="surname"/>
                <OutputClaim ClaimTypeReferenceId="displayName"/>
            </OutputClaims>
        </TechnicalProfile>
    

    Adicionamos um novo perfil técnico do Microsoft Entra ID, AAD-UserRead. Configuramos esse perfil técnico para executar uma operação de leitura e retornar as declarações objectId, userPrincipalName, givenName,surname e displayName se uma conta de usuário com email for encontrada na seção InputClaim.

Etapa 3 – Usar o perfil técnico do Microsoft Entra ID

Depois de coletarmos detalhes do usuário usando o perfil técnico autodeclarado UserInformationCollector, precisamos gravar uma conta de usuário no armazenamento do Microsoft Entra ID usando o perfil técnico AAD-UserWrite. Para fazer isso, use o perfil técnico AAD-UserWrite como um perfil técnico de validação no perfil técnico autodeclarado UserInformationCollector.

ContosoCustomPolicy.XML No arquivo, localize o perfil técnico UserInformationCollector e adicione o perfil técnico AAD-UserWrite como um perfil técnico de validação na coleção ValidationTechnicalProfiles. Você precisa adicionar isso após o perfil técnico de validação CheckCompanyDomain.

Usaremos o perfil técnico AAD-UserRead nas etapas de orquestração do percurso do usuário para ler os detalhes do usuário antes de emitir um token JWT.

Etapa 4 – Atualizar o perfil técnico ClaimGenerator

Usamos o perfil técnico ClaimGenerator para executar três transformações de declarações, GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation e CreateMessageTransformation.

  1. No arquivo ContosoCustomPolicy.XML, localize o perfil técnico ClaimGenerator e substitua-o pelo seguinte código:

        <TechnicalProfile Id="UserInputMessageClaimGenerator">
            <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
            <Protocol Name="Proprietary"
                Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="message" />
            </OutputClaims>
            <OutputClaimsTransformations>
                <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
            </OutputClaimsTransformations>
        </TechnicalProfile>
    
        <TechnicalProfile Id="UserInputDisplayNameGenerator">
            <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
            <Protocol Name="Proprietary"
                Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="displayName" />
            </OutputClaims>
            <OutputClaimsTransformations>
                <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
            </OutputClaimsTransformations>
        </TechnicalProfile>
    

    Dividimos o perfil técnico em dois perfis separados. O perfil técnico UserInputMessageClaimGenerator gera a mensagem enviada como declaração no token JWT. O perfil técnico UserInputDisplayNameGenerator gera a declaração displayName. O valor da declaração displayName deve estar disponível antes que o perfil técnico AAD-UserWrite grave o registro do usuário no armazenamento do Microsoft Entra ID. No novo código, removemos GenerateRandomObjectIdTransformation à medida que objectId é criado e retornado pelo Microsoft Entra ID depois que uma conta é criada. Portanto, não precisamos gerá-la dentro da política.

  2. No arquivo ContosoCustomPolicy.XML, localize o perfil técnico UserInformationCollector e adicione o perfil técnico UserInputDisplayNameGenerator como um perfil de validação. Depois de fazer isso, a coleção UserInformationCollector do perfil técnico ValidationTechnicalProfiles deve ser semelhante ao seguinte código:

        <!--<TechnicalProfile Id="UserInformationCollector">-->
            <ValidationTechnicalProfiles>
                <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                    <Preconditions>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                            <Value>accountType</Value>
                            <Value>work</Value>
                            <Action>SkipThisValidationTechnicalProfile</Action>
                        </Precondition>
                    </Preconditions>
                </ValidationTechnicalProfile>                        
                <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
                <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
            </ValidationTechnicalProfiles>
        <!--</TechnicalProfile>-->
    

    Você deve adicionar o perfil técnico de validação antes de AAD-UserWrite, pois o valor da declaração displayName deve estar disponível antes que o perfil técnico AAD-UserWrite grave o registro do usuário no armazenamento do Microsoft Entra ID.

Etapa 5 – Atualizar as etapas de orquestração do percurso do usuário

Localize o percurso do usuário HelloWorldJourney e substitua todas as etapas de orquestração pelo 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="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

Na etapa de orquestração 4, executamos o perfil técnico AAD-UserRead para ler os detalhes do usuário (a serem incluídos no token JWT) da conta do usuário.

Como não armazenamos a declaração message, na etapa de orquestração 5, executamos UserInputMessageClaimGenerator para gerar a declaração message e incluir o token JWT.

Etapa 6 – Fazer o upload da política

Siga as instruções em Carregar arquivo de política personalizado para carregar o 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 7 – Testar a política

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

Depois que a política concluir a execução e você receber o token de ID, verifique se o registro de usuário foi criado:

  1. Entre no portal do Azure com permissões de Administrador global ou de Administrador de funções com privilégios.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.

  3. Em Serviços do Azure, selecione Azure AD B2C. Ou use a caixa de pesquisa para localizar e selecionar Azure AD B2C.

  4. Em Gerenciar, selecione Usuários.

  5. Localize a conta de usuário que você acabou de criar e selecione-a. O perfil da conta é semelhante à captura de tela abaixo:

    A screenshot of creating a user account in Azure AD.

Em nosso perfil técnico AAD-UserWrite do Microsoft Entra ID, especificamos que, se o usuário já existir, geraremos uma mensagem de erro.

Teste sua política personalizada novamente usando o mesmo endereço de Email. Em vez da política ser executada até a conclusão para emitir um token de ID, você poderá ver uma mensagem de erro semelhante à captura de tela abaixo.

A screenshot of error as account already exists.

Observação

O valor da declaração de senha é uma informação muito importante. Tenha muito cuidado ao lidar com isso em sua política personalizada. Por um motivo semelhante, o Azure AD B2C trata o valor da declaração de senha como um valor especial. Quando você coleta o valor da declaração de senha no perfil técnico autodeclarado, esse valor só fica disponível dentro do mesmo perfil técnico ou dentro de perfis técnicos de validação referenciados por esse mesmo perfil técnico autodeclarado. Depois que a execução desse perfil técnico autodeclarado for concluída e passar para outro perfil técnico, o valor será perdido.

Verificar endereço de email do usuário

Recomendamos que você verifique o email do usuário antes de usá-lo para criar uma conta de usuário. Ao verificar os endereços de email, você pode confirmar se as contas são criadas por usuários reais. Você também ajuda os usuários a ter certeza de que eles estão usando os endereços de email corretos para criar uma conta.

A política personalizada do Azure AD B2C fornece uma maneira de verificar o endereço de email usando o controle de exibição de verificação. Você envia um código de verificação para o email. Depois do envio do código, o usuário lê a mensagem, insere o código de verificação no controle fornecido pelo controle de exibição e seleciona o botão Verificar Código.

Um controle de exibição é um elemento de interface do usuário que tem funcionalidade especial e interage com o serviço de back-end do Azure AD B2C (Azure Active Directory B2C). Ele permite que o usuário execute ações na página que invocam um perfil técnico de validação no back-end. Os controles de exibição aparecem na página e são referenciados por um perfil técnico autodeclarado.

Para adicionar a verificação de email usando um controle de exibição, siga as seguintes etapas:

Fazer declaração

Você precisa fazer uma declaração a ser usada para manter o código de verificações.

Para fazer a declaração, no arquivo ContosoCustomPolicy.XML, localize o elemento ClaimsSchema e faça a declaração verificationCode usando o seguinte código:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Configurar um perfil técnico de enviar e verificar código

O Azure AD B2C usa o perfil técnico de SSPR do Microsoft Entra ID para verificar um endereço de email. Esse perfil técnico pode gerar e enviar um código para um endereço de email ou verificar o código, depedendo da configuração.

No arquivo ContosoCustomPolicy.XML, localize o elemento ClaimsProviders e adicione o provedor de declarações usando o seguinte código:

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Configuramos dois perfis técnicos AadSspr-SendCode e AadSspr-VerifyCode. AadSspr-SendCode gera e envia um código para o endereço de email especificado na seção InputClaims, enquanto AadSspr-VerifyCode verifica o código. Especifique a ação que deseja executar nos metadados do perfil técnico.

Configurar um controle de exibição

Você precisa configurar um controle de exibição de verificação de email para poder verificar o email dos usuários. Esse controle de exibição substituirá a declaração de exibição de email que você usa para coletar um email do usuário.

Para configurar um controle de exibição, siga as seguintes etapas:

  1. No arquivo ContosoCustomPolicy.XML, localize a seção BuildingBlocks e adicione um controle de exibição como um elemento filho usando o seguinte código:

        <!--<BuildingBlocks>-->
            ....
            <DisplayControls>
                <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
                  <DisplayClaims>
                    <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                    <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
                  </DisplayClaims>
                  <OutputClaims></OutputClaims>
                  <Actions>
                    <Action Id="SendCode">
                      <ValidationClaimsExchange>
                        <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                      </ValidationClaimsExchange>
                    </Action>
                    <Action Id="VerifyCode">
                      <ValidationClaimsExchange>
                        <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                      </ValidationClaimsExchange>
                    </Action>
                  </Actions>
                </DisplayControl>
            </DisplayControls> 
        <!--</BuildingBlocks>-->
    

    Declaramos um controle de exibição, emailVerificationControl. Observe as seguintes partes importantes:

    • DisplayClaims - Assim como em um perfil técnico autodeclarado, esta seção especifica uma coleção de declarações a serem coletadas do usuário dentro do controle de exibição.

    • Ações – Especifica a ordem das ações a serem executadas pelo controle de exibição. Cada ação faz referência a um perfil técnico responsável por executar as ações. Por exemplo, o SendCode faz referência ao perfil técnico AadSspr-SendCode, que gera e envia um código para um endereço de email.

  2. No arquivo ContosoCustomPolicy.XML, localize o perfil técnico autodeclarado UserInformationCollector e substitua a declaração de exibição de email para exibir o controleemailVerificationControl:

    De:

        <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
    

    Para:

        <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
    
  3. Use o procedimento nas etapas 6 e 7 para carregar e testar o arquivo de política. Desta vez, você deve verificar seu endereço de email antes que uma conta de usuário seja criada.

Atualizar a conta de usuário usando o perfil técnico do Microsoft Entra ID

Você pode configurar um perfil técnico do Microsoft Entra ID para atualizar uma conta de usuário em vez de tentar criar uma nova. Para fazer isso, configure o perfil técnico do Microsoft Entra ID para gerar um erro se a conta de usuário especificada ainda não existir na coleção Metadata usando o código a seguir. A Operação precisa ser definida como Gravação:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

Usar atributos personalizados

Neste artigo, você aprendeu a armazenar detalhes do usuário usando os atributos de perfil de usuário internos. No entanto, geralmente você precisa criar atributos personalizados para gerenciar o seu cenário específico. Para fazer isso, siga as instruções no artigo Definir atributos personalizados no Azure Active Directory B2C.

Próximas etapas