Compartilhar via

Considerações de arquitetura para identidade em uma solução multilocatário

A identidade é um aspecto importante de qualquer solução multilocatário. Os componentes de identidade do aplicativo são responsáveis pelas seguintes tarefas:

  • Verificando a identidade de um usuário, conhecida como autenticação

  • Aplicar as permissões de um usuário dentro do escopo de um locatário, conhecido como autorização

Seus clientes também podem querer autorizar aplicativos externos a acessar seus dados ou integrar-se à sua solução. A identidade de um usuário determina quais informações um usuário ou serviço pode acessar. É importante que você considere seus requisitos de identidade para isolar seu aplicativo e seus dados entre os locatários.

Atenção

Os serviços de autenticação e autorização em aplicativos SaaS (multilocatário e software como serviço) normalmente são fornecidos por um IdP (provedor de identidade externo). Um IdP geralmente é parte integrante de uma plataforma de identidade gerenciada.

Construir seu próprio IdP é complexo, caro e desafiador de proteger. É considerado um antipadrão, e não recomendamos isso.

Antes de definir uma estratégia de identidade multitenant, considere primeiro os seguintes requisitos de identidade de alto nível para o seu serviço:

  • Determine se as identidades de usuários ou de carga de trabalho acessam um único aplicativo ou vários aplicativos dentro de uma família de produtos. Algumas famílias de produtos podem incluir aplicativos distintos que compartilham a mesma infraestrutura de identidade, como sistemas de ponto de venda e plataformas de gerenciamento de inventário.

  • Considere se sua solução implementa padrões modernos de autenticação e autorização, como OAuth2 e OpenID Connect.

  • Avalie se a autenticação está limitada a aplicativos baseados em interface do usuário ou se o acesso à API também se aplica a locatários e sistemas de terceiros.

  • Determine se os locatários precisam se federar com seus próprios IdPs e se é necessário oferecer suporte a vários IdPs para cada locatário. Por exemplo, você pode ter inquilinos com o Microsoft Entra ID, o Auth0 e os Serviços de Federação do Active Directory, onde cada inquilino está federado com sua solução. Identifique quais protocolos de federação seus IdPs usam, pois esses protocolos determinam o suporte que seu IdP deve oferecer.

  • Examine todos os requisitos de conformidade aplicáveis que eles precisam atender, como o GdpR (Regulamento Geral de Proteção de Dados), que moldam sua estratégia de identidade.

  • Determine se os locatários exigem que os dados de identidade sejam armazenados em regiões geográficas específicas para atender às necessidades legais, de conformidade ou operacionais.

  • Avalie se os usuários acessam dados de vários locatários dentro do aplicativo. Se eles o fizerem, pode ser necessário dar suporte à alternância de inquilinos sem interrupções ou fornecer exibições consolidadas entre diferentes inquilinos para usuários específicos. Por exemplo, os usuários que entram no portal do Azure podem alternar facilmente entre diferentes diretórios de ID do Microsoft Entra e assinaturas às quais têm acesso.

Ao estabelecer seus requisitos de alto nível, você pode começar a planejar detalhes e requisitos mais específicos, como fontes de diretório do usuário e fluxos de inscrição e entrada.

Diretório de identidade

Para que uma solução multilocatário autentique e autorize um usuário ou serviço, ela precisará de um local para armazenar informações de identidade. Um diretório pode incluir registros autoritativos para cada identidade. Ou pode conter referências a identidades externas armazenadas no diretório de outro IdP.

Ao projetar um sistema de identidade para sua solução multilocatário, você precisa considerar quais dos seguintes tipos de IdP podem ser necessários para seus locatários e clientes:

  • IdP local: Um IdP local permite que os usuários se inscrevam no serviço. Os usuários fornecem um nome de usuário, um endereço de email ou um identificador, como um número de cartão de recompensa. Eles também fornecem uma credencial, como uma senha. O IdP armazena o identificador do usuário e as credenciais.

  • IdP Social: Um IdP social permite que os usuários usem uma identidade que eles têm em uma rede social ou outro IdP público, como Facebook, Google ou uma conta pessoal da Microsoft. Os IdPs sociais são comumente usados em soluções SaaS B2C (entre empresas e consumidores).

  • O diretório de ID do Microsoft Entra do locatário: Em muitas soluções SaaS de B2B (empresa para empresa), os locatários podem já ter seu próprio diretório de ID do Microsoft Entra e talvez queiram que a solução de vocês utilize o diretório deles como o IdP para acesso. Essa abordagem é possível quando sua solução é criada como um aplicativo multilocatário do Microsoft Entra.

  • Federação com o IdP de um locatário: Em algumas soluções de SaaS B2B, os locatários podem ter seu próprio IdP, além da ID do Microsoft Entra, e talvez queiram que sua solução seja federada com ela. A federação habilita o SSO (logon único). Ele também permite que os locatários gerenciem o ciclo de vida e as políticas de segurança de seus usuários independentemente da solução.

Você deve considerar se seus locatários precisam oferecer suporte a vários IdPs. Por exemplo, um único locatário pode precisar dar suporte a identidades locais, identidades sociais e identidades federadas. Esse requisito é típico quando as empresas usam uma solução destinada a funcionários e empreiteiros. Eles podem usar a federação para conceder acesso aos funcionários, ao mesmo tempo em que permitem acesso a empreiteiros ou usuários que não têm contas no IdP federado.

Armazenar informações de autenticação e autorização do locatário

Em uma solução multilocatário, você precisa considerar onde armazenar vários tipos de informações de identidade, incluindo os seguintes tipos:

  • Detalhes sobre contas de usuário e serviço, incluindo seus nomes e outras informações que seus locatários exigem.

  • Informações necessárias para autenticar seus usuários com segurança, incluindo informações para autenticação multifator (MFA).

  • Informações específicas do locatário, como funções de locatário e permissões, para autorização.

Atenção

Não recomendamos que você mesmo crie processos de autenticação. Os IdPs modernos fornecem esses serviços de autenticação para seu aplicativo e também incluem outros recursos importantes, como MFA e acesso condicional. Criar seu próprio provedor de identidade é um antipadrão. Não recomendamos isso.

Considere as seguintes opções para armazenar informações de identidade:

  • Armazene todas as informações de identidade e autorização no diretório IdP e compartilhe-as entre múltiplos locatários.

  • Armazene as credenciais do usuário no diretório IdP. Armazene dados de autorização na camada de aplicativo, juntamente com as informações do locatário.

Determinar o número de identidades para um usuário

As soluções multilocatário geralmente permitem que uma identidade de usuário ou carga de trabalho acesse recursos e dados de aplicativos em vários locatários. Quando essa abordagem for necessária, considere os seguintes fatores:

  • Decida se deseja criar uma única identidade de usuário para cada pessoa ou criar identidades separadas para cada combinação locatário-usuário.

    • Use uma única identidade para cada pessoa quando possível. Ele simplifica o gerenciamento de conta para o provedor de solução e os usuários. Além disso, muitas das proteções inteligentes contra ameaças que os IdPs modernos fornecem dependem de cada pessoa ter uma única conta de usuário.

    • Use várias identidades distintas em alguns cenários. Por exemplo, se as pessoas usarem seu sistema para fins profissionais e pessoais, talvez elas queiram separar suas contas de usuário. Ou se seus locatários tiverem requisitos estritos de armazenamento de dados regulatórios ou geográficos, eles poderão exigir que uma pessoa tenha várias identidades para que possa cumprir regulamentos ou leis.

  • Evite armazenar credenciais várias vezes se você usar identidades por locatário. Os usuários devem ter suas credenciais armazenadas em uma única identidade, e você deve usar recursos, como identidades de convidado para fazer referência às mesmas credenciais de usuário de registros de identidade de múltiplos locatários.

Conceder aos usuários acesso aos dados do locatário

Considere como você planeja mapear usuários para um locatário. Por exemplo, durante o processo de inscrição, você pode fornecer um código de convite exclusivo para os usuários inserirem quando acessarem um locatário pela primeira vez. Em algumas soluções, o nome de domínio do endereço de email de inscrição do usuário pode identificar seu locatário associado. Como alternativa, você pode usar outro atributo do registro de identidade do usuário para determinar o mapeamento do locatário. Essa associação deve ser armazenada com base em identificadores exclusivos e imutáveis para o locatário e o usuário.

Se sua solução limitar cada usuário a acessar dados para um único locatário, considere as seguintes decisões:

  • Determine como o IdP detecta qual entidade um usuário acessa.

  • Explicar como o IdP comunica o identificador de locatário ao aplicativo. Normalmente, uma declaração de identificador de locatário é adicionada ao token.

Se um único usuário precisar ter acesso a vários locatários, considere as seguintes decisões:

  • A solução deve dar suporte à lógica para identificar usuários e conceder permissões apropriadas entre locatários. Por exemplo, um usuário pode ter direitos administrativos em um locatário, mas acesso limitado em outro locatário. Por exemplo, suponha que um usuário se inscreveu com uma identidade social e recebeu acesso a dois locatários. O locatário A enriqueceu a identidade do usuário com mais informações. O locatário B deve ter acesso às informações enriquecidas?

  • Um mecanismo claro deve permitir que os usuários mudem entre locatários. Essa abordagem garante uma experiência tranquila do usuário e impede o acesso acidental entre locatários.

  • As identidades de carga de trabalho, se você as usar, devem especificar qual locatário estão tentando acessar. Esse requisito pode incluir a inserção de contexto específico do locatário em solicitações de autenticação.

  • Considere se as informações específicas do locatário armazenadas no registro de identidade de um usuário podem vazar involuntariamente entre locatários. Por exemplo, se um usuário se inscrever com uma identidade social e obtiver acesso a dois locatários e o Locatário A enriquecer o perfil do usuário, determine se o Locatário B deve ter acesso a essas informações enriquecidas.

Processo de inscrição do usuário para identidades locais ou sociais

Alguns locatários talvez precisem permitir que os usuários se inscrevam para obter uma identidade em sua solução. A inscrição por autoatendimento pode ser necessária se você não precisar de federação com o IdP de um locatário. Se um processo de auto-inscrição for necessário, considere os seguintes fatores:

  • Defina quais fontes de identidade os usuários podem se inscrever a partir. Por exemplo, determine se os usuários podem criar uma identidade local e também usar um IdP social.

  • Especifique se a solução permite apenas domínios de email específicos se as identidades locais forem usadas. Por exemplo, determine se um locatário pode restringir as inscrições a usuários com um @contoso.com endereço de email.

  • O UPN (nome de entidade de usuário) usado para identificar identidades locais deve ser claramente estabelecido. OS UPNs comuns incluem endereços de email, nomes de usuário, números de telefone ou identificadores de associação. Como os UPNs podem ser alterados, é aconselhável fazer referência ao identificador exclusivo imutável subjacente para autorização e auditoria. Um exemplo é o ID de objeto (OID) no Microsoft Entra ID.

  • A verificação de UPNs pode ser necessária para garantir sua precisão. Esse processo pode incluir a validação da propriedade de um endereço de email ou número de telefone antes de conceder acesso.

  • Algumas soluções podem exigir que os administradores de locatários aprovem as inscrição do usuário. Esse processo de aprovação permite o controle administrativo sobre quem se junta a um locatário.

  • Decida se os locatários precisam de uma experiência de registro ou URL específica para o locatário. Por exemplo, determine se seus locatários exigem uma experiência de inscrição com a marca quando os usuários se inscrevem ou a capacidade de interceptar uma solicitação de inscrição e realizar uma validação extra antes de prosseguir.

Acesso de locatário para usuários de inscrição de autoatendimento

Se os usuários puderem se inscrever para obter uma identidade, defina um processo para conceder-lhes acesso a um locatário. O fluxo de inscrição pode incluir um processo manual de concessão de acesso ou um processo automatizado com base nas informações sobre os usuários, como seus endereços de email. É importante planejar esse processo e considerar os seguintes fatores:

  • Defina como o fluxo de inscrição determina que um usuário recebe acesso a um locatário específico.

  • Defina se sua solução revoga automaticamente o acesso do usuário a um locatário quando apropriado. Por exemplo, quando os usuários saem de uma organização, deve haver um processo manual ou automatizado em vigor para remover o acesso.

  • Forneça um recurso de auditoria do usuário para que os locatários possam examinar quais usuários têm acesso ao seu ambiente e entender suas permissões atribuídas.

Gerenciamento automatizado do ciclo de vida da conta

Um requisito comum para clientes corporativos ou de empresas de uma solução é um conjunto de recursos que lhes permitem automatizar a integração e desintegração de contas. Protocolos abertos, como o SCIM (System for Cross-Domain Identity Management), fornecem uma abordagem padrão do setor para automação. Esse processo automatizado geralmente inclui a criação e remoção de registros de identidade e o gerenciamento de permissões de locatário. Considere os seguintes fatores ao implementar o gerenciamento automatizado do ciclo de vida da conta em uma solução multilocatário:

  • Determine se os clientes precisam configurar e gerenciar um processo de ciclo de vida automatizado para cada locatário. Por exemplo, quando um usuário for integrado, talvez seja necessário criar a identidade em múltiplos locatários em seu aplicativo, onde cada locatário terá um conjunto diferente de permissões.

  • Determine se você precisa implementar o SCIM ou oferecer federação. A federação permite que os clientes mantenham o controle sobre o gerenciamento de usuários, preservando a origem dos dados verdadeiros dentro de seus próprios sistemas, em vez de gerenciar usuários locais na solução fornecida.

Processo de autenticação de usuário

Quando um usuário entra em um aplicativo multilocatário, seu sistema de identidade autentica o usuário. Considere os seguintes fatores ao planejar seu processo de autenticação:

  • Alguns locatários podem exigir a capacidade de configurar suas próprias políticas de MFA. Por exemplo, se seus locatários estiverem no setor de serviços financeiros, precisarão implementar políticas rígidas de MFA, enquanto um pequeno varejista online poderá não ter as mesmas exigências.

  • A opção de definir regras de acesso condicional personalizadas pode ser importante para os locatários. Por exemplo, diferentes locatários podem precisar bloquear tentativas de entrada de regiões geográficas específicas.

  • Determine se os locatários precisam personalizar o processo de entrada individualmente. Por exemplo, sua solução pode precisar mostrar o logotipo de um cliente. Ou talvez seja necessário recuperar informações do usuário, como um número de recompensas, de outro sistema e devolvê-la ao IdP para enriquecer o perfil do usuário.

  • Talvez alguns usuários precisem representar outros usuários. Por exemplo, um membro da equipe de suporte pode querer investigar um problema que outro usuário tem ao representar sua conta de usuário sem precisar se autenticar como o usuário.

  • O acesso à API pode ser necessário para alguns usuários ou aplicativos externos. Esses cenários podem incluir chamar as APIs da solução diretamente, o que ignora os fluxos de autenticação de usuário padrão.

Identidades de carga de trabalho

Na maioria das soluções, uma identidade geralmente representa um usuário. Alguns sistemas multilocatários também permitem que identidades de carga de trabalho sejam usadas por serviços e aplicativos para obter acesso aos recursos do aplicativo. Por exemplo, talvez seus locatários precisem acessar uma API que sua solução fornece para que eles possam automatizar suas tarefas de gerenciamento.

O Microsoft Entra dá suporte a identidades de carga de trabalho e outros IdPs também costumam dar suporte a elas.

As identidades de carga de trabalho são semelhantes às identidades de usuário, mas geralmente exigem métodos de autenticação diferentes, como chaves ou certificados. As identidades de carga de trabalho não usam MFA. Em vez disso, as identidades de carga de trabalho geralmente requerem que outros controles de segurança, como rolagem regular de chaves e expiração de certificado.

Se seus locatários puderem habilitar o acesso à identidade de carga de trabalho para sua solução multilocatário, você deverá considerar os seguintes fatores:

  • Determine como as identidades de carga de trabalho são criadas e gerenciadas em cada locatário.

  • Decida como as solicitações de identidade de carga de trabalho são delimitadas para o locatário.

  • Avalie se você precisa limitar o número de identidades de carga de trabalho que cada locatário cria.

  • Determine se são necessários controles de acesso condicional para identidades de carga de trabalho em cada locatário. Por exemplo, um locatário pode querer limitar uma identidade de carga de trabalho de ser autenticada de fora de uma região específica.

  • Identifique quais controles de segurança você fornece aos locatários para garantir que as identidades da carga de trabalho permaneçam seguras. Por exemplo, a rolagem automatizada de chaves, a expiração de chaves, a expiração de certificados e o monitoramento de riscos de login ajudam a reduzir o risco de uso indevido da identidade do carga de trabalho.

Federar com um IdP para SSO

Os locatários que já têm seus próprios diretórios de usuário podem querer que sua solução realize a federação com seus diretórios. A federação permite que sua solução use as identidades em seu diretório em vez de gerenciar outro diretório com identidades distintas.

A federação é especialmente importante quando alguns locatários desejam especificar suas próprias políticas de identidade ou habilitar experiências de SSO.

Se você espera que os locatários federam com sua solução, considere os seguintes fatores:

  • Considere o processo de configuração da federação para um locatário. Determine se os locatários configuram a federação por conta própria ou se o processo requer configuração e manutenção manuais por sua equipe.

  • Defina quais protocolos de federação sua solução dá suporte.

  • Estabeleça processos que impedem que configurações incorretas de federação concedam acesso a locatários não previstos.

  • Planeje se o IdP de um único locatário precisa ser federado a mais de um locatário na sua solução. Por exemplo, se os clientes tiverem tanto um tenant de treinamento quanto um tenant de produção, talvez precisem federar o mesmo IdP com cada tenant.

Modelos de autorização

Decida sobre o modelo de autorização que faça mais sentido para sua solução. Considere as seguintes abordagens comuns de autorização:

  • Autorização baseada em função: Os usuários são atribuídos a funções. Alguns recursos do aplicativo são restritos a funções específicas. Por exemplo, um usuário na função de administrador pode executar qualquer ação, enquanto um usuário em uma função inferior pode ter um subconjunto de permissões em todo o sistema.

  • Autorização baseada em recursos: Sua solução fornece um conjunto de recursos distintos, cada um deles com seu próprio conjunto de permissões. Um usuário específico pode ser um administrador de um recurso e não ter acesso a outro recurso.

Esses modelos são distintos e a abordagem selecionada afeta sua implementação e a complexidade das políticas de autorização que você pode implementar.

Direitos e licenciamento

Em algumas soluções, você pode usar o licenciamento por usuário como parte do seu modelo de preços comerciais. Nesse cenário, você fornece diferentes camadas de licenças de usuário que têm recursos diferentes. Por exemplo, os usuários com uma licença podem ter permissão para usar um subconjunto dos recursos do aplicativo. Os recursos que os usuários específicos têm permissão para acessar, com base em suas licenças, às vezes são chamados de direito.

O código do aplicativo ou um sistema de direitos dedicados normalmente rastreia e impõe direitos em vez do sistema de identidade. Esse processo é semelhante à autorização, mas ocorre fora da camada de gerenciamento de identidade.

Escala de identidade e volume de autenticação

À medida que as soluções multilocatário crescem, o número de usuários e solicitações de login que a solução precisa processar aumenta. Considere os seguintes fatores:

  • Avalie se o diretório do usuário é dimensionado para dar suporte ao número necessário de usuários.

  • Avalie se o processo de autenticação consegue lidar com o número esperado de logins e inscrições.

  • Determine se há picos que o sistema de autenticação não pode manipular. Por exemplo, às 9h no Horário Padrão do Pacífico, todos no oeste dos Estados Unidos podem começar a trabalhar e fazer login na sua solução, o que cria um pico de solicitações de login. Esses cenários às vezes são chamados de tempestades de login.

  • Determine se a alta carga em partes da solução afeta o desempenho do processo de autenticação. Por exemplo, se a autenticação exigir a chamada para uma API de camada de aplicativo, um aumento nas solicitações de autenticação poderá afetar o desempenho geral do sistema.

  • Defina como sua solução se comporta se o IdP ficar indisponível. Considere se um serviço de autenticação de backup deve ser incluído para manter a continuidade dos negócios.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Principais autores:

Outros colaboradores:

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