Partilhar via

Considerações sobre o uso do Azure Ative Directory B2C em uma arquitetura multilocatária

  • Artigo

O Azure Ative Directory (Azure AD) B2C fornece identidade de empresa para consumidor como um serviço. A identidade do usuário geralmente é uma das principais considerações quando você cria um aplicativo multilocatário. Sua solução de identidade serve como o gatekeeper para seu aplicativo, garantindo que seus locatários permaneçam dentro dos limites que você define para eles. Este artigo descreve considerações e abordagens para usar o Azure AD B2C em uma solução multilocatário.

Um dos motivos mais comuns para usar o Azure AD B2C é habilitar a federação de identidades para um aplicativo. A federação de identidades é o processo de estabelecer confiança entre dois provedores de identidade para que seus usuários possam entrar com uma conta pré-existente. Se você usar o Azure AD B2C, poderá implementar a federação de identidades para permitir que seus usuários entrem usando suas contas sociais ou corporativas. Se você usar a federação, os usuários não precisarão criar uma conta local separada específica para seu aplicativo.

Se você é novo neste tópico, recomendamos que revise os seguintes recursos:

Nota

Neste artigo, dois conceitos com nomes semelhantes são discutidos: locatários de aplicativos e locatários do Azure AD B2C.

O termo locatário do aplicativo é usado para se referir aos seus locatários, que podem ser seus clientes ou grupos de usuários.

O Azure AD B2C também usa o conceito de locatário em referência a diretórios individuais, e o termo multilocação é usado para se referir a interações entre vários locatários do Azure AD B2C. Embora os termos sejam os mesmos, os conceitos não são. Quando um locatário do Azure AD B2C é referido neste artigo, o termo completo locatário do Azure AD B2C é usado.

Identidade em soluções multilocatárias

Em soluções multilocatário, é comum combinar vários serviços de identidade para atingir diferentes conjuntos de requisitos. Muitas soluções têm dois conjuntos distintos de identidades:

  • Identidades de clientes, que são para contas de usuário final. Eles controlam como os usuários de seus locatários obtêm acesso aos seus aplicativos.
  • Identidades internas, que lidam com a forma como a sua própria equipa gere a sua solução.

Esses diferentes tipos de identidade também normalmente usam serviços de identidade distintos. O Azure AD B2C é um serviço de gerenciamento de acesso e identidade do cliente (CIAM) que os usuários de seus locatários usam para acessar a solução. O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso (IAM) que você e sua equipe usam para gerenciar seus recursos do Azure e controlar seu aplicativo.

Considere um exemplo de solução multilocatária criada pela Fabrikam. A solução usa uma combinação dos dois serviços para atender aos requisitos da Fabrikam:

  • A Fabrikam implementa o Azure AD B2C para que os clientes (locatários) da empresa possam entrar em aplicativos.
  • Os funcionários da Fabrikam usam o diretório Microsoft Entra de sua organização para obter acesso à solução para fins de gerenciamento e administração. Eles usam as mesmas identidades que usam para acessar outros recursos da Fabrikam, como o Microsoft Office.

O diagrama a seguir ilustra este exemplo:

Diagrama que descreve dois aplicativos com dois métodos de entrada.

Modelos de isolamento

Ao usar o Azure AD B2C, você precisa decidir como isolar suas contas de usuário entre diferentes locatários de aplicativos.

Você precisa considerar perguntas como:

  • Você precisa federar os logins para os provedores de identidade do seu cliente? Por exemplo, você precisa habilitar a federação para SAML, ID do Microsoft Entra, provedores de login social ou outras fontes?
  • Você ou seus inquilinos têm requisitos de residência de dados?
  • O usuário precisa acessar mais de um locatário de aplicativo?
  • Você precisa de permissões complexas e/ou controle de acesso baseado em função (RBAC)?
  • Quem inicia sessão na sua candidatura? Diferentes categorias de usuários são frequentemente chamadas de personas do usuário.

A tabela a seguir resume as diferenças entre os principais modelos de locação do Azure AD B2C:

Consideração Locatário compartilhado do Azure AD B2C Locatário do Azure AD B2C particionado verticalmente Um locatário do Azure AD B2C por locatário de aplicativo
Isolamento de dados Os dados de cada locatário de aplicativo são armazenados em um único locatário do Azure AD B2C, mas só podem ser acessados por administradores Os dados de cada locatário de aplicativo são distribuídos entre vários locatários do Azure AD B2C, mas só podem ser acessados por administradores Os dados de cada locatário de aplicativo são armazenados em um locatário dedicado do Azure AD B2C, mas só podem ser acessados por administradores
Complexidade da implantação Baixo Médio a alto, dependendo da sua estratégia de particionamento Muito alta
Limites a considerar Solicitações por locatário do Azure AD B2C, solicitações por endereço IP do cliente Uma combinação de solicitações, número de locatários do Azure AD B2C por assinatura e número de diretórios para um único usuário, dependendo da sua estratégia de particionamento Número de locatários do Azure AD B2C por assinatura, número máximo de diretórios para um único usuário
Complexidade operacional Baixo Médio a alto, dependendo da sua estratégia de particionamento Muito alta
Número de locatários do Azure AD B2C necessários Um Entre um e n, dependendo da sua estratégia de particionamento n, onde n é o número de locatários do aplicativo
Cenário de exemplo Você está criando uma oferta de SaaS para consumidores que tem poucos ou nenhum requisito de residência de dados, como um serviço de streaming de música ou vídeo. Você está criando uma oferta de SaaS, como um aplicativo de contabilidade e manutenção de registros para empresas. Você precisa oferecer suporte a requisitos de residência de dados ou a um grande número de provedores de identidade federada personalizados. Você está criando uma oferta de SaaS, como um aplicativo de manutenção de registros do governo para empresas. Seus clientes exigem um alto grau de isolamento de dados de outros locatários de aplicativos.

Locatário compartilhado do Azure AD B2C

Geralmente, é mais fácil gerenciar um único locatário compartilhado do Azure AD B2C se seus requisitos permitirem. Você precisa manter apenas um locatário a longo prazo, e essa opção cria a menor sobrecarga.

Nota

Recomendamos o uso de um locatário compartilhado do Azure AD B2C para a maioria dos cenários.

Você deve considerar um locatário compartilhado do Azure AD B2C quando:

  • Você não tem requisitos de residência de dados ou requisitos estritos de isolamento de dados.
  • Os requisitos do aplicativo estão dentro dos limites de serviço do Azure AD B2C.
  • Se você tiver provedores de identidade federados, poderá usar o Home Realm Discovery para selecionar automaticamente um provedor com o qual um usuário possa entrar, ou é aceitável que os usuários selecionem manualmente um de uma lista.
  • Você tem uma experiência de entrada unificada para todos os locatários de aplicativos.
  • Seus usuários finais precisam acessar mais de um locatário de aplicativo usando uma única conta.

Este diagrama ilustra o modelo de locatário compartilhado do Azure AD B2C:

Diagrama que mostra três aplicativos se conectando a um único locatário compartilhado do Azure AD B2C.

Locatários do Azure AD B2C particionados verticalmente

O provisionamento de locatários do Azure AD B2C particionados verticalmente é uma estratégia projetada para minimizar, quando possível, o número de locatários do Azure AD B2C necessários. É um meio termo entre os outros modelos de arrendamento. O particionamento vertical oferece maior flexibilidade na personalização para locatários específicos quando necessário. No entanto, ele não cria a sobrecarga operacional associada ao provisionamento de um locatário do Azure AD B2C para cada locatário de aplicativo.

Os requisitos de implantação e manutenção para esse modelo de locação são maiores do que os de um único locatário do Azure AD B2C, mas são menores do que serão se você usar um locatário do Azure AD B2C por locatário de aplicativo. Você ainda precisa projetar e implementar uma estratégia de implantação e manutenção para vários locatários em seu ambiente.

O particionamento vertical é semelhante ao padrão de compartilhamento de dados. Para particionar verticalmente seus locatários do Azure AD B2C, você precisa organizar os locatários do aplicativo em grupos lógicos. Essa categorização de locatários é frequentemente chamada de estratégia de particionamento. Sua estratégia de particionamento deve ser baseada em um fator comum e estável do locatário do aplicativo, como região, tamanho ou requisitos personalizados de um locatário de aplicativo. Por exemplo, se sua meta for resolver seus requisitos de residência de dados, você pode decidir implantar um locatário do Azure AD B2C para cada região que hospeda locatários de aplicativos. Ou, se você agrupar por tamanho, poderá decidir localizar a maioria das identidades dos locatários do aplicativo em um único locatário do Azure AD B2C, mas localizar seus maiores locatários de aplicativo em seus próprios locatários dedicados do Azure AD B2C.

Importante

Evite basear sua estratégia de particionamento em fatores que podem mudar ao longo do tempo, porque é difícil mover usuários entre locatários do Azure AD B2C. Por exemplo, se você criar uma oferta SaaS que tenha várias SKUs ou camadas de produto, não deverá particionar seus usuários com base na SKU selecionada, porque a SKU pode mudar se o cliente atualizar seu produto.

Você deve considerar o provisionamento de seus locatários do Azure AD B2C usando uma estratégia particionada verticalmente se:

  • Você tem requisitos de residência de dados ou precisa separar seus usuários por geografia.
  • Você tem um grande número de provedores de identidade federada e não pode usar o Home Realm Discovery para selecionar automaticamente um para um usuário entrar.
  • Seu aplicativo está, ou pode estar, ciente da multilocação e sabe em qual locatário do Azure AD B2C seus usuários precisam entrar.
  • Você acha que seus locatários de aplicativos maiores podem atingir os limites do Azure AD B2C.
  • Você tem uma estratégia de longo prazo para implantar e manter um número médio a grande de locatários do Azure AD B2C.
  • Você tem uma estratégia para fragmentar seus locatários de aplicativo entre uma ou mais assinaturas do Azure para trabalhar dentro do limite do número de locatários do Azure AD B2C que podem ser implantados em uma assinatura do Azure.

O diagrama a seguir ilustra o modelo de locatário do Azure AD B2C particionado verticalmente:

Diagrama que mostra três aplicações. Dois estão conectados a um locatário compartilhado do Azure AD B2C. O terceiro está conectado ao seu próprio locatário do Azure AD B2C.

Um locatário do Azure AD B2C por locatário de aplicativo

Se você provisionar um locatário do Azure AD B2C para cada locatário de aplicativo, poderá personalizar muitos fatores para cada locatário. No entanto, esta abordagem cria um aumento significativo das despesas gerais. Você precisa desenvolver uma estratégia de implantação e manutenção para um número potencialmente grande de locatários do Azure AD B2C.

Você também precisa estar ciente dos limites de serviço. As assinaturas do Azure permitem implantar apenas um número limitado de locatários do Azure AD B2C. Se você precisar implantar mais do que o limite permite, precisará considerar um design de assinatura apropriado para poder equilibrar seus locatários do Azure AD B2C em várias assinaturas. Existem outros limites do Microsoft Entra que também se aplicam, como o número de diretórios que um único usuário pode criar e o número de diretórios aos quais um usuário pode pertencer.

Aviso

Devido à complexidade dessa abordagem, é altamente recomendável que você considere os outros modelos de isolamento primeiro. Esta opção está incluída aqui por uma questão de exaustividade, mas não é a abordagem certa para a maioria dos casos de uso.

Um equívoco comum é assumir que, se você usar o padrão Selos de Implantação, precisará incluir serviços de identidade em cada carimbo. Isso não é necessariamente verdade, e muitas vezes você pode usar outro modelo de isolamento. Exerça diligência e tenha uma justificação comercial clara se utilizar este modelo de isolamento. As despesas gerais de implantação e manutenção são significativas.

Você deve considerar o provisionamento de um locatário do Azure AD B2C para cada locatário de aplicativo somente se:

  • Você tem requisitos rígidos de isolamento de dados para locatários de aplicativos.
  • Você tem uma estratégia de longo prazo para implantar e manter um grande número de locatários do Azure AD B2C.
  • Você tem uma estratégia para fragmentar seus clientes entre uma ou mais assinaturas do Azure para cumprir o limite de locatário por assinatura do Azure AD B2C.
  • Seu aplicativo está, ou pode estar, ciente da multilocação e sabe em qual locatário do Azure AD B2C seus usuários precisam entrar.
  • Você precisa executar a configuração personalizada para cada locatário do aplicativo.
  • Seus usuários finais não precisam acessar mais de um locatário de aplicativo por meio da mesma conta de login.

O diagrama a seguir ilustra o uso de um locatário do Azure AD B2C por locatário de aplicativo:

Diagrama que mostra três aplicativos, cada um se conectando ao seu próprio locatário do Azure AD B2C.

Federação de identidades

Você precisa configurar cada provedor de identidade federada, seja por meio de um fluxo de usuário ou em uma política personalizada. Normalmente, durante o login, os usuários selecionam qual provedor de identidade desejam usar para autenticar. Se você estiver usando um modelo de isolamento de locatário compartilhado ou tiver um grande número de provedores de identidade federada, considere usar o Home Realm Discovery para selecionar automaticamente um provedor de identidade durante o login.

Você também pode usar a federação de identidades como uma ferramenta para gerenciar vários locatários do Azure AD B2C federando os locatários do Azure AD B2C entre si. Isso permite que seu aplicativo confie em um único locatário do Azure AD B2C. O aplicativo não precisa estar ciente de que seus clientes estão divididos entre vários locatários do Azure AD B2C. Essa abordagem é mais comumente usada no modelo de isolamento particionado verticalmente, quando os usuários são particionados por região. Você precisa levar algumas considerações em conta se adotar essa abordagem. Para obter uma visão geral dessa abordagem, consulte Soluções de identidade global.

Deteção de Realm Inicial

Home Realm Discovery é o processo de seleção automática de um provedor de identidade federada para o evento de entrada de um usuário. Se você selecionar automaticamente o provedor de identidade do usuário, não precisará solicitar que o usuário selecione um provedor.

A Descoberta de Território Doméstico é importante quando você usa um locatário compartilhado do Azure AD B2C e também permite que seus clientes tragam seu próprio provedor de identidade federada. Talvez você queira evitar um design no qual um usuário precisa selecionar em uma lista de provedores de identidade. Isso adiciona complexidade ao processo de entrada. Além disso, um usuário pode selecionar acidentalmente um provedor incorreto, o que faz com que a tentativa de entrada falhe.

Você pode configurar o Home Realm Discovery de várias maneiras. A abordagem mais comum é usar o sufixo de domínio do endereço de e-mail do usuário para determinar o provedor de identidade. Por exemplo, digamos que a Northwind Traders é cliente da solução multilocatária da Fabrikam. O endereço user@northwindtraders.com de e-mail inclui o sufixo northwindtraders.comde domínio , que pode ser mapeado para o provedor de identidade federada Northwind Traders.

Para obter mais informações, consulte Home Realm Discovery. Para obter um exemplo de como implementar essa abordagem no Azure AD B2C, consulte o repositório GitHub de exemplos do Azure AD B2C.

Residência de dados

Ao provisionar um locatário do Azure AD B2C, você seleciona, para fins de residência de dados, uma região na qual implantar o locatário. Essa escolha é importante porque especifica a região em que os dados do cliente residem quando estão em repouso. Se você tiver requisitos de residência de dados para um subconjunto de seus clientes, considere usar a estratégia particionada verticalmente.

Autorização

Para uma solução de identidade forte, você precisa considerar a autorização , além da autenticação. Há várias abordagens para usar a plataforma de identidade da Microsoft para criar uma estratégia de autorização para seu aplicativo. O exemplo AppRoles demonstra como usar funções de aplicativo do Azure AD B2C para implementar autorização em um aplicativo. Descreve igualmente abordagens alternativas em matéria de autorização.

Não há uma abordagem única para a autorização, e você deve considerar as necessidades de seu aplicativo e de seus clientes ao decidir sobre uma abordagem.

Manutenção

Ao planejar uma implantação multilocatária do Azure AD B2C, você precisa pensar na manutenção de longo prazo de seus recursos do Azure AD B2C. Um locatário do Azure AD B2C, como seu locatário organizacional do Microsoft Entra, é um recurso que você precisa para criar, manter, operar e proteger. Embora a lista a seguir não seja abrangente, você deve considerar a manutenção incorrida em áreas como estas:

  • Governança do inquilino. Quem mantém o locatário do Azure AD B2C? De que funções elevadas esses administradores precisam? Como você configura as políticas de Acesso Condicional e MFA para os administradores? Como você monitora o locatário do Azure AD B2C a longo prazo?
  • Configuração da jornada do usuário. Como você implanta alterações em seu locatário ou locatários do Azure AD B2C? Como você testa as alterações em seus fluxos de usuários ou políticas personalizadas antes de implantá-las?
  • Provedores de identidade federada. Você precisa adicionar ou remover provedores de identidade ao longo do tempo? Se você permitir que cada um de seus clientes traga seu próprio provedor de identidade, como você gerencia isso em escala?
  • Registos de aplicações. Muitos registros de aplicativos do Microsoft Entra usam um segredo de cliente ou certificado para autenticação. Como você alterna esses segredos ou certificados quando precisa?
  • Chaves de política. Se você usa políticas personalizadas, como alterna as chaves de política quando precisa?
  • Credenciais do usuário. Como você gerencia as informações e credenciais do usuário? O que acontece se um dos seus utilizadores for bloqueado ou esquecer uma palavra-passe e necessitar da intervenção do administrador ou do serviço de apoio ao cliente?

Lembre-se de que você precisa considerar essas perguntas para cada locatário do Azure AD B2C implantado. Você também deve considerar como seus processos mudam quando você tem vários locatários do Azure AD B2C para manter. Por exemplo, implantar manualmente alterações de política personalizadas em um locatário do Azure AD B2C é fácil, mas implantá-las manualmente em cinco locatários é demorado e arriscado.

Implantações e DevOps

Um processo de DevOps bem definido pode ajudá-lo a minimizar a sobrecarga necessária para manter seus locatários do Azure AD B2C. Você deve implementar práticas de DevOps no início do seu processo de desenvolvimento. Idealmente, você deve tentar automatizar todas ou a maioria das suas tarefas de manutenção, incluindo a implantação de alterações em suas políticas personalizadas ou fluxos de usuários. Você também deve planejar a criação de vários locatários do Azure AD B2C para testar progressivamente as alterações em ambientes inferiores antes de implantá-las em seus locatários de produção. Seus pipelines de DevOps podem executar essas atividades de manutenção. Você pode usar a API do Microsoft Graph para gerenciar programaticamente seus locatários do Azure AD B2C.

Para obter mais informações sobre implantações automatizadas e gerenciamento do Azure AD B2C, consulte os seguintes recursos.

Importante

Alguns dos pontos de extremidade usados para gerenciar o Azure AD B2C programaticamente não estão disponíveis em geral. As APIs na versão beta do Microsoft Graph estão sujeitas a alterações a qualquer momento e estão sujeitas aos termos de serviço de pré-lançamento.

Comparando o Microsoft Entra B2B com o Azure AD B2C

A colaboração B2B do Microsoft Entra é um recurso do Microsoft Entra External ID que você pode usar para convidar usuários convidados para seu locatário organizacional do Microsoft Entra para que você possa colaborar com eles. Normalmente, você usa a colaboração B2B quando precisa conceder a um usuário externo, como um fornecedor, acesso a recursos em seu locatário do Microsoft Entra.

O Azure AD B2C é um produto exclusivo além do Microsoft Entra External ID que fornece um conjunto diferente de recursos. O Azure AD B2C destina-se a ser utilizado pelos clientes do seu produto. Seu locatário do Azure AD B2C é distinto do locatário organizacional do Microsoft Entra.

Dependendo de suas personas de usuário e cenários, talvez seja necessário usar o Microsoft Entra B2B, Azure AD B2C ou até mesmo ambos ao mesmo tempo. Por exemplo, se seu aplicativo precisar autenticar vários tipos de usuários, como funcionários em sua organização, usuários que trabalham para um fornecedor e clientes, todos dentro do mesmo aplicativo, você poderá usar o Microsoft Entra B2B e o Azure AD B2C juntos para atender a esse requisito.

Para obter mais informações, consulte:

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Landon Pierce - Brasil | Engenheiro de Clientes, FastTrack for Azure

Outros contribuidores:

  • Mick Alberts - Brasil | Redator Técnico
  • Michael Bazarewsky - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
  • John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Jelle Druyts - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Simran Jeet Kaur - Brasil | Engenheiro de Clientes, FastTrack for Azure
  • LaBrina Amar | Gerente Principal de Engenharia do Cliente, FastTrack for Azure
  • Arsen Vladimirsky - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos