Partilhar via

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

  • Artigo

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

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:

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

  2. 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 (objectIdnã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 empresa accountType. Portanto, temos que pedir ao usuário para inserir um accessCode 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:

screenshot of sign-up or sign-in interface.

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