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.
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 Chamar uma API REST usando a política personalizada do Azure Active Directory 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 – Fazer declarações
Você precisa fazer mais duas declarações, userPrincipalName
e passwordPolicies
:
ContosoCustomPolicy.XML
No arquivo, localize o elemento ClaimsSchema e declareuserPrincipalName
epasswordPolicies
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
epasswordPolicies
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.
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>
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:Operação: O operação especifica a ação a ser executada, nesse caso, Write. 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 Microsoft Entra ID.
InputClaims: O elemento InputClaims contém uma declaração que é usada para pesquisar uma conta no diretório ou criar uma. Precisa 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. Esse perfil técnico usa a declaração de email como o identificador de chave da conta de usuário. Saiba mais sobre outros identificadores de chave que você pode usar para identificar exclusivamente uma conta de usuário.
No arquivo
ContosoCustomPolicy.XML
, localize o perfil técnicoAAD-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çõesobjectId
,userPrincipalName
,givenName
,surname
edisplayName
se uma conta de usuário comemail
for encontrada na seçãoInputClaim
.
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.
No arquivo
ContosoCustomPolicy.XML
, localize o perfil técnicoClaimGenerator
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çãodisplayName
deve estar disponível antes que o perfil técnicoAAD-UserWrite
grave o registro do usuário no armazenamento do Microsoft Entra ID. No novo código, removemos GenerateRandomObjectIdTransformation à medida queobjectId
é criado e retornado pelo Microsoft Entra ID depois que uma conta é criada. Portanto, não precisamos gerá-la dentro da política.No arquivo
ContosoCustomPolicy.XML
, localize o perfil técnicoUserInformationCollector
e adicione o perfil técnicoUserInputDisplayNameGenerator
como um perfil de validação. Depois de fazer isso, a coleçãoUserInformationCollector
do perfil técnicoValidationTechnicalProfiles
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çãodisplayName
deve estar disponível antes que o perfil técnicoAAD-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:
Entre no portal do Azure com permissões de Administrador global ou de Administrador de funções com privilégios.
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.
Em Serviços do Azure, selecione Azure AD B2C. Ou use a caixa de pesquisa para localizar e selecionar Azure AD B2C.
Em Gerenciar, selecione Usuários.
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 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.
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:
No arquivo
ContosoCustomPolicy.XML
, localize a seçãoBuildingBlocks
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.
No arquivo
ContosoCustomPolicy.XML
, localize o perfil técnico autodeclaradoUserInformationCollector
e substitua a declaração de exibição de email para exibir o controleemailVerificationControl
:De:
<DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
Para:
<DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
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
Saiba como definir atributos personalizados em sua política personalizada.
Saiba como adicionar a expiração de senha à política personalizada.
Saiba mais sobre o perfil técnico do Microsoft Entra ID.