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

Neste artigo, descrevemos os cenários para a abordagem de design baseada em região. Antes de começar a criar, é recomendável que você revise os recursos e o desempenho da abordagem de design baseada em funil e região.

Os designs consideram:

• Criar e entrar na conta local
• Criar e entrar na conta federada
• Autenticar contas locais para usuários que se conectam fora da região em que estão registrados, com suporte da autenticação baseada em API entre locatários.
• Autenticar contas federadas para usuários que se conectam fora da região em que estão registrados, com suporte da pesquisa baseada em API entre locatários
• Impede a criação de conta em várias regiões diferentes
• Os aplicativos em cada região têm um conjunto de pontos de extremidade para se conectar

Autenticações de conta local

Os casos de uso a seguir são típicos em um ambiente do Azure AD B2C global. Os casos de uso da conta local também abrangem contas para onde o usuário viaja. Cada uma fornece um diagrama e etapas de fluxo de trabalho para cada caso de uso.

Inscrição de usuário local

Esse caso de uso demonstra como um usuário de seu país/região de origem executa a criação de conta com uma conta local do Azure AD B2C.

1. Usuário da Europa, Oriente Médio e África (EMEA) tenta se criar conta no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário tenta criar conta. O processo de criação de conta verifica a tabela de pesquisa global para determinar se o usuário existe em um dos locatários regionais do Azure AD B2C.

4. O usuário não foi encontrado na tabela de pesquisa global. A conta do usuário é gravada no Azure AD B2C e um registro é criado na tabela de pesquisa global para rastrear a região na qual o usuário se inscreveu.

5. O locatário regional emite um token de volta para o aplicativo.

Tentativas de criação de conta do usuário local existente

Esse caso de uso demonstra como um usuário que registra novamente o mesmo email em seu país, ou em uma região diferente, é bloqueado.

1. O usuário da EMEA tenta se inscrever no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário tenta criar conta. O processo de criação de conta verifica a tabela de pesquisa global para determinar se o usuário existe em um dos locatários regionais do Azure AD B2C.

4. O email do usuário é encontrado na tabela de pesquisa global, indicando que o usuário registrou esse email na solução em algum momento anterior.

5. O usuário recebe um erro, indicando que sua conta existe.

Credenciais de usuário local

Esse caso de uso demonstra como um usuário de seu país/região de origem executa uma entrada com uma conta local do Azure AD B2C.

1. O usuário da EMEA tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário insere suas credenciais no locatário regional.

4. O locatário regional emite um token de volta para o aplicativo.

5. O usuário está conectado ao aplicativo.

Entrada do usuário em viagem

Esse caso de uso demonstra como um usuário pode viajar por regiões e manter seu perfil de usuário e credenciais armazenadas no locatário regional, respectivo a sua inscrição.

1. O usuário da América do Norte (NOAM) tenta entrar no myapp.fr, pois está de férias na França. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário insere suas credenciais no locatário regional.

4. O locatário regional realiza uma pesquisa na tabela de pesquisa global, pois o email do usuário não foi encontrado no diretório AD B2C do Azure da EMEA.

5. O email do usuário foi localizado como tendo se inscrito no locatário do B2C do Azure AD da NOAM.

6. O locatário do Azure AD B2C da EMEA executa um fluxo de ROPC do Microsoft Entra no locatário do Azure AD B2C da NOAM para verificar as credenciais.

   Observação

   Essa chamada também buscará um token para o usuário executar uma chamada à API do Graph. O locatário do Azure AD B2C da EMEA executa uma chamada à API do Graph para o locatário do Azure AD B2C da NOAM para buscar o perfil do usuário. Essa chamada é autenticada pelo token de acesso para a API do Graph adquirido na última etapa.

7. O locatário regional emite um token de volta para o aplicativo.

O usuário local esqueceu a senha

Esse caso de uso demonstra como um usuário pode redefinir a senha quando está em seu país/região de origem.

1. O usuário da EMEA tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário do Azure AD B2C da EMEA e seleciona a senha esquecida. O usuário insere e verifica o email dele.

3. A pesquisa de email é executada para determinar em qual locatário regional o usuário existe.

4. O usuário fornece uma nova senha.

5. A nova senha é gravada no locatário do Azure AD B2C da EMEA.

6. O locatário regional emite um token de volta para o aplicativo.

Usuário em viagem esqueceu a senha

Esse caso de uso demonstra como um usuário pode redefinir sua senha quando estiver viajando e distante da região em que registrou sua conta.

1. O usuário da NOAM tenta entrar no myapp.fr, pois está de férias na França. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário do Azure AD B2C da EMEA e seleciona a senha esquecida. O usuário insere e verifica o email dele.

3. A pesquisa de email é executada para determinar em qual locatário regional o usuário existe.

4. O email é encontrado no locatário do Azure AD B2C da NOAM. O usuário fornece uma nova senha.

5. A nova senha é gravada no locatário do Azure AD B2C da NOAM por meio de uma chamada à API do Graph.

6. O locatário regional emite um token de volta para o aplicativo.

Alteração de senha do usuário local

Esse caso de uso demonstra como um usuário pode alterar sua senha depois de fazer logon na região em que registrou sua conta.

1. O usuário da EMEA tenta selecionar alterar senha depois de fazer logon no myapp.fr.

2. O usuário chega ao locatário do Azure AD B2C da EMEA e o conjunto de cookies de SSO (logon único) permite que o usuário altere a senha imediatamente.

3. A nova senha é gravada na conta de usuários no locatário do Azure AD B2C da EMEA.

4. O locatário regional emite um token de volta para o aplicativo.

Alteração de senha do usuário em viagem

Esse caso de uso demonstra como um usuário pode alterar sua senha depois de fazer logon distante da região em que registrou sua conta.

1. Os usuários da NOAM tentam selecionar alterar senha depois de fazer logon no myapp.fr.

2. O usuário chega ao locatário do Azure AD B2C da EMEA e o conjunto de cookies de SSO permite que o usuário altere a senha imediatamente.

3. O email dos usuários está no locatário da NOAM depois de verificar a tabela de pesquisa global.

4. A nova senha é gravada na conta de usuários no locatário do NOAM Azure AD B2C por meio da chamada à API do Graph.

5. O locatário regional emite um token de volta para o aplicativo.

Autenticações do provedor de identidade federado

Os casos de uso a seguir mostram exemplos de como usar identidades federadas para criar conta ou entrar como um cliente do Azure AD B2C.

Criar conta de ID federada local

Esse caso de uso demonstra como um usuário de sua região local cria conta no serviço usando uma ID federada.

1. O usuário da EMEA tenta se inscrever no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário seleciona entrar com um provedor de identidade federada.

4. Executar uma pesquisa na tabela de pesquisa global.

   • Se a vinculação de conta estiver no escopo: continue se o identificador do IdP federado e o email que voltou do IdP federada não existirem na tabela de pesquisa.

   • Se a vinculação de conta não estiver no escopo: continue se o identificador do IdP federada que voltou do IdP federada não existir na tabela de pesquisa.

5. Gravar a conta de usuários no locatário do Azure AD B2C da EMEA.

6. O locatário regional emite um token de volta para o aplicativo.

Entrada de usuário federado local

Esse caso de uso demonstra como um usuário de sua região local entra no serviço usando uma ID federada.

1. O usuário da EMEA tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário seleciona entrar com um provedor de identidade federada.

4. Execute uma pesquisa na tabela de pesquisa global e confirme se a ID federada do usuário está registrada na EMEA.

5. O locatário regional emite um token de volta para o aplicativo.

Entrada de usuário federado em viagem

Esse cenário demonstra como um usuário localizado distante da região da qual criou conta executa uma entrada no serviço usando um IdP federado.

1. O usuário da NOAM tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário seleciona entrar com um provedor de identidade federada.

   Observação

   Use a mesma ID do aplicativo do Registro de Aplicativo no IdP Social em todos os locatários regionais do Azure AD B2C. Isso garante que a ID que volta do IdP Social seja sempre a mesma.

4. Execute uma pesquisa na tabela de pesquisa global e determine se a ID federada do usuário está registrada na NOAM.

5. Leia os dados da conta do locatário do Azure AD B2C da NOAM usando a API do Graph da MS.

6. O locatário regional emite um token de volta para o aplicativo.

Vinculação de conta com critérios correspondentes

Esse cenário demonstra como os usuários podem executar a vinculação de conta quando um critério de correspondência é atendido (geralmente endereço de email).

1. O usuário da EMEA tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário seleciona entrar com um provedor de identidade federada/IdP social.

4. Uma pesquisa é executada na tabela de pesquisa global para a ID retornada do IdP federado.

5. Quando a ID não existir, mas o email do IdP federado existir no Azure AD B2C da EMEA, este é um cenário de vinculação de conta.

6. Leia o usuário do diretório e determine quais métodos de autenticação estão habilitados na conta. Apresente uma tela para o usuário entrar com um método de autenticação existente nessa conta.

7. Depois que o usuário provar que possui a conta no Azure AD B2C, adicione a nova ID social à conta existente e conta na tabela de pesquisa global.

8. O locatário regional emite um token de volta para o aplicativo.

Vinculação de conta de usuário em viagem com critérios correspondentes

Esse cenário demonstra como os usuários podem executar a vinculação de conta quando estão distantes da sua região.

1. O usuário da NOAM tenta entrar no myapp.fr. Se o usuário não for enviado para seu nome de host local, o gerenciador de tráfego irá impor um redirecionamento.

2. O usuário chega ao locatário da EMEA.

3. O usuário seleciona entrar com um provedor de identidade federada/IdP social.

4. Uma pesquisa é executada na tabela de pesquisa global para a ID retornada do IdP federado.

5. Se a ID não existir e o email do IdP federado existir em outra região, este é um cenário de vinculação de conta de usuário em viagem.

6. Crie uma vinculação de id_token_hint afirmando que os usuários coletaram declarações atualmente. Inicialize um percurso para o locatário do Azure AD B2C da NOAM usando federação. O usuário provará que possui a conta por meio do locatário do Azure AD B2C da NOAM.

   Observação

   Esse método é usado para reutilizar a lógica de vinculação de conta existente no locatário inicial e reduzir as chamadas à API externa para manipular a coleção de identidades. Um exemplo de política personalizada que utiliza id_token_hint pode ser encontrado aqui.

7. Depois que o usuário provar que possui a conta no Azure AD B2C, adicione a nova ID social à conta existente fazendo uma chamada à API do Graph para o locatário do Azure AD B2C da NOAM. Adicione a ID social à conta na tabela de pesquisa global.

8. O locatário regional emite um token de volta para o aplicativo.

Próximas etapas

• Soluções de identidade global do Azure AD B2C

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

• Configuração baseada em região da prova de conceito da identidade global do Azure AD B2C

• Configuração baseada em funil da prova de conceito da identidade global do Azure AD B2C