Considerações arquitetônicas para identidade em uma solução multilocatária

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

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

• Impondo 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 dados entre locatários.

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

• Determine se os usuários ou identidades 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 vários IdPs devem ser suportados para cada locatário. Por exemplo, pode ter inquilinos com Microsoft Entra ID, Auth0 e Active Directory Federation Services, em que cada inquilino se federará com a sua solução. Identifique quais protocolos de federação seus IdPs usam porque esses protocolos determinam o que seu IdP deve suportar.

• Analise todos os requisitos de conformidade aplicáveis que eles precisam atender, como o Regulamento Geral de Proteção de Dados (GDPR), 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 no aplicativo. Se isso acontecer, talvez seja necessário oferecer suporte à troca contínua de locatários ou fornecer exibições consolidadas entre locatários para usuários específicos. Por exemplo, os usuários que entram no portal do Azure podem alternar facilmente entre diferentes diretórios e assinaturas do Microsoft Entra ID aos 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 de usuários e fluxos de inscrição e entrada.

Diretório de identidade

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

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

• 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 e-mail ou um identificador, como um número de cartão de recompensas. Eles também fornecem uma credencial, como uma senha. O IdP armazena o identificador de usuário e as credenciais.

• IdP Social: Um IdP social permite que os usuários usem uma identidade que eles tenham 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 entre empresas e consumidores (B2C).

• Diretório de ID do Microsoft Entra do locatário: Em muitas soluções SaaS entre empresas (B2B), os locatários podem já ter seu próprio diretório de ID do Microsoft Entra e podem querer que sua solução use seu diretório como o IdP para acessar sua solução. Essa abordagem é possível quando sua solução é criada como um aplicativo Microsoft Entra multilocatário.

• Federação com IdP de um inquilino: Em algumas soluções SaaS B2B, os locatários podem ter seu próprio IdP, diferente do Microsoft Entra ID, e podem querer que sua solução se federar com ele. A federação permite o logon único (SSO). 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 sua solução.

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

Armazenar informações de autenticação e autorização de 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 e permissões de locatário, para autorização.

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 vários locatários.

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

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

As soluções multilocatárias 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 de locatário e usuário.

  • Use uma única identidade para cada pessoa sempre que possível. Ele simplifica o gerenciamento de contas para o provedor de soluções e 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, elas podem querer separar suas contas de usuário. Ou se os seus inquilinos tiverem requisitos regulamentares ou geográficos rigorosos de armazenamento de dados, 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 dos registros de identidade de vários 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 e-mail de inscrição do usuário pode identificar seu locatário associado. Como alternativa, pode-se usar outro atributo do registo de identidade do utilizador para determinar o mapeamento do tenant. Essa associação deve ser armazenada com base em identificadores exclusivos imutáveis para o locatário e o usuário.

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

• Determine como o IdP deteta qual locatário um usuário acessa.

• Explique 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 oferecer 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, em seguida, recebeu acesso a dois locatários. O locatário A enriqueceu a identidade do usuário com mais informações. O inquilino B deve ter acesso à informação enriquecida?

• Um mecanismo claro deve permitir que os utilizadores alternem entre inquilinos. Essa abordagem garante uma experiência de usuário suave e evita o acesso acidental entre locatários.

• As identidades de carga de trabalho, se as utilizar, devem especificar qual locatário elas estão tentando acessar. Esse requisito pode incluir a incorporaçã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 de usuário, determine se o Locatário B deve ter acesso a essas informações enriquecidas.

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

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

• Defina quais fontes de identidade os usuários têm permissão para se inscrever. Por exemplo, determine se os usuários podem criar uma identidade local e também usar um IdP social.

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

• O nome principal do usuário (UPN) usado para identificar identidades locais deve ser claramente estabelecido. UPNs comuns incluem endereços de e-mail, 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 do 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 e-mail ou número de telefone antes de conceder acesso.

• Algumas soluções podem exigir que os administradores de locatários aprovem as inscrições de usuários. Esse processo de aprovação permite o controlo administrativo sobre quem adere a um inquilino.

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

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

Se os usuários puderem se inscrever para obter uma identidade, defina um processo para conceder acesso a um locatário. O fluxo de inscrição pode incluir um processo manual de concessão de acesso ou um processo automatizado baseado nas informações sobre os usuários, como seus endereços de e-mail. É 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 para remover seu acesso.

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

Gestão automatizada do ciclo de vida da conta

Um requisito comum para clientes corporativos ou empresariais de uma solução é um conjunto de funcionalidades que lhes permite automatizar a integração e a remoção de contas. Protocolos abertos, como o System for Cross-Domain Identity Management (SCIM), 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 seus clientes precisam configurar e gerenciar um processo de ciclo de vida automatizado para cada locatário. Por exemplo, quando um usuário é integrado, talvez seja necessário criar a identidade em vários locatários em seu aplicativo, onde cada locatário tem um conjunto diferente de permissões.

• Determine se você precisa implementar o SCIM ou oferecer federação. A federação permite que os locatários mantenham o controle sobre o gerenciamento de usuários, mantendo a fonte da verdade em seus próprios sistemas, em vez de gerenciar usuários locais em sua solução.

Processo de autenticação do 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, eles precisarão implementar políticas rígidas de MFA, enquanto um pequeno varejista on-line pode não ter os mesmos requisitos.

• A opção para 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 pode ser necessário recuperar informações do usuário, como um número de recompensas, de outro sistema e devolvê-las ao IdP para enriquecer o perfil do usuário.

• Alguns usuários podem precisar se passar por outros usuários. Por exemplo, um membro da equipe de suporte pode querer investigar um problema que outro usuário tem personificando sua conta de usuário sem ter que 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, seus locatários podem precisar acessar uma API fornecida pela solução para que possam automatizar suas tarefas de gerenciamento.

O Microsoft Entra suporta identidades de carga de trabalho, e outros IdPs também costumam oferecê-las.

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 exigem outros controles de segurança, como a rolagem regular de chaves e a expiração de certificados.

Se seus locatários puderem habilitar o acesso de identidade de carga de trabalho à 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 da carga de trabalho são definidas para o inquilino.

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

• Determine se os controles de acesso condicional são necessários 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 de 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 risco de entrada ajudam a reduzir o risco de uso indevido da identidade da carga de trabalho.

Federar com um IdP para SSO

Os locatários que já têm os seus próprios diretórios de utilizador podem querer que a sua solução se federe aos 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 se 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 suporta.

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

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

Modelos de autorização

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

• Autorização baseada em funções: 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 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 licenças

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 usuários específicos têm permissão para acessar, com base em suas licenças, às vezes é chamado de direito.

Recomendamos que acompanhe e faça cumprir os direitos dentro do seu código de candidatura ou num sistema dedicado de direitos, em vez de depender do sistema de identidade. Esse processo é semelhante à autorização, mas ocorre fora da camada de gerenciamento de identidade.

Existem várias razões para esta separação:

• Complexidade dos modelos de licenciamento: As regras de licenciamento são frequentemente complexas e específicas para o modelo de negócio. Por exemplo, as licenças podem ser por lugar, baseadas no tempo (atribuição diária ou mensal), limitar o uso simultâneo ou ter regras específicas de reatribuição. Os fornecedores de identidade são geralmente concebidos para autenticação de utilizadores e autorização básica, não para lógica complexa de licenciamento comercial.

• Independência: Depender das funcionalidades do fornecedor de identidade para a gestão de licenças pode prender a sua solução a esse fornecedor ou às suas restrições. Se der apoio a clientes que usam diferentes fornecedores de identidade, terá de construir uma solução personalizada para eles de qualquer maneira.

Um padrão comum é gerir licenças dentro da base de dados da aplicação ou de um serviço dedicado. Quando um utilizador inicia sessão, o fornecedor de identidade recupera os seus direitos e injeta-os no token de autorização como reivindicações personalizadas que podem ser verificadas pelos componentes da aplicação em tempo de execução.

Escala de identidade e volume de autenticação

À medida que as soluções multilocatárias crescem, aumenta o número de usuários e solicitações de entrada que a solução precisa processar. Avalie estas considerações de escalabilidade:

• Avalie se o diretório de usuários é dimensionado para suportar o número necessário de usuários.

• Avalie se o processo de autenticação lida com o número esperado de entradas e inscrições.

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

• Determine se a alta carga em partes da sua 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 comportará 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.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
• Daniel Scott-Raynsford | Estrategista de Tecnologia para Parceiros
• Arsen Vladimirskiy | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

• Jelle Druyts | Engenheiro de Clientes Principal, FastTrack for Azure
• Landon Pierce | Engenheiro de Clientes Senior
• Sander van den Hoven | Senior Estrategista de Tecnologia de Parceiros
• Nick Ward | Arquiteto de Soluções em Nuvem Senior

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Recurso relacionado

• Abordagens arquitetónicas para identidade em soluções multi-inquilino