Criar uma solução de identidade global com uma abordagem baseada na região

Neste artigo, descrevemos os cenários da abordagem de conceção baseada na região. Antes de começar a criar, recomenda-se que reveja as capacidades e o desempenho da abordagem de estrutura baseada em funil e na região.

A conta de designs para:

• Inscrição e início de sessão na Conta Local
• Inscrição e início de sessão da conta federada
• Autenticação de contas locais para utilizadores que iniciam sessão fora da respetiva região registada, suportada pela autenticação baseada em API entre inquilinos.
• Autenticação de contas federadas para utilizadores que iniciam sessão fora da respetiva região registada, suportada pela pesquisa baseada em API entre inquilinos
• Impede a inscrição de várias regiões diferentes
• As aplicações em cada região têm um conjunto de pontos finais com os quais ligar

Autenticações de conta local

Os seguintes casos de utilização são típicos num ambiente global Azure AD B2C. Os casos de utilização da conta local também abrangem as contas em que o utilizador viaja. Cada um fornece um diagrama e passos de fluxo de trabalho para cada caso de utilização.

Inscrição de utilizador local

Este caso de utilização demonstra como um utilizador do respetivo país/região de origem efetua uma inscrição com um Azure AD Conta Local B2C.

1. O utilizador da Europa, Médio Oriente e África (EMEA) tenta inscrever-se no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador tenta inscrever-se. O processo de inscrição verifica a tabela de referência global para determinar se o utilizador existe em qualquer um dos inquilinos regionais Azure AD B2C.

4. O utilizador não se encontra na tabela de referência global. A conta do utilizador é escrita no Azure AD B2C e é criado um registo na tabela de referência global para controlar a região na qual o utilizador se inscreveu.

5. O inquilino regional emite um token de volta para a aplicação.

O utilizador local existente tenta inscrever-se

Este caso de utilização demonstra como um utilizador que volte a registar o mesmo e-mail a partir do seu próprio país/região, ou de uma região diferente, está bloqueado.

1. O utilizador da EMEA tenta inscrever-se no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador tenta inscrever-se. O processo de inscrição verifica a tabela de referência global para determinar se o utilizador existe em qualquer um dos inquilinos regionais Azure AD B2C.

4. O e-mail do utilizador encontra-se na tabela de referência global, indicando que o utilizador registou este e-mail na solução em algum momento anterior.

5. É apresentado um erro ao utilizador, indicando que a conta existe.

Início de sessão do utilizador local

Este caso de utilização demonstra como um utilizador do respetivo país/região de origem efetua um início de sessão com um Azure AD conta local B2C.

1. O utilizador da EMEA tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador introduz as respetivas credenciais no inquilino regional.

4. O inquilino regional emite um token de volta para a aplicação.

5. O utilizador tem sessão iniciada na aplicação.

Início de sessão de utilizador itinerante

Este caso de utilização demonstra como um utilizador pode viajar entre regiões e manter o respetivo perfil de utilizador e credenciais armazenadas no respetivo inquilino regional, respetivamente, para a inscrição.

1. O utilizador do América do Norte (NOAM) tenta iniciar sessão no myapp.fr, uma vez que estão de férias em França. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador introduz as respetivas credenciais no inquilino regional.

4. O inquilino regional efetua uma pesquisa na tabela de referência global, uma vez que o e-mail do utilizador não foi encontrado no diretório EMEA Azure AD B2C.

5. O e-mail do utilizador está localizado para ter sido inscrito no inquilino NOAM Azure AD B2C.

6. O inquilino do EMEA Azure AD B2C executa um fluxo ROPC Microsoft Entra em relação ao inquilino NOAM Azure AD B2C para verificar as credenciais.

   Nota

   Esta chamada também irá obter um token para o utilizador efetuar uma chamada Graph API. O inquilino do EMEA Azure AD B2C efetua uma chamada de Graph API para o inquilino NOAM Azure AD B2C para obter o perfil do utilizador. Esta chamada é autenticada pelo token de acesso para Graph API adquiridos no último passo.

7. O inquilino regional emite uma aplicação de back-back de token.

O utilizador local esqueceu-se da palavra-passe

Este caso de utilização demonstra como um utilizador pode repor a palavra-passe quando está no seu país/região.

1. O utilizador da EMEA tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino do EMEA Azure AD B2C e seleciona esqueceu-se da palavra-passe. O utilizador introduz e verifica o respetivo e-mail.

3. Email pesquisa é realizada para determinar em que inquilino regional o utilizador existe.

4. O utilizador fornece uma nova palavra-passe.

5. A nova palavra-passe é escrita no inquilino em EMEA Azure AD B2C.

6. O inquilino regional emite um token de volta para a aplicação.

Utilizador itinerante esqueceu-se da palavra-passe

Este caso de utilização demonstra como um utilizador pode repor a palavra-passe quando está a viajar para fora da região na qual registou a conta.

1. O utilizador da NOAM tenta iniciar sessão no myapp.fr, uma vez que está de férias em França. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino do EMEA Azure AD B2C e seleciona esqueceu-se da palavra-passe. O utilizador introduz e verifica o respetivo e-mail.

3. Email pesquisa é realizada para determinar em que inquilino regional o utilizador existe.

4. Verificou-se que o e-mail existe no inquilino noAM Azure AD B2C. O utilizador fornece uma nova palavra-passe.

5. A nova palavra-passe é escrita no inquilino NOAM Azure AD B2C através de uma chamada de Graph API.

6. O inquilino regional emite um token de volta para a aplicação.

Alteração da palavra-passe do utilizador local

Este caso de utilização demonstra como um utilizador pode alterar a palavra-passe depois de ter iniciado sessão na região na qual registou a conta.

1. O utilizador das tentativas do EMEA seleciona alterar a palavra-passe depois de iniciar sessão no myapp.fr.

2. O utilizador chega ao inquilino do EMEA Azure AD B2C e o conjunto de cookies Single-Sign On (SSO) permite que o utilizador altere a palavra-passe imediatamente.

3. A nova palavra-passe é escrita na conta de utilizador no inquilino em EMEA Azure AD B2C.

4. O inquilino regional emite um token de volta para a aplicação.

Alteração da palavra-passe do utilizador itinerante

Este caso de utilização demonstra como um utilizador pode alterar a palavra-passe depois de iniciar sessão, longe da região na qual registou a conta.

1. Os utilizadores das tentativas NOAM selecionam alterar palavra-passe após iniciar sessão no myapp.fr.

2. O utilizador chega ao inquilino do EMEA Azure AD B2C e o conjunto de cookies SSO permite que o utilizador altere a palavra-passe imediatamente.

3. O e-mail dos utilizadores encontra-se no inquilino NOAM depois de verificar a tabela de referência global.

4. A nova palavra-passe é escrita na conta de utilizador no inquilino NOAM Azure AD B2C por MS Graph API chamada.

5. O inquilino regional emite um token de volta para a aplicação.

Autenticações do Fornecedor de Identidade Federado

Os seguintes casos de utilização mostram exemplos de utilização de identidades federadas para se inscrever ou iniciar sessão como um cliente Azure AD B2C.

Inscrição de ID federado local

Este caso de utilização demonstra como um utilizador da região local se inscreve no serviço com um ID federado.

1. O utilizador da EMEA tenta inscrever-se no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador seleciona para iniciar sessão com um fornecedor de identidade federado.

4. Efetue uma pesquisa na tabela de referência global.

   • Se a ligação da conta estiver no âmbito: continue se o identificador do IdP federado nem o e-mail devolvido do IdP federado não existirem na tabela de referência.

   • Se a ligação da conta não estiver no âmbito: continue se o identificador IdP federado que voltou do IdP federado não existir na tabela de referência.

5. Escreva a conta de utilizadores no inquilino emEA Azure AD B2C.

6. O inquilino regional emite um token de volta para a aplicação.

Início de sessão de utilizador federado local

Este caso de utilização demonstra como um utilizador da respetiva região local inicia sessão no serviço com um ID federado.

1. O utilizador da EMEA tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador seleciona para iniciar sessão com um fornecedor de identidade federado.

4. Efetue uma pesquisa na tabela de referência global e confirme que o ID federado do utilizador está registado no EMEA.

5. O inquilino regional emite um token de volta para a aplicação.

Início de sessão de utilizador federado em viagem

Este cenário demonstra como um utilizador localizado longe da região na qual se inscreveu e efetua um início de sessão no serviço com um IdP federado.

1. O utilizador do NOAM tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador seleciona para iniciar sessão com um fornecedor de identidade federado.

   Nota

   Utilize o mesmo ID da Aplicação do Registo de Aplicações no IdP de Rede Social em todos os inquilinos regionais Azure AD B2C. Isto garante que o ID que regressa do IdP Social é sempre o mesmo.

4. Efetue uma pesquisa na tabela de referência global e determine que o ID federado do utilizador está registado no NOAM.

5. Leia os dados da conta a partir do inquilino NOAM Azure AD B2C com o MS Graph API.

6. O inquilino regional emite um token de volta para a aplicação.

Ligação de conta com critérios correspondentes

Este cenário demonstra como os utilizadores poderão efetuar a ligação de conta quando um critério correspondente for satisfeito (normalmente, endereço de e-mail).

1. O utilizador da EMEA tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador seleciona para iniciar sessão com um fornecedor de identidade federado/IdP social.

4. É efetuada uma pesquisa na tabela de pesquisa global do ID devolvido do IdP federado.

5. Quando o ID não existe, mas o e-mail do IdP federado existe no EMEA Azure AD B2C, é um cenário de ligação de conta.

6. Leia o utilizador a partir do diretório e determine que métodos de autenticação estão ativados na conta. Apresentar um ecrã para o utilizador iniciar sessão com um método de autenticação existente nesta conta.

7. Assim que o utilizador provar que é o proprietário da conta no Azure AD B2C, adicione o novo ID de rede social à conta existente e adicione o ID de rede social à conta na tabela de referência global.

8. O inquilino regional emite um token de volta para a aplicação.

Ligação da conta de utilizador itinerante com critérios correspondentes

Este cenário demonstra como os utilizadores poderão efetuar a ligação da conta quando estiverem longe da região.

1. O utilizador do NOAM tenta iniciar sessão no myapp.fr. Se o utilizador não estiver a ser enviado para o nome do anfitrião local, o gestor de tráfego irá impor um redirecionamento.

2. O utilizador chega ao inquilino da EMEA.

3. O utilizador seleciona para iniciar sessão com um fornecedor de identidade federado/IdP social.

4. É efetuada uma pesquisa na tabela de pesquisa global do ID devolvido do IdP federado.

5. Quando o ID não existe e o e-mail do IdP federado existe noutra região, é um cenário de ligação de conta de utilizador itinerante.

6. Crie uma ligação de id_token_hint que associe as afirmações atualmente recolhidas aos utilizadores. Bootstrap a journey into the NOAM Azure AD B2C tenant using federation. O utilizador irá provar que é o proprietário da conta através do inquilino NOAM Azure AD B2C.

   Nota

   Este método é utilizado para reutilizar a lógica de ligação da conta existente no inquilino principal e reduzir as chamadas à API externa para manipular a coleção de identidades. Pode encontrar aqui um exemplo de política personalizada que utiliza id_token_hint.

7. Assim que o utilizador provar que é o proprietário da conta no Azure AD B2C, adicione o novo ID de rede social à conta existente ao efetuar uma chamada de Graph API para o inquilino noAM Azure AD B2C. Adicione o ID de rede social à conta na tabela de referência global.

8. O inquilino regional emite um token de volta para a aplicação.

Passos seguintes

• Azure AD soluções de identidade global B2C

• Criar uma solução de identidade global com uma abordagem baseada em funil

• Azure AD a prova de identidade global do B2C da configuração baseada na região do conceito

• Azure AD configuração baseada em funil da prova de identidade global B2C