Mapear solicitações para locatários em uma solução multilocatário

Sempre que uma solicitação chega ao aplicativo, você precisa determinar o contexto do locatário, que é o locatário que está fazendo a solicitação. Quando você tem uma infraestrutura específica de locatário que pode ser hospedada em diferentes regiões geográficas, você precisa corresponder a solicitação de entrada a um locatário. Em seguida, você deve encaminhar a solicitação para a infraestrutura física que hospeda os recursos desse locatário, conforme ilustrado no diagrama a seguir:

Muitos aplicativos multilocatários também têm permissões baseadas no usuário. O mapeamento de locatário é uma atividade separada. Você precisa conhecer o usuário que está fazendo a solicitação e o locatário no qual está trabalhando.

Este artigo fornece diretrizes para tomadores de decisão técnicos sobre as abordagens que você pode considerar para mapear solicitações para o locatário apropriado e as compensações envolvidas nas abordagens.

Abordagens para identificar locatários

Há várias maneiras de identificar o locatário para uma solicitação de entrada. Cada abordagem requer inspecionar algum aspecto da solicitação de entrada.

Nomes de domínios

Se você usar nomes de domínio ou subdomínio específicos do locatário, é provável que as solicitações possam ser facilmente mapeadas para locatários usando o Host cabeçalho, o X-Forwarded-Host cabeçalho ou outro cabeçalho HTTP que inclui o nome do host original para cada solicitação.

No entanto, considere as seguintes perguntas:

• Como os usuários saberão qual nome de domínio usar para acessar o serviço?
• Você tem um ponto de entrada central, como uma página de aterrissagem ou página de logon, que todos os locatários usam? Se você fizer isso, como os usuários selecionarão o locatário com o qual estão trabalhando?
• Quais outras informações você está usando para verificar o acesso aos recursos do locatário, como tokens de autorização? Os tokens de autorização incluem os nomes de domínio específicos do locatário?

Propriedades de solicitação HTTP

Se você não usar nomes de domínio específicos do locatário, ainda poderá usar aspectos da solicitação HTTP para identificar o locatário para o qual uma solicitação específica é. Por exemplo, considere uma solicitação HTTP que identifica o nome do locatário como tailwindtraders. Isso pode ser comunicado usando uma das seguintes abordagens:

• A estrutura do caminho da URL, como https://app.contoso.com/tailwindtraders/.
• Uma cadeia de caracteres de consulta na URL, como https://contoso.com/app?tenant=tailwindtraders.
• Um cabeçalho de solicitação HTTP personalizado, como Tenant-Id: tailwindtraders.

Ao usar essa abordagem, você deve considerar as seguintes perguntas:

• Os usuários saberão como acessar o serviço? Por exemplo, se você usar uma cadeia de caracteres de consulta para identificar locatários, uma página de aterrissagem central precisará direcionar os usuários para a página do locatário correto adicionando a cadeia de caracteres de consulta?
• Você tem um ponto de entrada central, como uma página de aterrissagem ou página de logon, que todos os locatários usam? Se você fizer isso, como os usuários selecionarão o locatário que precisam acessar?
• Seu aplicativo fornece APIs? Por exemplo, seu aplicativo Web é um SPA (aplicativo de página única) ou um aplicativo móvel com um back-end de API? Se for, talvez você possa usar um gateway de API ou proxy reverso para executar o mapeamento de locatário.

Reivindicações de Token

Muitos aplicativos usam protocolos de autenticação e autorização baseados em declarações, como OAuth 2.0 ou SAML. Esses protocolos fornecem tokens de autorização para o cliente. Um token contém um conjunto de declarações, que são partes de informações sobre o aplicativo cliente ou o usuário. As declarações podem ser usadas para comunicar informações como o endereço de email de um usuário. Em seguida, seu sistema pode incluir o endereço de email do usuário, pesquisar o mapeamento de usuário para locatário e encaminhar a solicitação para a implantação apropriada. Ou você pode até incluir o mapeamento de locatário em seu sistema de identidade e adicionar uma declaração de ID de locatário ao token.

Se você estiver usando declarações para mapear solicitações para locatários, considere as seguintes perguntas:

• Você usará uma declaração para identificar um locatário? Qual declaração você usará?
• Um usuário pode ser membro de vários locatários? Se isso for possível, como os usuários selecionarão o locatário com o qual gostariam de trabalhar para uma solicitação específica?
• Há um sistema central de autenticação e autorização para todos os locatários? Caso contrário, como você garantirá que todas as autoridades de token emitam tokens e declarações consistentes?

Chaves de API

Muitos aplicativos expõem APIs. Isso pode ser para uso interno em sua organização ou para uso externo por parceiros ou clientes. Um método comum de autenticação para APIs é usar uma chave de API. As chaves de API são fornecidas com cada solicitação. Se você registrar a ID do locatário para a qual uma chave foi emitida, poderá procurar a ID do locatário quando a chave for usada.

As chaves de API podem ser geradas de várias maneiras. Aqui estão duas abordagens comuns:

• Gere um valor aleatório criptograficamente e armazene-o em uma tabela de pesquisa, juntamente com a ID do locatário. Quando uma solicitação é recebida, seu sistema localiza a chave de API na tabela de pesquisa e a corresponde a uma ID de locatário.
• Crie uma cadeia de caracteres significativa com uma ID de locatário incluída dentro dela. Assine digitalmente a chave usando uma abordagem como o HMAC. Ao processar cada solicitação, você verifica a assinatura e, em seguida, extrai a ID do locatário.

Considere as seguintes perguntas:

• Como você gerará e emitirá chaves de API?
• Como seus clientes de API receberão e armazenarão com segurança a chave de API?
• Você precisa que suas chaves de API expirem após um período de tempo? Como você girará as chaves de API dos clientes sem causar tempo de inatividade?
• As chaves de API geradas pelo cliente fornecem um nível adequado de segurança para suas APIs?

Certificados de cliente

A autenticação de certificado do cliente, às vezes chamada de TLS mútua (mTLS), é comumente usada para comunicação serviço a serviço e para dispositivos autônomos ou quiosques usados por usuários não autenticados. Os certificados do cliente fornecem uma maneira segura de autenticar clientes. Da mesma forma que tokens e declarações, os certificados do cliente fornecem atributos que podem ser usados para determinar o locatário. Por exemplo, o assunto do certificado pode conter o endereço de email do usuário, que pode ser usado para pesquisar o locatário.

Ao planejar o uso de certificados de cliente para mapeamento de locatário, considere os seguintes fatores:

• Como você emitirá e renovará com segurança os certificados de cliente confiáveis pelo seu serviço? Os certificados do cliente podem ser complexos para trabalhar, pois exigem infraestrutura especial para gerenciar e emitir certificados. Se tratadas incorretamente, essas complexidades podem reduzir sua segurança em vez de aumentá-la.
• Os certificados do cliente serão usados apenas para solicitações de logon iniciais ou anexados a todas as solicitações ao seu serviço?
• O processo de emissão e gerenciamento de certificados se tornará incontrolável quando você tiver um grande número de clientes?
• Como você implementará o mapeamento entre o certificado do cliente e o locatário?

Proxies reversos

Um proxy reverso, também conhecido como proxy de aplicativo, pode ser usado para rotear solicitações HTTP. Um proxy reverso aceita uma solicitação de um ponto de extremidade de entrada e pode encaminhar a solicitação para um dos muitos pontos de extremidade de back-end. Proxies reversos são úteis para aplicativos multilocatários, pois podem executar o mapeamento entre algumas informações de solicitação, descarregando a tarefa da infraestrutura do aplicativo.

Muitos proxies reversos podem usar as propriedades de uma solicitação para tomar uma decisão sobre o roteamento de locatário. Eles podem inspecionar o nome de domínio de destino, o caminho da URL, a cadeia de caracteres de consulta, os cabeçalhos HTTP e até mesmo as declarações dentro de tokens ou partes do corpo da solicitação.

Os seguintes proxies reversos comuns são usados no Azure:

• O Azure Front Door é um balanceador de carga global e firewall de aplicativo Web. Ele usa a rede de borda global da Microsoft para criar aplicativos Web rápidos, seguros e altamente escalonáveis. Você pode usar conjuntos de regras para extrair identificadores de locatário e colocá-los em outra parte da solicitação.
• O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego web gerenciado que você implanta na mesma região física que o serviço de back-end.
• O Gerenciamento de API do Azure é otimizado para tráfego de API. O Gerenciamento de API do Azure fornece um mecanismo abrangente de políticas que oferece muita flexibilidade para extrair informações de inquilinos das solicitações.
• As tecnologias comerciais e de software livre (que você hospeda por conta própria) incluem nginx, Traefik e HAProxy.

Validação de solicitação

É importante que seu aplicativo valide se todas as solicitações recebidas são autorizadas para o locatário. Por exemplo, se seu aplicativo usa um nome de domínio personalizado para mapear solicitações para o locatário, seu aplicativo ainda deve verificar se cada solicitação recebida pelo aplicativo está autorizada para esse locatário. Embora a solicitação inclua um nome de domínio ou outro identificador de locatário, isso não significa que você deve conceder acesso automaticamente. Ao usar o OAuth 2.0, você executa a validação inspecionando o público-alvo e as declarações de escopo .

Ao implementar a validação de solicitação, considere os seguintes fatores:

• Como você autorizará todas as solicitações para seu aplicativo? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
• Use estruturas de autenticação e autorização confiáveis, amplamente usadas e bem mantidas e middleware, em vez de implementar toda a lógica de validação por conta própria. Por exemplo, não crie lógica de validação de assinatura de token ou bibliotecas de criptografia de certificado do cliente. Em vez disso, use recursos da plataforma de aplicativo (ou pacotes confiáveis conhecidos) que foram validados e testados.

Performance

A lógica de mapeamento de locatário provavelmente é executada em cada solicitação para seu aplicativo. Considere o quão bem o processo de mapeamento de locatário será dimensionado à medida que sua solução crescer. Por exemplo, se você consultar uma tabela de banco de dados como parte do mapeamento de locatário, o banco de dados dará suporte a uma grande quantidade de carga? Se o mapeamento de locatário exigir a descriptografia de um token, os requisitos de computação se tornarão muito altos ao longo do tempo? Se o tráfego for bastante modesto, isso provavelmente não afetará seu desempenho geral. No entanto, quando você tem um aplicativo de alta escala, a sobrecarga envolvida nesse mapeamento pode se tornar significativa.

Cookies de sessão

Uma abordagem para reduzir a sobrecarga de desempenho da lógica de mapeamento de locatário é usar cookies de sessão. Em vez de executar o mapeamento em cada solicitação, considere calcular as informações apenas na primeira solicitação para cada sessão. Em seguida, seu aplicativo fornece um cookie de sessão para o cliente. O cliente passa o cookie de sessão de volta para seu serviço com todas as solicitações de cliente subsequentes dentro dessa sessão.

Considere as seguintes perguntas:

• Você pode usar cookies de sessão para reduzir a sobrecarga de solicitações de mapeamento para locatários?
• Quais serviços você usa para rotear solicitações para as implantações físicas para cada locatário? Esses serviços dão suporte a sessões baseadas em cookie?

Migração de locatário

Os locatários geralmente precisam ser movidos para uma nova infraestrutura como parte do ciclo de vida do locatário. Quando um locatário é movido para uma nova implantação, os pontos de extremidade HTTP acessados podem ser alterados. Quando isso acontecer, considere que o processo de mapeamento de locatário precisa ser alterado. Talvez seja necessário considerar os seguintes fatores:

• Se o aplicativo usar nomes de domínio para solicitações de mapeamento, ele também poderá exigir uma alteração de DNS no momento da migração. A alteração de DNS pode levar tempo para ser propagada para os clientes, dependendo do TTL (tempo de vida útil) das entradas DNS em seu serviço DNS.
• Se a migração alterar os endereços de quaisquer pontos de extremidade durante o processo de migração, considere redirecionar temporariamente as solicitações do locatário para uma página de manutenção que é atualizada automaticamente.

Contributors

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Daniel Scott-Raynsford | Estrategista de Tecnologia Do Parceiro

Outros colaboradores:

• John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas
• Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

Saiba mais sobre considerações ao trabalhar com nomes de domínio em um aplicativo multilocatário.