Compartilhar via

Configurar um fluxo de inscrição e entrada para uma conta local usando a política personalizada do Azure AD B2C

  • Artigo

No artigo Criar e ler uma conta de usuário usando a política personalizada do Azure AD 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 Active Directory B2C (AAD B2C) que permite ao usuário criar uma conta local no Azure AD B2C ou entrar em uma. Uma conta local se refere a uma conta criada em seu locatário do Azure AD B2C quando um usuário se inscreve em seu aplicativo.

Visão geral

O Azure AD B2C utiliza 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 juntamente com outras informações para um ponto de extremidade seguro, que determina se as credenciais são válidas ou não. Em poucas palavras, quando você utiliza a implementação do OpenID Connect do Azure AD B2C, você pode terceirizar a inscrição, a entrada e outras experiências de gerenciamento de identidade em seus aplicativos da Web para o Microsoft Entra ID.

A política personalizada do Azure AD B2C fornece um perfil técnico OpenID Connect, que você utiliza para fazer uma chamada para um ponto de extremidade seguro da Microsoft. Saiba mais sobre o perfil técnico OpenID Connect.

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 - Configurar o perfil técnico OpenID Connect

Para configurar um perfil técnico OpenID Connect, é necessário executar três etapas:

  • Declarar mais declarações.
  • Registre os aplicativos no seu portal do Azure.
  • Finalmente, configure o próprio Perfil Técnico OpenID Connect

Etapa 1.1 - Declarar mais declarações

No arquivo ContosoCustomPolicy.XML, localize a seção ClaimsSchema e adicione mais declarações usando o código a seguir:

    <!--<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 o registro de dois aplicativos que são usados para a inscrição e entrada de usuários com contas locais: IdentityExperienceFramework, uma API Web, e ProxyIdentityExperienceFramework, um aplicativo nativo com permissão delegada para o aplicativo IdentityExperienceFramework.

Se você ainda não tiver feito isso, registre os seguintes aplicativos. Para automatizar o passo a passo abaixo, visite o Aplicativo de Configuração do IEF e siga as instruções:

  1. Utilize as etapas em Registrar o aplicativo IdentityExperienceFramework para registrar o aplicativo Identity Experience Framework. Copie a ID do Aplicativo (cliente), appID, para o registro de aplicativo Identity Experience Framework para uso na próxima etapa.

  2. Siga 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 de aplicativo Proxy Identity Experience Framework para uso na próxima etapa.

Etapa 1.3 - Configurar o perfil técnico OpenID Connect

No arquivo ContosoCustomPolicy.XML, localize a seção ClaimsProviders e, em seguida, adicione um elemento Provedor de Declarações que mantenha seu Perfil Técnico 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 a ID do Aplicativo (cliente) do aplicativo Identity Experience Framework que você copiou na etapa 1.2.

  • proxyAppID com a ID do Aplicativo (cliente) do aplicativo Proxy Identity Experience Framework que você copiou na etapa 1.2.

Etapa 2 - Configurar a interface de entrada do usuário

Quando a política é executada, o usuário precisa ver uma interface de usuário que permita que ele entre. A interface do usuário também tem a opção de 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 exiba o formulário de entrada para o usuário.
  • Configurar a definição de conteúdo da interface do usuário de entrada.

Etapa 2.1 - Configurar um perfil técnico para a interface de entrada do usuário

No arquivo ContosoCustomPolicy.XML, localize o perfil técnico SignInUser e adicione um Perfil Técnico SelfAsserted depois dele usando o código a seguir:

    <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>

Adicionamos um Perfil Técnico SelfAsserted, UserSignInCollector, que exibe o formulário de entrada para o usuário. Configuramos o perfil técnico para coletar o de email do usuário como nome de entrada, conforme indicado nos metadados setting.operatingMode. O formulário de entrada inclui um link de inscrição, que leva o usuário para um formulário de inscrição, conforme indicado pelos metadados SignUpTarget. 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 (consulte a captura de tela na etapa 5).

Na próxima etapa (etapa 2.2), configuraremos uma definição de conteúdo que usaremos neste Perfil Técnico SelfAsserted.

Etapa 2.2 - Configurar a definição do conteúdo da interface de entrada

No arquivo ContosoCustomPolicy.XML, localize a seção ContentDefinitions e, em seguida, entre em Content Definition usando o código a seguir:

    <!--<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 autodeclarado, SignupOrSigninContentDefinition. Podemos especificá-lo no perfil técnico utilizando o elemento de metadados ou especificá-lo quando referenciarmos o perfil técnico nas etapas de orquestração. Anteriormente, aprendemos a especificar uma definição de conteúdo diretamente no perfil técnico autodeclarado, portanto, neste artigo, aprenderemos como especificá-la quando referenciarmos o perfil técnico nas etapas de orquestração, etapa 3 .

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

No arquivo ContosoCustomPolicy.XML, localize o percurso do usuário HelloWorldJourney e substitua todas as suas coleções de etapas de orquestração pelo código a seguir:

    <!--<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 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 de Orquestração 1: exibe a página de entrada, para que o usuário possa entrar ou selecionar o link Inscrever-se agora. Observe que especificamos a definição de conteúdo que o perfil técnico autodeclarado UserSignInCollector utiliza para exibir o formulário de entrada.

  • Etapa de Orquestração 2: essa etapa será 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 6 de Orquestração 3: essa etapa será executada se o usuário se inscrever (objectId não existe) e se um usuário não selecionar uma empresa accountType. Portanto, temos que pedir ao usuário para inserir um accessCode invocando o perfil técnico autodeclarado AccessCodeInputCollector.

  • Etapa de Orquestração 4: essa etapa será 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 6 de Orquestração 5: essa etapa lê as informações da conta do Microsoft Entra ID (invocamos o perfil técnico AAD-UserRead do Microsoft Entra ID), para que seja executado independentemente de um usuário se inscrever ou entrar.

  • Etapa 6 de Orquestração: essa 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.

Etapa 4 - Política de upload

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 5 - Política de teste

Siga as etapas em Testar a política personalizada para testar sua política personalizada. Após a política ser executada, você verá uma interface semelhante à captura de tela abaixo:

screenshot of sign-up or sign-in interface.

Você pode entrar inserindo o Endereço de Email e a Senha de uma conta existente. Se ainda não tiver uma conta, precisará selecionar o link Inscrever-se agora para criar uma nova conta de usuário.

Próximas etapas