Compartilhar via

Considerações para usar o Azure Active Directory B2C em uma arquitetura multilocatário

  • Artigo

O Azure Active Directory (Azure AD) B2C fornece identidade business-to-consumer como um serviço. A identidade do usuário geralmente é uma das principais considerações quando você projeta 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 definidos 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 os usuários possam entrar com uma conta preexistente. 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 empresariais. Se você usar federação, seus usuários não precisarão criar uma conta local separada que seja específica para seu aplicativo.

Se você for novo neste tópico, recomendamos revisar os seguintes recursos:

Observação

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

O termo locatário de aplicativo é usado para fazer referência a 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 é mencionado neste artigo, o termo completo locatário do Azure AD B2C é usado.

Identidade em soluções multilocatário

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 cliente, que são para contas de usuário final. Elas controlam como os usuários de seus locatários obtêm acesso aos seus aplicativos.
  • Identidades internas, que lidam com a forma como sua própria equipe gerencia sua solução.

Esses diferentes tipos de identidade também geralmente usam serviços de identidade distintos. O Azure AD B2C é um serviço de gerenciamento de acesso e de 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 os recursos do Azure e controlar seu aplicativo.

Considere um exemplo de solução multilocatário criado 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 nos aplicativos.
  • Os funcionários da Fabrikam usam o diretório do 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 esse 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 questões como:

  • Você precisa federar as entradas para os provedores de identidade do cliente? Por exemplo, você precisa habilitar a federação para SAML, Microsoft Entra ID, provedores sociais de entrada ou outras fontes?
  • Você ou seus locatários 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 entra em seu aplicativo? Diferentes categorias de usuários são frequentemente chamadas personas de usuários.

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

Consideração Locatário do Azure AD B2C compartilhado 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 podem ser acessados apenas por administradores Os dados de cada locatário de aplicativo são distribuídos entre vários locatários do Azure AD B2C, mas podem ser acessados apenas por administradores Os dados de cada locatário de aplicativo são armazenados em um locatário do Azure AD B2C dedicado, mas podem ser acessados apenas por administradores
Complexidade da implantação Baixo Médio a alto, dependendo da sua estratégia de particionamento Muito alto
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 alto
Número de locatários do Azure AD B2C necessários Um Entre um e n, dependendo da sua estratégia de particionamento n, em que n é o número de locatários do aplicativo
Cenário de exemplo Você está criando uma oferta de SaaS para consumidores que não tem nenhum requisito de residência de dados ou que tem um número baixo de requisitos, 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 de manutenção de registros para empresas. Você precisa dar suporte a requisitos de residência de dados ou a um grande número de provedores de identidade federados 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 do Azure AD B2C compartilhado

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

Observação

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 rígidos de isolamento de dados.
  • Seus requisitos de aplicativo estão dentro dos limites de serviço do Azure AD B2C.
  • Se você tiver federado provedores de identidade, poderá usar a Descoberta de Realm Inicial para selecionar automaticamente um provedor com o qual um usuário entrar, ou será 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 que foi 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 locação. 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 Fragmentação de Dados. Para particionar verticalmente seus locatários do Azure AD B2C, você precisa organizar seus locatários de aplicativo em grupos lógicos. Essa categorização de locatários é geralmente chamada de estratégia de particionamento. Sua estratégia de particionamento deve ser baseada em um fator comum e estável do locatário de aplicativo, como região, tamanho ou requisitos personalizados de um locatário de aplicativo. Por exemplo, se o seu objetivo for resolver seus requisitos de residência de dados, você poderá decidir implantar um locatário do Azure AD B2C para cada região que hospeda locatários de aplicativo. Ou, se você agrupar por tamanho, poderá decidir localizar a maioria das identidades de seus locatários de aplicativo em um único locatário do Azure AD B2C, mas localizar seus maiores locatários de aplicativo nos próprios locatários dedicados do Azure AD B2C.

Importante

Evite basear sua estratégia de particionamento em fatores que podem mudar com o tempo, porque é difícil mover usuários entre locatários do Azure AD B2C. Por exemplo, se você criar uma oferta de 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 poderá ser alterada 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ê tiver requisitos de residência de dados ou precisar separar seus usuários por geografia.
  • Você tiver um grande número de provedores de identidade federados e não puder usar a Descoberta de Realm Inicial para selecionar automaticamente um para um usuário entrar.
  • Seu aplicativo estiver, ou puder estar, ciente da multilocação e souber em qual locatário do Azure AD B2C seus usuários precisam entrar.
  • Você acha que seus locatários de aplicativo maiores podem atingir os limites do Azure AD B2C.
  • Você terá 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ê terá uma estratégia para fragmentar seus locatários de aplicativo entre uma ou mais assinaturas do Azure para trabalhar dentro do limite no 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 aplicativos. 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, essa abordagem cria um aumento significativo na sobrecarga. 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 permitido, precisará considerar um design de assinatura apropriado, para poder equilibrar seus locatários do Azure AD B2C em várias assinaturas. Há 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. Essa opção está incluída aqui por uma questão de integridade, mas não é a abordagem certa para a maioria dos casos de uso.

Um equívoco comum é supor que, se você usar o padrão de Selos de Implantação, você precisará incluir serviços de identidade em cada selo. Isso não é necessariamente verdade, e muitas vezes você pode usar outro modelo de isolamento. Exerça diligência e tenha uma justificativa comercial clara se você usar esse modelo de isolamento. A sobrecarga de implantação e manutenção é significativa.

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

  • Você tiver requisitos rígidos de isolamento de dados para locatários de aplicativo.
  • Você terá uma estratégia de longo prazo para implantar e manter um número grande de locatários do Azure AD B2C.
  • Você tiver 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 estiver, ou puder estar, ciente da multilocação e souber em qual locatário do Azure AD B2C seus usuários precisam entrar.
  • Você precisará executar a configuração personalizada para todos os locatários de aplicativo.
  • Seus usuários finais não precisarão acessar mais de um locatário de aplicativo por meio da mesma conta de entrada.

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 identidade

Você precisa configurar cada provedor de identidade federado, por meio de um fluxo de usuário ou em uma política personalizada. Geralmente, durante a entrada, 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 federados, considere usar a Descoberta de Realm Inicial para selecionar automaticamente um provedor de identidade durante a entrada.

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 uns com os outros. Dessa forma, seu aplicativo pode confiar em um único locatário do Azure AD B2C. O aplicativo não precisa estar ciente de que seus clientes estão divididos entre múltiplos 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. Se adotar essa abordagem, você precisará considerar alguns pontos. Para obter uma visão geral dessa abordagem, consulte Soluções de identidade global.

Descoberta de Realm Inicial

Descoberta de Realm Inicial é o processo de selecionar automaticamente um provedor de identidade federado para o evento de entrada de um usuário. Se você selecionar automaticamente o provedor de identidade do usuário, não será necessário solicitar que o usuário selecione um provedor.

A Descoberta de Realm Inicial é importante quando você usa um locatário compartilhado do Azure AD B2C e também permite que seus clientes tragam o próprio provedor de identidade federada. Talvez você queira evitar um design no qual um usuário precise 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 pode fazer com que a tentativa de entrada falhe.

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

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

Residência de dadosResidê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 opção é importante porque especifica a região em que os dados do cliente residem quando estão inativos. 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 a autorização em um aplicativo. Ele também descreve abordagens de autorização alternativas.

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 por uma abordagem.

Manutenção

Ao planejar uma implantação multilocatário 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 do qual 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 locatário. Quem mantém o locatário do Azure AD B2C? Quais são as funções elevadas que esses administradores precisam? Como configurar as políticas de Acesso Condicional e MFA para os administradores? Como você monitora o locatário do Azure AD B2C no longo prazo?
  • Configuração da jornada do usuário. Como você implanta alterações em um ou mais locatários do Azure AD B2C? Como você testa as alterações em seus fluxos de usuário ou políticas personalizadas antes de implantá-las?
  • Provedores de identidade federados. 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ê gerenciará isso em escala?
  • Registros de aplicativo. Muitos registros de aplicativos do Microsoft Entra usam um segredo do cliente ou certificado para autenticação. Como você gira esses segredos ou certificados quando precisa?
  • Chaves de política. Se você usar políticas personalizadas, como girará as chaves de política quando precisar?
  • Credenciais de usuário. Como você gerencia as informações e credenciais do usuário? O que acontecerá se um de seus usuários for bloqueado ou esquecer uma senha e requerer intervenção do administrador ou do atendimento 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 múltiplos 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 processo de desenvolvimento. De maneira ideal, você deve tentar automatizar todas ou a maioria das tarefas de manutenção, incluindo a implantação de alterações em suas políticas personalizadas ou fluxos de usuário. Você também deve planejar criar múltiplos 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 recursos a seguir.

Importante

Alguns dos pontos de extremidade usados para gerenciar o Azure AD B2C programaticamente não estão disponíveis para o público 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

Colaboração B2B do Microsoft Entra é um recurso da ID Externa da ID Externa do Microsoft Entra que você pode usar para convidar usuários convidados para seu locatário organizacional do Microsoft Entra para que você possa colaborar com eles. Geralmente, 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 da ID Externa do Microsoft Entra, que fornece um conjunto diferente de recursos. O Azure AD B2C destina-se a ser usado pelos clientes do seu produto. Seu locatário do Azure AD B2C é diferente do locatário organizacional do Microsoft Entra.

Dependendo de suas personas e cenários de usuário, talvez seja necessário usar o Microsoft Entra B2B, o 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, os 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 saber mais, veja:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

  • Mick Alberts | Escritor Técnico
  • Michael Bazarewsky | Engenheiro Sênior do Cliente do FastTrack for Azure
  • John Downs | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
  • Jelle Druyts | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
  • Simran Jeet Kaur | Engenheiro do cliente, FastTrack for Azure
  • LaBrina Loving | Gerenciador de Engenharia de Clientes Principal do FastTrack para Azure
  • Arsen Vladimirsky | Engenheiro de cliente principal, FastTrack for Azure

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

Próximas etapas