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

Sempre que um pedido chega à sua aplicação, precisa de determinar o contexto do tenant, que é o tenant que está a fazer o pedido. Quando tem uma infraestrutura específica para o locatário que pode estar alojada em diferentes regiões geográficas, precisa de associar o pedido recebido a um locatário. Depois, deve encaminhar o pedido para a infraestrutura física que aloja os recursos desse inquilino, como ilustrado no diagrama seguinte:

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

Este artigo fornece orientação para os tomadores de decisão técnica 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 inquilinos

Há várias maneiras de identificar o locatário para uma solicitação de entrada. Cada abordagem requer a inspeção de algum aspeto da solicitação recebida.

Nomes de domínio

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 inclua o nome de 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 destino ou página de login, 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?
• Que 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 aspetos da solicitação HTTP para identificar o locatário para o qual uma solicitação específica se destina. Por exemplo, considere uma solicitação HTTP que identifique o nome do locatário como tailwindtraders. Isto pode ser comunicado através de 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 esta abordagem, deve considerar as seguintes questões:

• Os utilizadores saberão como aceder ao serviço? Por exemplo, se você usar uma cadeia de caracteres de consulta para identificar locatários, uma página de destino 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 destino ou página de login, 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 aplicativo de página única (SPA) ou um aplicativo móvel com um back-end de API? Se for, pode ser possível usar um gateway API ou um proxy reverso para fazer o mapeamento de inquilino.

Reivindicações de tokens

Muitos aplicativos usam autenticação baseada em declarações e protocolos de autorização, como OAuth 2.0 ou SAML. Esses protocolos fornecem tokens de autorização para o cliente. Um token contém um conjunto de reivindicações, que são pedaços de informação sobre a aplicação cliente ou o utilizador. As declarações podem ser usadas para comunicar informações como o endereço de e-mail de um usuário. Seu sistema pode então incluir o endereço de e-mail do usuário, procurar o mapeamento de usuário para locatário e, em seguida, 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 reivindicação para identificar um inquilino? Que alegação irá utilizar?
• 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 quem gostariam de trabalhar para uma solicitação específica?
• Existe um sistema central de autenticação e autorização para todos os inquilinos? Se não, como você garantirá que todas as autoridades de token emitam tokens e declarações consistentes?

Chaves de API

Muitos aplicativos expõem APIs. Estes podem ser para uso interno dentro da sua organização ou para uso externo por parceiros ou clientes. Um método comum de autenticação para APIs é usar uma chave 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 criptograficamente aleatório e armazene-o em uma tabela de pesquisa, ao lado do ID do locatário. Quando uma solicitação é recebida, seu sistema encontra a chave de API na tabela de pesquisa e, em seguida, ela faz a correspondência com uma ID de locatário.
• Crie uma cadeia de caracteres significativa com um ID de locatário incluído dentro dela. Assine digitalmente a chave usando uma abordagem como a HMAC. Ao processar cada solicitação, você verifica a assinatura e, em seguida, extrai a ID do locatário.

Considere as perguntas seguintes:

• Como você vai gerar e emitir chaves de API?
• Como seus clientes de API receberão e armazenarão a chave de API com segurança?
• Você precisa que suas chaves de API expirem após um período de tempo? Como você vai girar as chaves de API de seus 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 de cliente, às vezes chamada de TLS mútuo (mTLS), é comumente usada para comunicação de serviço a serviço e para dispositivos autônomos ou quiosques usados por usuários não autenticados. Os certificados de cliente fornecem uma maneira segura de autenticar clientes. De forma semelhante aos tokens e reivindicações, os certificados de cliente fornecem atributos que podem ser usados para determinar o inquilino. Por exemplo, o assunto do certificado pode conter o endereço de email do utilizador, que pode ser usado para consultar o inquilino.

Ao planear usar certificados de clientes para mapeamento de inquilinos, considere os seguintes fatores:

• Como você emitirá e renovará com segurança os certificados de cliente confiáveis pelo seu serviço? Os certificados de cliente podem ser complexos de trabalhar, uma vez que requerem uma infraestrutura especial para gerenciar e emitir certificados. Se forem mal tratadas, estas complexidades podem reduzir a sua segurança em vez de a aumentar.
• Os certificados de cliente serão usados apenas para solicitações iniciais de login ou anexados a todas as solicitações ao seu serviço?
• O processo de emissão e gestão de certificados tornar-se-á incontrolável quando 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. Os proxies reversos são úteis para aplicativos multilocatário, 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 do 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 escaláveis. Pode usar conjuntos de regras para extrair identificadores de cliente e colocá-los noutra parte da solicitação.
• O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web gerenciado que você implanta na mesma região física do seu serviço de back-end.
• O Gerenciamento de API do Azure é otimizado para o tráfego da API. O Azure API Management fornece um motor de políticas abrangente que proporciona grande flexibilidade para extrair informação dos inquilinos a partir dos pedidos.
• As tecnologias comerciais e de código aberto (que você mesmo hospeda) incluem nginx, Traefik e HAProxy.

Validação do pedido

É 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 é 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ê deva conceder acesso automaticamente. Quando usa o OAuth 2.0, realiza a validação inspecionando as claims de audiência e as claims de escopo.

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

• Como irá autorizar todos os pedidos à sua candidatura? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
• Use estruturas e middleware de autenticação e autorização confiáveis, amplamente utilizados e bem conservados, 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 de cliente. Em vez disso, use recursos da sua 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 todas as solicitações ao seu aplicativo. Considere o quão bem o processo de mapeamento de locatários será dimensionado à medida que sua solução cresce. Por exemplo, se você consultar uma tabela de banco de dados como parte do mapeamento de locatário, o banco de dados suportará uma grande quantidade de carga? Se o mapeamento do locatário exigir a descriptografia de um token, os requisitos de computação se tornarão muito altos com o tempo? Se o seu tráfego for bastante modesto, isso provavelmente não afetará seu desempenho geral. Quando você tem um aplicativo de alta escala, no entanto, 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 inquilinos é 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 de cada sessão. Em seguida, a sua aplicação fornece um cookie de sessão ao cliente. O cliente passa o cookie de sessão de volta para o seu serviço com todas as solicitações subsequentes do cliente dentro dessa sessão.

Considere as perguntas seguintes:

• 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 de cada locatário? Estes serviços suportam sessões baseadas em cookies?

Migração de inquilinos

Os inquilinos muitas vezes precisam de ser transferidos para novas infraestruturas como parte do ciclo de vida do inquilino. Quando um locatário é movido para uma nova implantação, os pontos de extremidade HTTP que eles acessam podem mudar. Quando isso acontecer, considere que o processo de mapeamento do locatário precisa mudar. Pode ser necessário considerar os seguintes fatores:

• Se seu aplicativo usa nomes de domínio para mapear solicitações, ele também pode exigir uma alteração de DNS no momento da migração. A alteração de DNS pode levar algum tempo para se propagar para os clientes, dependendo do tempo de vida (TTL) das entradas DNS no 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 seja atualizada automaticamente.

Contributors

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

Autor principal:

• Daniel Scott-Raynsford | Estrategista de Tecnologia para Parceiros

Outros contribuidores:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
• Paolo Salvatori | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro de Clientes Principal, FastTrack for Azure

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

Próximos passos

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