Compartilhar via

Prova de conceito da estrutura de identidade global do Azure Active Directory B2C para configuração baseada em região

  • Artigo

A seção a seguir descreve como criar implementações de prova de conceito para orquestração baseada em região. As políticas personalizadas concluídas do Azure AD B2C (Azure Active Directory B2C) podem ser encontradas aqui.

Abordagem baseada em região

Cada locatário regional do Azure AD B2C exigirá uma política personalizada do Azure AD B2C, que contém os seguintes recursos:

Percurso de inscrição:

  • Exibir uma tela para coletar o nome de usuário, a senha e outros atributos do usuário
  • Impedir a inscrição se o usuário já existir consultando a tabela de mapeamento usuário-região
  • Gravar o perfil do usuário no locatário local
  • Gravar o mapeamento nome de usuário-região do usuário em uma tabela de mapeamento
  • Emitir um token para o aplicativo

Percurso de entrada:

  • Exibir tela de nome de usuário e senha
  • Executar uma pesquisa do nome de usuário e retornar sua região
  • Executar uma verificação de credencial local ou uma verificação de credencial entre locatários
  • Ler o perfil do usuário do locatário local ou por meio de uma chamada entre locatários
  • Emitir um token para o aplicativo

Percurso de redefinição de senha:

  • Exibir uma tela para validar o email dos usuários por OTP de email
  • Executar uma pesquisa do nome de usuário e retornar sua região
  • Exibir uma tela para capturar a nova senha
  • Gravar a nova senha no locatário local ou por meio de uma chamada entre locatários
  • Emitir um token para o aplicativo

O diagrama de bloco a seguir mostra a prova de conceito. As diretrizes mostrarão como configurar os locatários do Azure AD B2C. A camada de API externa e a tabela de pesquisa distribuída geográfica não estão incluídas como parte deste guia.

Captura de tela que mostra o diagrama de bloco da abordagem baseada em região

Pré-requisitos

  1. Crie um locatário para cada região a que sua empresa precise dar suporte. Você precisará de pelo menos dois locatários para essa prova de conceito.

  2. Implante políticas personalizadas em seus locatários.

Preparar camada de armazenamento

Você precisará de uma camada de armazenamento, que pode armazenar email, objectId e região dos usuários. Isso permitirá que você acompanhe e confira onde o usuário se inscreveu. Você pode usar uma tabela do Armazenamento do Azure para persistir esses dados.

Preparar a camada de API

Há várias APIs usadas como parte da prova de conceito para demonstrar a abordagem baseada em região.

Verificar se o usuário já existe

Uma API é usada durante a inscrição para determinar se o usuário já existe em alguma região.

A solicitação será a seguinte:

POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json

{
  email: bob@contoso.com
}

  • A resposta deverá ser um HTTP 200 se o usuário não existir.

  • A resposta deverá ser HTTP 409 se o usuário existir.

Registrar o mapeamento usuários-região

Uma API é usada durante a inscrição para registrar em qual região o usuário se inscreveu.

A solicitação será a seguinte:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

  • A resposta deverá ser um HTTP 200 se o usuário existir.

  • A resposta deverá ser HTTP 409 se o usuário existir.

Retornar a região em que o usuário existe

Uma API é usada durante a entrada para determinar em qual região o usuário se inscreveu. Isso indica se uma autenticação entre locatários precisa ser executada.

A solicitação será a seguinte:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

A resposta deve ser um HTTP 200 com a região e o objectId registrados dos usuários.

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "region": "APAC"  
}

A API deverá responder com um HTTP 409 se o usuário não existir ou se encontrar um erro.

Gravar senha entre locatários

Uma API é usada durante o fluxo de redefinição de senha para gravar a nova senha dos usuários em uma região diferente de onde eles redefiniram a senha.

A solicitação será a seguinte:

POST /writePasswordCrossTenant HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "password": "some!strong123STRING"
}

A resposta deverá ser um HTTP 200 se o processo for bem-sucedido ou HTTP 409 se houver um erro.

Configuração do Azure AD B2C baseada em região

As seções a seguir preparam o locatário do Azure AD B2C para acompanhar a região em que o usuário se inscreveu e executar autenticações entre locatários ou redefinições de senha, se necessário.

Configuração de política de inscrição personalizada

Durante a inscrição, precisamos ter certeza de que o usuário não existe em nenhum outro locatário e gravar o mapeamento usuário-região dos usuários em uma tabela externa.

Modifique o perfil técnico LocalAccountSignUpWithLogonEmail no pacote inicial do Azure AD B2C da seguinte maneira:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
...
  <ValidationTechnicalProfiles>            
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-doesUserExistInLookupTable" />        
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
    <ValidationTechnicalProfile ReferenceId="REST-writeUserToRegionMapping" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

O ValidationTechnicalProfiles executará a seguinte lógica:

  1. Obtenha um token para chamar seus pontos de extremidade de API protegidos usando o perfil técnico REST-getTokenforExternalApiCalls.

    • Siga a documentação aqui para obter e proteger sua API usando um token de portador do Microsoft Entra.

  2. Verifique se o usuário já existe no mapeamento usuário-região por meio do ponto de extremidade da API REST externo protegido:

    • Essa chamada à API é feita antes de todas as inscrições; ela é essencial para garantir que a API terá o balanceamento de carga, a resiliência e os mecanismos de failover para atender aos requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para consultar um mapeamento usuário-região por meio de uma API REST externa é o seguinte:

      <TechnicalProfile Id="REST-doesUserExistInLookupTable ">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/doesUserExistInLookupTable</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

    • Essa API deverá responder com HTTP 409 se o usuário existir, com a mensagem de erro apropriada a ser exibida na tela. Caso contrário, responder com um HTTP 200 se o usuário não existir.

  3. Gravar o mapeamento usuário-região por meio do ponto de extremidade da API REST externa protegida

    • Essa chamada à API é feita antes de todas as inscrições; ela é essencial para garantir que a API terá o balanceamento de carga, a resiliência e os mecanismos de failover para atender aos requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para gravar o mapeamento usuário-região por meio de uma API REST externa é o seguinte:

    <TechnicalProfile Id="REST-writeUserToRegionMapping">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/writeUserToRegionMapping</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  <InputClaim ClaimTypeReferenceId="region" DefaultValue="EMEA" />
  <InputClaim ClaimTypeReferenceId="objectId" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
``` 

Configuração de política de entrada personalizada

Durante a entrada, devemos determinar o local do perfil dos usuários e autenticá-los no locatário Azure AD B2C em que reside o perfil.

Modifique o perfil técnico SelfAsserted-LocalAccountSignin-Email no pacote inicial do Azure AD B2C para executar a pesquisa de região do usuário e execute a autenticação entre locatários quando o usuário for de uma região diferente da do locatário que ele atingiu. Atualize o ValidationTechnicalProfiles como:

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="login-NonInteractive">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
     <ValidationTechnicalProfile ReferenceId="REST-login-NonInteractive-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-fetchUserProfile-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

O ValidationTechnicalProfiles executará a seguinte lógica quando o usuário enviar suas credenciais:

  1. Obtenha um token para chamar seus pontos de extremidade de API protegidos usando o perfil técnico REST-getTokenforExternalApiCalls.

    • Siga a documentação aqui para obter e proteger sua API usando um token de portador do Microsoft Entra.

  2. Pesquisar o mapeamento usuário-região por meio do ponto de extremidade da API REST externa protegida

    • Essa chamada à API é feita antes de todas as inscrições; ela é essencial para garantir que a API terá o balanceamento de carga, a resiliência e os mecanismos de failover para atender aos requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para consultar um mapeamento usuário-região por meio de uma API REST externa é o seguinte:

      <TechnicalProfile Id="REST-regionLookup">
  <DisplayName>User to Region lookup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/userToRegionLookup</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="AllowInsecureAuthInProduction">false</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="user_region" PartnerClaimType="region" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

  3. Execute a autenticação de conta local por meio do perfil técnico login-NonInteractive para usuários que se inscreveram nesse locatário. Esse é o perfil técnico padrão encontrado no pacote inicial do Azure AD B2C.

  4. Condicionalmente, execute uma autenticação entre locatários por meio dos perfis técnicos REST-login-NonInteractive-[region] para cada região respectiva.

    • Um token da API do MS Graph será obtido do locatário inicial dos usuários. Crie um Registro de Aplicativo de Aplicativo Nativo em cada locatário regional com permissões da API do MS Graph para a permissão delegada user.read.

    • Um exemplo de um perfil técnico para fazer o mapeamento usuário-região por meio de uma API REST externa é o seguinte:

      <TechnicalProfile Id="REST-login-NonInteractive-APAC">
  <DisplayName>non interactive authentication to APAC</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/yourAPACb2ctenant.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">None</Item>
    <Item Key="SendClaimsIn">Form</Item>
    <Item Key="AllowInsecureAuthInProduction">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="apac_client_id" PartnerClaimType="client_id" DefaultValue="00001111-aaaa-2222-bbbb-3333cccc4444" />
    <InputClaim ClaimTypeReferenceId="ropc_grant_type" PartnerClaimType="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" />
    <InputClaim ClaimTypeReferenceId="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

    • Substitua <yourb2ctenant> no ServiceUrl pelo locatário que você precisa direcionar para autenticação.

    • Use o registro de aplicativo ApplicationId para preencher o DefaultValue da declaração de entrada apac_client_id.

  5. Condicionalmente, busque o perfil do usuário usando uma chamada à API REST entre locatários por meio dos perfis técnicos REST-fetchUserProfile-[region] para cada região respectiva.

    • Um exemplo de perfil técnico para ler o perfil do usuário por meio da API do MS Graph é o seguinte:

      <TechnicalProfile Id="REST-fetchUserProfile-APAC">
  <DisplayName>fetch user profile cross tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://graph.microsoft.com/beta/me</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">graph_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="graph_bearerToken" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="id" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surName" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Configuração de política de redefinição de senha personalizada

Durante a redefinição de senha, devemos determinar o local do perfil dos usuários e atualizar a senha no locatário do Azure AD B2C em que reside o perfil do usuário.

Modifique o perfil técnico LocalAccountSignUpWithLogonEmail no pacote inicial do Azure AD B2C para executar a pesquisa de região do usuário e atualize a senha no respectivo locatário. Atualize o ValidationTechnicalProfiles como:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
  <OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" DefaultValue="EMEA"/>
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

O ValidationTechnicalProfiles executará a seguinte lógica quando o usuário enviar um email verificado para atualizar sua senha:

  1. Obter um token para chamar seus pontos de extremidade de API protegidos

  2. Pesquisar o mapeamento usuário-região por meio do ponto de extremidade da API REST externa protegida

    • Essa chamada à API é feita antes de todas as tentativas de redefinição de senha; ela é essencial para garantir que a API terá o balanceamento de carga, a resiliência e os mecanismos de failover para atender aos requisitos de tempo de atividade.

Modifique o perfil técnico LocalAccountWritePasswordUsingObjectId para gravar a nova senha no locatário local ou condicionalmente no locatário entre regiões.

<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
  ...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>EMEA</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-UserWritePasswordUsingObjectId-APAC">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>APAC</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
</TechnicalProfile>

O ValidationTechnicalProfiles executará a seguinte lógica quando o usuário enviar uma nova senha:

  1. Grave a nova senha dos usuários no diretório se o usuário existir no locatário do EMEA (este locatário).

  2. Condicionalmente, grave a nova senha no perfil do usuário na região em que ele reside, usando uma chamada à API REST.

    <TechnicalProfile Id="REST-UserWritePasswordUsingObjectId-APAC">
  <DisplayName>Write password to APAC tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/writePasswordCrossTenant</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="DebugMode">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="objectId" />
    <InputClaim ClaimTypeReferenceId="newPassword" />
  </InputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Próximas etapas