Configurar um fluxo de inscrição e entrada para uma conta local usando a política personalizada do Azure Ative Directory B2C
No artigo Criar e ler uma conta de usuário usando o Azure Ative Directory B2C , um usuário cria uma nova conta de usuário, mas não entra nela.
Neste artigo, você aprenderá a escrever uma política personalizada do Azure Ative Directory B2C (Azure AD B2C) que permite que um usuário crie uma conta local do Azure AD B2C ou entre em uma. Uma conta local refere-se a uma conta que é criada em seu locatário do Azure AD B2C quando um usuário se inscreve em seu aplicativo.
Descrição geral
O Azure AD B2C usa o protocolo de autenticação OpenID Connect para verificar as credenciais do usuário. No Azure AD B2C, você envia as credenciais do usuário junto com outras informações para um ponto de extremidade seguro, que determina se as credenciais são válidas ou não. Em resumo, quando você usa a implementação do OpenID Connect do Azure AD B2C, pode terceirizar a inscrição, o logon e outras experiências de gerenciamento de identidade em seus aplicativos Web para o Microsoft Entra ID.
A política personalizada do Azure AD B2C fornece um perfil técnico do OpenID Connect, que você usa para fazer uma chamada para um ponto de extremidade seguro da Microsoft. Saiba mais sobre o perfil técnico do OpenID Connect.
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 Criar e ler uma conta de usuário 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 - Configurar o perfil técnico do OpenID Connect
Para configurar um perfil técnico do OpenID Connect, você precisa executar três etapas:
- Declare mais reivindicações.
- Registre aplicativos em seu portal do Azure.
- Finalmente, configure o próprio Perfil Técnico do OpenID Connect
Etapa 1.1 - Declarar mais reclamações
ContosoCustomPolicy.XML
No arquivo, localize a seção ClaimsSchema e, em seguida, adicione mais declarações usando o seguinte código:
<!--<ClaimsSchema>-->
...
<ClaimType Id="grant_type">
<DisplayName>grant_type</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="scope">
<DisplayName>scope</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="nca">
<DisplayName>nca</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="client_id">
<DisplayName>client_id</DisplayName>
<DataType>string</DataType>
<AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
<UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
</ClaimType>
<ClaimType Id="resource_id">
<DisplayName>resource_id</DisplayName>
<DataType>string</DataType>
<AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
<UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
</ClaimType>
<!--</ClaimsSchema>-->
Etapa 1.2 - Registrar aplicativos do Identity Experience Framework
O Azure AD B2C exige que você registre dois aplicativos que ele usa para se inscrever e entrar em usuários com contas locais: IdentityExperienceFramework, uma API da Web, e ProxyIdentityExperienceFramework, um aplicativo nativo com permissão delegada para o aplicativo IdentityExperienceFramework.
Se ainda não o fez, registe as seguintes candidaturas. Para automatizar o passo a passo abaixo, visite o aplicativo de configuração do IEF e siga as instruções:
Use as etapas em Registrar o aplicativo IdentityExperienceFramework para registrar o aplicativo Identity Experience Framework. Copie o ID do aplicativo (cliente), appID, para o registro do aplicativo Identity Experience Framework para uso na próxima etapa.
Use as etapas em Registrar o aplicativo ProxyIdentityExperienceFramework para registrar o aplicativo Proxy Identity Experience Framework. Copie a ID do aplicativo (cliente), proxyAppID, para o registro do aplicativo Proxy Identity Experience Framework para uso na próxima etapa.
Etapa 1.3 - Configurar o perfil técnico do OpenID Connect
ContosoCustomPolicy.XML
No arquivo, localize a seção ClaimsProviders e adicione um elemento Claims Provider que contém seu perfil técnico do OpenID Connect usando o seguinte código:
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<DisplayName>OpenID Connect Technical Profiles</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SignInUser">
<DisplayName>Sign in with Local Account</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We didn't find this account</Item>
<Item Key="UserMessageIfInvalidPassword">Your password or username is incorrect</Item>
<Item Key="UserMessageIfOldPasswordUsed">You've used an old password.</Item>
<Item Key="ProviderName">https://sts.windows.net/</Item>
<Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
<Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
<Item Key="response_types">id_token</Item>
<Item Key="response_mode">query</Item>
<Item Key="scope">email openid</Item>
<!-- Policy Engine Clients -->
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="client_id">proxyAppID</Item>
<Item Key="IdTokenAudience">appID</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="username" Required="true" />
<InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" Required="true" />
<InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
<InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
<InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
<InputClaim ClaimTypeReferenceId="client_id" DefaultValue="proxyAppID" />
<InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="appID" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
</OutputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Substitua ambas as instâncias de:
appID com ID de aplicativo (cliente) do aplicativo Identity Experience Framework copiado na etapa 1.2.
proxyAppID com ID de aplicativo (cliente) do aplicativo Proxy Identity Experience Framework copiado na etapa 1.2.
Etapa 2 - Configurar a interface do usuário de entrada
Quando a política é executada, o usuário precisa ver uma interface de usuário que permita entrar. A interface do usuário também tem uma opção para se inscrever se eles ainda não tiverem uma conta. Para fazer isso, você precisa executar duas etapas:
- Configure um perfil técnico autodeclarado, que exibe o formulário de entrada para o usuário.
- Configure a definição de conteúdo para a interface do usuário de entrada.
Etapa 2.1 - Configurar um perfil técnico da interface do usuário de entrada
No arquivo, localize o ContosoCustomPolicy.XML
SignInUser
perfil técnico e adicione um perfil técnico autodeclarado depois dele usando o seguinte código:
<TechnicalProfile Id="UserSignInCollector">
<DisplayName>Local Account Signin</DisplayName>
<Protocol Name="Proprietary"
Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="setting.operatingMode">Email</Item>
<Item Key="SignUpTarget">AccountTypeInputCollectorClaimsExchange</Item>
</Metadata>
<DisplayClaims>
<DisplayClaim ClaimTypeReferenceId="email" Required="true" />
<DisplayClaim ClaimTypeReferenceId="password" Required="true" />
</DisplayClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="password" />
<OutputClaim ClaimTypeReferenceId="objectId" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="SignInUser" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
Adicionámos um Perfil Técnico SelfAsserted, UserSignInCollector, que apresenta o formulário de início de sessão ao utilizador. Configuramos o perfil técnico para coletar o endereço de e-mail do usuário como seu nome de entrada, conforme indicado nos setting.operatingMode
metadados. O formulário de login inclui um link de inscrição, que leva o usuário a um formulário de inscrição, conforme indicado pelos SignUpTarget
metadados. Você verá como configuramos o SignUpWithLogonEmailExchangeClaimsExchange
nas etapas de orquestração.
Além disso, adicionamos o perfil técnico SignInUser OpenID Connect como um ValidationTechnicalProfile. Assim, o perfil técnico SignInUser é executado quando o usuário seleciona o botão Entrar (veja a captura de tela na etapa 5).
Na próxima etapa (etapa 2.2), configuramos uma definição de conteúdo que usaremos neste Perfil Técnico Autodeclarado.
Etapa 2.2 - Configurar a definição de conteúdo da interface de entrada
ContosoCustomPolicy.XML
No arquivo, localize a seção ContentDefinitions e, em seguida, entre na definição de conteúdo usando o seguinte código:
<!--<ContentDefinitions>-->
...
<ContentDefinition Id="SignupOrSigninContentDefinition">
<LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.7</DataUri>
<Metadata>
<Item Key="DisplayName">Signin and Signup</Item>
</Metadata>
</ContentDefinition>
<!--</ContentDefinitions>-->
Configuramos uma definição de conteúdo para o nosso perfil técnico autoafirmado, SignupOrSigninContentDefinition
. Podemos especificá-lo no perfil técnico usando o elemento de metadados ou especificá-lo quando referenciarmos o perfil técnico nas etapas de orquestração. Anteriormente, aprendemos como especificar uma definição de conteúdo diretamente no perfil técnico autodeclarado, portanto, neste artigo, aprenderemos como especificá-la quando fizermos referência ao perfil técnico nas etapas de orquestração, etapa 3.
Etapa 3 - Atualizar as etapas de orquestração da jornada do usuário
ContosoCustomPolicy.XML
No arquivo, localize a jornada do usuário HelloWorldJourney e substitua toda a sua coleção de etapas de orquestração pelo seguinte código:
<!--<OrchestrationSteps>-->
...
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
<ClaimsProviderSelections>
<ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
</ClaimsProviderSelections>
<ClaimsExchanges>
<ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>accountType</Value>
<Value>company</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="4" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="5" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="6" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
<!--</OrchestrationSteps>-->
Nas etapas de orquestração de dois a cinco, usamos pré-condições para determinar se a etapa de orquestração deve ser executada. Precisamos determinar se o usuário está entrando ou se inscrevendo.
Quando a política personalizada é executada:
Etapa 1 da orquestração - Exibe a página de login, para que o usuário possa entrar ou selecionar o link Inscreva-se agora . Observe que especificamos a definição de conteúdo que o perfil técnico autodeclarado UserSignInCollector usa para exibir o formulário de entrada.
Etapa de orquestração 2 - Esta etapa é executada se o usuário se inscrever (
objectId
não existe), portanto, exibimos o formulário de seleção de tipo de conta invocando o perfil técnico autodeclarado AccountTypeInputCollector.Etapa de orquestração 3 - Esta etapa é executada se o usuário se inscrever (
objectId
não existe) e se um usuário não selecionar uma empresaaccountType
. Portanto, temos que pedir ao usuário para inserir umaccessCode
invocando o perfil técnico autoafirmado AccessCodeInputCollector .Etapa de orquestração 4 - Esta etapa é executada se o usuário se inscrever (objectId não existe), portanto, exibimos o formulário de inscrição invocando o perfil técnico autodeclarado UserInformationCollector .
Etapa 5 da orquestração - Esta etapa lê as informações da conta do Microsoft Entra ID (invocamos
AAD-UserRead
o perfil técnico do Microsoft Entra ID), portanto, ele é executado se um usuário se inscrever ou entrar.Etapa de orquestração 6 - Esta etapa invoca o perfil técnico UserInputMessageClaimGenerator para montar a mensagem de saudação do usuário.
Etapa de orquestração 7 - Finalmente, a etapa 8 monta e retorna o token JWT no final da execução da política.
Passo 4 - 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 5 - Política de teste
Siga as etapas em Testar a política personalizada para testar sua política personalizada. Quando a política for executada, você verá uma interface semelhante à captura de tela abaixo:
Pode iniciar sessão introduzindo o Endereço de E-mail e a Palavra-passe de uma conta existente. Se você ainda não tiver uma conta, precisará selecionar o link Inscrever-se agora para criar uma nova conta de usuário.
Próximos passos
Saiba como configurar um fluxo de inscrição e entrada com uma conta social usando a política personalizada do Azure Ative Directory B2C.
Saiba como remover o link de inscrição, para que os usuários possam apenas entrar.
Saiba mais sobre o perfil técnico do OpenID Connect.