Partilhar via

Prova de conceito do framework de identidade global do Azure Active Directory B2C para a configuração baseada na região

  • Artigo

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

Abordagem baseada na região

Cada inquilino regional Azure AD B2C exigirá uma política personalizada Azure AD B2C, que contém as seguintes capacidades:

Percurso de inscrição:

  • Apresentar um ecrã para recolher o nome de utilizador, a palavra-passe e quaisquer outros atributos do utilizador
  • Impedir a inscrição se o utilizador já existir ao consultar a tabela de mapeamento user-region
  • Escrever o perfil de utilizador no inquilino local
  • Escrever o mapeamento de nome de utilizador para região dos utilizadores numa tabela de mapeamento
  • Emitir um token para a aplicação

Percurso de início de sessão:

  • Ecrã Apresentar nome de utilizador e palavra-passe
  • Efetuar uma pesquisa do nome de utilizador e devolver a região
  • Efetuar uma verificação de credenciais local ou uma verificação de credenciais entre inquilinos
  • Ler o perfil de utilizador a partir do inquilino local ou através de uma chamada entre inquilinos
  • Emitir um token para a aplicação

Percurso de reposição de palavra-passe:

  • Apresentar um ecrã para validar o e-mail dos utilizadores por e-mail OTP
  • Efetuar uma pesquisa do nome de utilizador e devolver a região
  • Apresentar um ecrã para capturar a nova palavra-passe
  • Escrever a nova palavra-passe no inquilino local ou através de uma chamada entre inquilinos
  • Emitir um token para a aplicação

O diagrama de blocos seguinte mostra a prova de conceito. A documentação de orientação mostrará como configurar os inquilinos do Azure AD B2C. A camada de API Externa e a tabela de referência distribuída geograficamente não estão incluídas como parte deste guia.

Captura de ecrã a mostrar o diagrama de bloco de abordagem baseado na região

Pré-requisitos

  1. Crie um inquilino por região que a sua empresa necessita para suportar. Precisará de, pelo menos, dois inquilinos para esta prova de conceito.

  2. Implemente políticas personalizadas nos inquilinos.

Preparar a camada de armazenamento

Precisará de uma camada de armazenamento, que pode armazenar o e-mail, o objectId e a região dos utilizadores. Isto irá permitir-lhe controlar e consultar onde o utilizador se inscreveu. Pode utilizar uma tabela de Armazenamento do Azure para manter estes dados.

Preparar a camada de API

Existem várias APIs utilizadas como parte da prova de conceito para demonstrar a abordagem baseada na região.

Verificar se o utilizador já existe

É utilizada uma API durante a inscrição para determinar se o utilizador já existe em qualquer região.

O pedido será o seguinte:

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

{
  email: bob@contoso.com
}

  • A resposta deve ser um HTTP 200 se o utilizador não existir.

  • A resposta deve ser HTTP 409 se o utilizador existir.

Registar o mapeamento da região dos utilizadores

É utilizada uma API durante a inscrição para registar em que região o utilizador se inscreveu.

O pedido será o 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 se o utilizador existir.

  • A resposta deve ser HTTP 409 se o utilizador existir.

Devolver em que região o utilizador existe

É utilizada uma API durante o início de sessão para determinar em que região o utilizador se tinha inscrito. Isto indica se é necessária uma autenticação entre inquilinos.

O pedido será o 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 registados pelos utilizadores.

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "region": "APAC"  
}

A API deve responder com um HTTP 409 se o utilizador não existir ou encontrar um erro.

Escrever palavra-passe entre inquilinos

É utilizada uma API durante o fluxo de reposição de palavra-passe para escrever a nova palavra-passe dos utilizadores numa região diferente à qual repõem a palavra-passe.

O pedido será o seguinte:

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

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "password": "some!strong123STRING"
}

A resposta deve ser um HTTP 200 se o processo for bem-sucedido ou HTTP 409 se ocorrer um erro.

Configuração de Azure AD B2C baseada na região

As secções seguintes preparam o inquilino do Azure AD B2C para controlar a região na qual o utilizador se inscreveu e executar autenticações entre inquilinos ou reposições de palavra-passe, se necessário.

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

Durante a inscrição, temos de verificar se o utilizador não existe em nenhum outro inquilino e escrever o mapeamento utilizador-região numa tabela externa.

Modifique o LocalAccountSignUpWithLogonEmail perfil técnico no Azure AD pacote de arranque B2C é o seguinte:

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

Os ValidationTechnicalProfiles executarão a seguinte lógica:

  1. Obtenha um token para chamar os pontos finais protegidos da API com o REST-getTokenforExternalApiCalls perfil técnico.

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

  2. Verifique se o utilizador já existe no mapeamento da região do utilizador através do ponto final da API REST externa protegida:

    • Esta chamada à API é feita antes de todas as inscrições, é fundamental garantir que esta API tem mecanismos de balanceamento de carga, resiliência e ativação pós-falha adequados para manter os requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para consultar um mapeamento de região de utilizador através 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>

    • Esta API deve responder com HTTP 409 se o utilizador existir, com a mensagem de erro adequada a ser apresentada no ecrã. Caso contrário, responda com um HTTP 200 se o utilizador não existir.

  3. Escrever o mapeamento da região do utilizador através do ponto final da API REST externa protegida

    • Esta chamada à API é feita antes de todas as inscrições, é fundamental garantir que esta API tem mecanismos de balanceamento de carga, resiliência e ativação pós-falha adequados para manter os requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para escrever o mapeamento de região do utilizador através 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>
``` 

Iniciar sessão na configuração da política personalizada

Durante o início de sessão, temos de determinar a localização do perfil dos utilizadores e autenticá-los no inquilino do Azure AD B2C onde reside o respetivo perfil.

Modifique o SelfAsserted-LocalAccountSignin-Email perfil técnico no Azure AD pacote de arranque B2C para efetuar a pesquisa de região do utilizador e efetue a autenticação entre inquilinos quando o utilizador for de uma região diferente da do inquilino a que chegou. 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>

Os ValidationTechnicalProfiles executarão a seguinte lógica quando o utilizador submeter as respetivas credenciais:

  1. Obtenha um token para chamar os pontos finais protegidos da API com o REST-getTokenforExternalApiCalls perfil técnico.

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

  2. Procurar o mapeamento da região do utilizador através do ponto final da API REST externa protegida

    • Esta chamada à API é feita antes de todas as inscrições, é fundamental garantir que esta API tem mecanismos de balanceamento de carga, resiliência e ativação pós-falha adequados para manter os requisitos de tempo de atividade.

    • Um exemplo de um perfil técnico para consultar um mapeamento de região de utilizador através 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. Efetue a autenticação de conta local através do login-NonInteractive perfil técnico dos utilizadores que se inscreveram neste inquilino. Este é o perfil técnico predefinido encontrado no Azure AD pacote de arranque B2C.

  4. Condicionalmente, execute uma autenticação entre inquilinos através dos REST-login-NonInteractive-[region] perfis técnicos de cada região.

    • Isto também obterá um token ms Graph API do inquilino raiz dos utilizadores. Registe um Registo de Aplicação Nativa em cada inquilino regional com permissões para o MS Graph API para a permissão user.readdelegada .

    • Um exemplo de um perfil técnico para efetuar o mapeamento de região de utilizador através 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="cf3f6898-9a79-426a-ba16-10e1a377c843" />
    <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 inquilino que tem de direcionar para autenticação.

    • Utilize o registo ApplicationId da aplicação para preencher o DefaultValue para a apac_client_id afirmação de entrada.

  5. Condicionalmente, obtenha o perfil de utilizador com uma chamada à API REST entre inquilinos através dos REST-fetchUserProfile-[region] perfis técnicos de cada região.

    • Um perfil técnico de exemplo para ler o perfil do utilizador através do MS Graph API é 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 da política personalizada de reposição de palavra-passe

Durante a reposição de palavra-passe, temos de determinar a localização do perfil dos utilizadores e atualizar a palavra-passe relativamente ao inquilino do Azure AD B2C onde se encontra o perfil de utilizador.

Modifique o LocalAccountSignUpWithLogonEmail perfil técnico no Azure AD pacote de arranque B2C para efetuar a pesquisa de utilizador-região e atualize a palavra-passe no respetivo inquilino. 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>

Os ValidationTechnicalProfiles executarão a seguinte lógica quando o utilizador submeter um e-mail verificado para atualizar a palavra-passe:

  1. Obter um token para chamar os pontos finais protegidos da API

  2. Procurar o mapeamento da região do utilizador através do ponto final da API REST externa protegida

    • Esta chamada à API é feita antes de todas as tentativas de reposição de palavra-passe, é fundamental garantir que esta API tem mecanismos de balanceamento de carga, resiliência e ativação pós-falha adequados para manter os requisitos de tempo de atividade.

Modifique o LocalAccountWritePasswordUsingObjectId perfil técnico para escrever a nova palavra-passe no inquilino local ou condicionalmente no inquilino 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>

Os ValidationTechnicalProfiles executarão a seguinte lógica quando o utilizador submeter uma nova palavra-passe:

  1. Escreva a nova palavra-passe dos utilizadores no diretório se o utilizador existir no inquilino do EMEA (este inquilino).

  2. Condicionalmente, escreva a nova palavra-passe no perfil de utilizador na região onde reside o perfil de utilizador, através de 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>

Passos seguintes