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 por ambos os seguintes:

• Verificando quem é um usuário (autenticação).
• Aplicando as permissões do usuário dentro do escopo de um locatário (autorização).

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

Antes de definir uma estratégia de identidade multilocatário, você deve primeiro considerar os requisitos de identidade de alto nível do seu serviço, incluindo os seguintes requisitos:

• As identidades de usuário ou carga de trabalho serão usadas para acessar um único aplicativo ou vários aplicativos dentro de uma família de produtos? Por exemplo, uma família de produtos de varejo pode ter um aplicativo de ponto de venda e um aplicativo de gerenciamento de estoque, que compartilham a mesma solução de identidade.
• Você está planejando implementar autenticação e autorização modernas, como OAuth2 e OpenID Connect?
• Sua solução fornece autenticação apenas para seus aplicativos baseados em interface do usuário? Ou você também fornece acesso à API para seus locatários e terceiros?
• Os locatários precisarão se federar em seu próprio IdP e vários provedores de identidade diferentes precisarão ser suportados para cada locatário? Por exemplo, você pode ter locatários com Microsoft Entra ID, Auth0 e Serviços de Federação do Ative Directory (ADFS), onde cada um deseja federar com sua solução. Você também precisa entender quais protocolos de federação dos IdPs de seus locatários você suportará, porque os protocolos influenciam os requisitos para seu próprio IdP.
• Existem requisitos de conformidade específicos que eles precisam cumprir, como o GDPR?
• Os seus inquilinos exigem que as suas informações de identidade estejam localizadas numa região geográfica específica?
• Os usuários de sua solução precisam de acesso a dados de um locatário ou de vários locatários em seu aplicativo? Eles precisam da capacidade de alternar rapidamente entre locatários ou exibir informações consolidadas de vários locatários? Por exemplo, os usuários que entraram no portal do Azure podem alternar facilmente entre diferentes diretórios e assinaturas do Microsoft Entra ID aos quais têm acesso.

Depois de 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/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 autoritativos para cada identidade ou pode conter referências a identidades externas armazenadas no diretório de outro provedor de identidade.

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:

• Provedor de identidade local. Um provedor de identidade 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.
• Provedor de identidade social. Um provedor de identidade social permite que os usuários usem uma identidade que eles tenham em uma rede social ou outro provedor de identidade pública, como Facebook, Google ou uma conta pessoal da Microsoft.
• Use o diretório Microsoft Entra ID do locatário. 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 o provedor de identidade de um locatário. 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 experiências de logon único (SSO) e 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 seus locatários precisam oferecer suporte a vários provedores de identidade. Por exemplo, talvez seja necessário oferecer suporte a identidades locais, identidades sociais e identidades federadas, tudo dentro de um único locatário. Essa exigência é comum quando as empresas usam uma solução que é tanto para seus próprios funcionários quanto para contratados. Eles podem usar a federação para o acesso de seus próprios funcionários à solução, ao mesmo tempo em que permitem o acesso a contratantes ou a usuários convidados, que não têm uma conta 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 exigidas por seus locatários.
• Informações necessárias para autenticar seus usuários com segurança, incluindo informações necessárias para fornecer autenticação multifator (MFA).
• Informações específicas do locatário, como funções e permissões de locatário. Estas informações são utilizadas 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 e armazene as informações 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

É comum que soluções multilocatárias permitam que uma identidade de usuário ou carga de trabalho acesse o aplicativo e os dados de vários locatários. Considere se essa abordagem é necessária para sua solução. Se for, então você deve considerar as seguintes perguntas:

• Você deve criar uma única identidade de usuário para cada pessoa ou criar identidades separadas para cada combinação de locatário e usuário?
  • É melhor usar uma identidade única para cada pessoa, sempre que possível. Torna-se difícil gerenciar várias contas de usuário, tanto para você, como fornecedor da solução, quanto para seus usuários. Além disso, muitas das proteções inteligentes contra ameaças oferecidas por um IdP moderno dependem de cada pessoa ter uma única conta de usuário.
  • No entanto, em algumas situações, pode ser necessário que um usuário tenha várias identidades distintas. 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.
• Se você usar identidades por locatário, evite armazenar credenciais várias vezes. 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 os usuários serão mapeados para um locatário. Por exemplo, durante o processo de inscrição, você pode usar um código de convite exclusivo que eles inserem na primeira vez que acessam um locatário. Em algumas soluções, você pode usar o nome de domínio dos endereços de e-mail de inscrição dos usuários como uma forma de identificar o locatário ao qual eles pertencem. Ou, você pode usar outro atributo do registro de identidade do usuário para mapear o usuário para um locatário. Em seguida, você deve armazenar o mapeamento com base nos identificadores exclusivos imutáveis subjacentes para o locatário e o usuário.

Se sua solução foi projetada para que um único usuário só acesse os dados de um único locatário, considere as seguintes decisões:

• Como o IdP deteta qual locatário um usuário está acessando?
• Como o IdP comunica o identificador de locatário ao aplicativo? Geralmente, uma declaração de identificador de locatário é adicionada ao token.

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

• Como sua solução identifica e concede permissões a um usuário que tem acesso a vários locatários? Por exemplo, um usuário poderia ser um administrador em um locatário de treinamento e ter acesso somente leitura a um locatário de produção? Ou você poderia ter locatários separados para departamentos diferentes em uma organização, mas precisa manter identidades de usuário consistentes em todos os locatários?
• Como é que um utilizador alterna entre inquilinos?
• Se você usar identidades de carga de trabalho, como uma identidade de carga de trabalho especifica o locatário que precisa acessar?
• Há informações específicas do locatário armazenadas no registro de identidade do usuário que possam vazar informações entre locatários? 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?

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 provedor de identidade de um locatário. Se for necessário um processo de auto-inscrição, então você deve considerar as seguintes perguntas:

• Quais fontes de identidade os usuários podem se inscrever? Por exemplo, um usuário pode criar uma identidade local e também usar um provedor de identidade social?
• Se apenas identidades locais forem permitidas, apenas domínios de e-mail específicos serão permitidos? Por exemplo, um locatário pode especificar que apenas os usuários que têm um endereço de @contoso.com e-mail têm permissão para se inscrever?
• Qual é o nome principal do usuário (UPN) que deve ser usado para identificar exclusivamente cada identidade local durante o processo de entrada? Por exemplo, um endereço de e-mail, nome de usuário, número de telefone e número de cartão de recompensas são opções comuns para UPNs. No entanto, os UPNs podem mudar ao longo do tempo. Quando você se refere à identidade nas regras de autorização ou logs de auditoria do seu aplicativo, é uma boa prática usar o identificador exclusivo imutável subjacente da identidade. O Microsoft Entra ID fornece um ID de objeto (OID), que é um identificador imutável.
• Um usuário será obrigado a verificar seu UPN? Por exemplo, se o endereço de e-mail ou número de telefone do usuário for usado como um UPN, como você verificará se as informações estão corretas?
• Os administradores de locatários precisam aprovar inscrições?
• Os locatários exigem uma experiência de inscrição específica do locatário ou URL? Por exemplo, seus locatários exigem uma experiência de inscrição de marca quando os usuários se inscrevem? Seus locatários precisam da 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

Quando os usuários têm permissão para se inscrever para uma identidade, geralmente precisa haver um processo para que eles tenham acesso a um locatário. O fluxo de inscrição pode incluir um processo de concessão de acesso, ou pode ser automatizado, com base nas informações sobre os usuários, como seus endereços de e-mail. É importante planejar esse processo e considerar as seguintes perguntas:

• Como o fluxo de inscrição determinará que um usuário deve ter acesso a um locatário específico?
• Se os usuários não tiverem mais acesso a um locatário, sua solução revogará automaticamente o acesso deles? Por exemplo, quando os usuários saem de uma organização, precisa haver um processo manual ou automatizado que remova seu acesso do locatário.
• Você precisa fornecer uma maneira para os locatários auditarem os usuários que têm acesso a seus locatários e suas permissões?

Gerenciamento automatizado do ciclo de vida da conta

Um requisito comum para clientes corporativos ou corporativos de uma solução é um conjunto de recursos que lhes permite automatizar a integração e o desembarque 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 não apenas a criação e remoção de registros de identidade, mas também o gerenciamento de permissões de locatário. Considere as seguintes perguntas ao implementar o gerenciamento automatizado do ciclo de vida da conta em uma solução multilocatário:

• Seus clientes precisam configurar e gerenciar um processo de ciclo de vida automatizado por 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.
• Você precisa implementar o SCIM, ou pode fornecer federação de locatários em vez disso, para manter a fonte da verdade para os usuários sob o controle do locatário, em vez de gerenciar usuários locais?

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. Você deve considerar as seguintes perguntas ao planejar seu processo de autenticação:

• Seus locatários precisam configurar suas próprias políticas de autenticação multifator (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.
• Seus locatários precisam configurar suas próprias regras de acesso condicional? Por exemplo, diferentes locatários podem precisar bloquear tentativas de entrada de regiões geográficas específicas.
• Os seus inquilinos precisam de personalizar o processo de início de sessão para cada inquilino? Por exemplo, você precisa mostrar o logotipo de um cliente? Ou as informações sobre cada usuário precisam ser extraídas de outro sistema, como um número de recompensas, e retornadas ao provedor de identidade para adicionar ao perfil do usuário?
• Seus usuários precisam 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.
• Seus usuários precisam obter acesso às APIs para sua solução? Por exemplo, os usuários ou aplicativos de terceiros podem precisar chamar diretamente suas APIs para estender sua solução, sem uma interface de usuário para fornecer um fluxo de autenticaçã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 sua solução, para que possam automatizar algumas de suas tarefas de gerenciamento.

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 esperam ser capazes de habilitar o acesso de identidade de carga de trabalho à sua solução multilocatário, você deve considerar as seguintes perguntas:

• Como as identidades de carga de trabalho serão criadas e gerenciadas em cada locatário?
• Como as solicitações de identidade de carga de trabalho serão definidas para o locatário?
• Você precisa limitar o número de identidades de carga de trabalho criadas por cada locatário?
• Você precisa fornecer controles de acesso condicional em identidades de carga de trabalho para 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.
• Quais controles de segurança você fornecerá aos locatários para garantir que as identidades de carga de trabalho sejam mantidas 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 são métodos para reduzir o risco, onde uma identidade de carga de trabalho pode ser usada indevidamente.

Federar com um provedor de identidade para logon único (SSO)

Os locatários, que já têm seus próprios diretórios de usuário, podem querer que sua solução seja federada para 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 é particularmente importante quando alguns locatários desejam especificar suas próprias políticas de identidade ou habilitar experiências de logon único (SSO).

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

• Qual é o processo para configurar a federação para um locatário? Os locatários podem configurar a federação por conta própria ou o processo requer configuração e manutenção manuais por sua equipe?
• Quais protocolos de federação você apoiará?
• Quais processos estão em vigor para garantir que a federação não possa ser configurada incorretamente, para conceder acesso a outro locatário?
• O provedor de identidade de um único locatário precisará ser federado para mais de um locatário em sua solução? Por exemplo, se os clientes tiverem um locatário de treinamento e produção, talvez precisem federar o mesmo provedor de identidade para ambos os locatários.

Modelos de autorização

Decida o modelo de autorização que faz mais sentido para a sua solução. Duas abordagens comuns de autorização sã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. Você forneceria diferentes níveis de licenças de usuário com 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.

Embora o rastreamento e a aplicação de direitos sejam semelhantes à autorização, normalmente são tratados pelo código do aplicativo ou por um sistema de direitos dedicado, em vez de gerenciados pelo sistema de identidade.

Escala de identidade e volume de autenticação

À medida que as soluções multilocatárias crescem, o número de usuários e solicitações de entrada que precisam ser processados pela solução aumentará. Você deve considerar as seguintes perguntas:

• O diretório de usuários será dimensionado para o número de usuários necessários?
• O processo de autenticação lidará com o número esperado de entradas e inscrições?
• Haverá picos que o sistema de autenticação não consegue lidar? Por exemplo, às 9h PST, todos na região oeste dos Estados Unidos podem começar a trabalhar e entrar na sua solução, causando um pico nas solicitações de login. Essas situações às vezes são chamadas de tempestades de login.
• A alta carga em outras partes da sua solução pode afetar o desempenho do processo de autenticação? Por exemplo, se o processo de autenticação exigir a chamada para uma API da camada de aplicativo, um grande número de solicitações de autenticação causará problemas para o restante da solução?
• O que acontecerá se o seu IdP ficar indisponível? Existe um serviço de autenticação de backup que possa assumir o controle para fornecer continuidade de negócios, enquanto o IdP não estiver disponível?

Contribuidores

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

Principais autores:

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

Outros contribuidores:

• Jelle Druyts - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Landon Pierce - Brasil | Engenheiro de Clientes Sênior
• Sander van den Hoven - Brasil | Estrategista Sênior de Tecnologia de Parceiros
• Nick Ward - Brasil | Arquiteto de Soluções Cloud Sênior

Próximos passos

Revisão de abordagens arquitetônicas para identidade em soluções multilocatário.