Criar e ler uma conta de usuário usando a política personalizada do Azure Ative Directory B2C

Artigo
01/11/2024

O Azure Ative Directory B2C (Azure AD B2C) é baseado na ID do Microsoft Entra e, portanto, usa o armazenamento de ID do Microsoft Entra 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 próprio, sobrenome, cidade, código postal e número de telefone, mas você pode estender o perfil de usuário com seus próprios atributos personalizados sem exigir um armazenamento de dados externo.

Sua política personalizada pode se conectar ao armazenamento de ID do Microsoft Entra 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ário antes que um token JWT seja retornado.

Descrição geral do cenário

No artigo Chamar uma API REST usando o Azure Ative Directory B2C custom policy , coletamos informações do usuário, validamos os dados, chamamos de API REST e, finalmente, retornamos um JWT sem armazenar uma conta de usuário. Devemos armazenar as informações do usuário para que não percamos as informações quando a política terminar a execução. Desta vez, depois de coletar as informações do usuário e validá-las, precisamos armazenar as informações do usuário no armazenamento do Azure AD B2C e, em seguida, ler antes de retornar o token JWT. O processo completo é mostrado no diagrama a seguir.

A flowchart of creating a user account in Azure AD.

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 Chamar uma API REST usando a política personalizada do Azure Ative Directory 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 a partir do primeiro artigo.

Etapa 1 - Declarar reclamações

Você precisa declarar mais duas reivindicações, userPrincipalNamee passwordPolicies:

ContosoCustomPolicy.XML No arquivo, localize o elemento ClaimsSchema e declare userPrincipalName e declara usando passwordPolicies 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 do userPrincipalName e passwordPolicies declarações 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 detalhes do usuário no armazenamento de ID do Microsoft Entra e o outro lê uma conta de usuário do armazenamento de ID do Microsoft Entra.

ContosoCustomPolicy.XML No arquivo, localize o elemento ClaimsProviders e adicione um novo provedor de declarações usando o código abaixo. Este provedor de declarações possui 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>

No provedor de declarações que você acabou de criar, adicione um perfil técnico do Microsoft Entra ID 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>

Adicionámos um novo perfil técnico do Microsoft Entra ID, AAD-UserWrite. É necessário tomar nota das seguintes partes importantes do perfil técnico:

Operação: A operação especifica a ação a ser executada, neste caso, Gravar. Saiba mais sobre outras operações em um provedor técnico do Microsoft Entra ID.
Declarações persistentes: O elemento PersistedClaims contém todos os valores que devem ser armazenados no armazenamento de ID do Microsoft Entra.
InputClaims: O elemento InputClaims contém uma declaração, que é usada para procurar uma conta no diretório ou criar uma nova. Deve haver exatamente um elemento de declaração de entrada na coleção de declarações de entrada para todos os perfis técnicos do Microsoft Entra ID. Este perfil técnico usa a declaração de e-mail como o identificador de chave para a conta de usuário. Saiba mais sobre outros identificadores de chave que você pode usar para identificar exclusivamente uma conta de usuário.

ContosoCustomPolicy.XML No arquivo, localize o perfil técnico e, em seguida, adicione um novo perfil técnico depois dele usando o AAD-UserWrite 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>

Adicionámos um novo perfil técnico do Microsoft Entra ID, AAD-UserRead. Configuramos este perfil técnico para executar uma operação de leitura e para retornar objectId, , givenNamesurname userPrincipalNamee displayName declarações se uma conta de usuário com a email seção na InputClaim for encontrada.

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

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

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

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

Etapa 4 - Atualizar o perfil técnico do ClaimGenerator

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

ContosoCustomPolicy.XML No arquivo, localize o perfil técnico e substitua-o ClaimGenerator 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 técnicos separados. O perfil técnico UserInputMessageClaimGenerator gera a mensagem enviada como declaração no token JWT. O perfil técnico UserInputDisplayNameGenerator gera a displayName declaração. O displayName valor da declaração deve estar disponível antes que o perfil técnico grave o AAD-UserWrite registro do usuário no armazenamento do Microsoft Entra ID. No novo código, removemos o GenerateRandomObjectIdTransformation à medida que o é criado e retornado pelo ID do Microsoft Entra depois que objectId uma conta é criada, portanto, não precisamos gerá-lo nós mesmos dentro da política.

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

    <!--<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, pois o valor da declaração deve estar disponível antes AAD-UserWrite que o perfil técnico grave o displayName AAD-UserWrite registro do usuário no armazenamento do Microsoft Entra ID.

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

Localize sua HelloWorldJourney jornada do usuário 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 4de orquestração, executamos o AAD-UserRead perfil técnico para ler os detalhes do usuário (a serem incluídos no token JWT) da conta de usuário criada.

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

Passo 6 - Política de carregamento

Siga as etapas em Carregar arquivo de política personalizado para carregar seu arquivo de política. Se você estiver carregando um arquivo com o mesmo nome que o que já está no portal, certifique-se de selecionar Substituir a política personalizada, se ela já existir.

Etapa 7 - Política de teste

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

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

Entre no portal do Azure com permissões de Administrador Global ou Administrador de Função Privilegiada.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Em Serviços do Azure, selecione Azure AD B2C. Ou use a caixa de pesquisa para localizar e selecionar Azure AD B2C.
Em Gerir, selecione Utilizadores.
Localize a conta de usuário que você acabou de criar e selecione-a. O perfil da conta é semelhante à captura de tela abaixo:

Em nosso AAD-UserWrite perfil técnico 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 e-mail. Em vez de a política ser executada até a conclusão para emitir um token de ID, você verá uma mensagem de erro semelhante à captura de tela abaixo.

A screenshot of error as account already exists.

Nota

O valor da declaração de senha é uma informação muito importante, portanto, tenha muito cuidado com a forma como você lida 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 reivindicação de senha no perfil técnico autodeclarado, esse valor só está disponível dentro do mesmo perfil técnico ou dentro de um perfil técnico de validação que são referenciados por esse mesmo perfil técnico autodeclarado. Uma vez concluída a execução desse perfil técnico autodeclarado e transferida para outro perfil técnico, o valor é perdido.

Verificar o endereço de e-mail do usuário

Recomendamos que você verifique o e-mail de um usuário antes de usá-lo para criar uma conta de usuário. Ao verificar endereços de e-mail, você garante que as contas sejam criadas por usuários reais. Você também ajuda os usuários a terem certeza de que estão usando seus endereços de e-mail 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 e-mail. Depois que o código for enviado, 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 da interface do usuário que tem funcionalidade especial e interage com o serviço back-end do Azure Ative Directory B2C (Azure AD 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 são exibidos 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, use as seguintes etapas:

Declarar reivindicação

Você precisa declarar uma reivindicação a ser usada para armazenar o código de verificação.

Para declarar a declaração, no arquivo, localize o ContosoCustomPolicy.XML elemento e declare verificationCode a ClaimsSchema declaração 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 envio e verificação de código

O Azure AD B2C usa o perfil técnico SSPR do Microsoft Entra ID para verificar um endereço de email. Este perfil técnico pode gerar e enviar um código para um endereço de e-mail ou verifica o código dependendo de como você o configura.

ContosoCustomPolicy.XML No arquivo, localize o elemento e adicione o provedor de declarações usando o ClaimsProviders 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 AadSspr-SendCode técnicos e AadSspr-VerifyCode. AadSspr-SendCode gera e envia um código para o endereço de e-mail especificado na InputClaims seção enquanto AadSspr-VerifyCode verifica o código. Você especifica 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 e-mail para poder verificar o e-mail dos usuários. O controle de exibição de verificação de e-mail que você configurar substituirá a declaração de exibição de e-mail que você usa para coletar um e-mail do usuário.

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

ContosoCustomPolicy.XML No arquivo, localize a BuildingBlocks seção e, em seguida, 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. Tome nota das 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.
Actions - 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 AadSspr-SendCode perfil técnico, que gera e envia um código para um endereço de e-mail.

No arquivo, localize o ContosoCustomPolicy.XML UserInformationCollector perfil técnico autodeclarado e substitua a declaração de exibição de e-mail para emailVerificationControl exibir o controle:

Da:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
Para:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
Use o procedimento na etapa 6 e na etapa 7 para carregar seu arquivo de política e testá-lo. Desta vez, você deve verificar seu endereço de e-mail antes de criar uma conta de usuário.

Atualizar 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, defina o perfil técnico do Microsoft Entra ID para gerar um erro se a conta de usuário especificada ainda não existir na Metadata coleção 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>

Utilizar atributos personalizados

Neste artigo, você aprendeu como armazenar detalhes do usuário usando atributos de perfil de usuário internos. No entanto, muitas vezes você precisa criar seus próprios atributos personalizados para gerenciar seu cenário específico. Para fazer isso, siga as instruções no artigo Definir atributos personalizados no Azure Ative Directory B2C .

Próximos passos

Saiba como configurar um fluxo de inscrição e entrada para uma conta local usando a política personalizada do Azure Ative Directory B2C.
Saiba como definir atributos personalizados em sua política personalizada.
Saiba como adicionar a expiração da senha à política personalizada.
Saiba mais sobre o perfil técnico do Microsoft Entra ID.

Partilhar via