Mapear pedidos para inquilinos numa solução multicliente

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:

Muitas aplicações multilocadas também têm permissões baseadas no utilizador. O mapeamento de inquilinos é uma atividade separada. Você precisa de saber tanto o utilizador que está a fazer a solicitação quanto o tenant no qual ele está a trabalhar.

Este artigo fornece orientação para os decisores técnicos sobre as abordagens que pode considerar para mapear pedidos para o inquilino apropriado e as contrapartidas envolvidas nas abordagens.

Abordagens para identificar locatários

Há várias maneiras de identificar o tenant para um pedido recebido. Cada abordagem requer a inspeção de algum aspeto do pedido recebido.

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 tenants usam? Se você fizer isso, como os usuários selecionarão o tenant com o qual estão trabalhando?
• Que outras informações está a usar 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 do pedido 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 um pedido HTTP que identifique o nome do inquilino 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 utilizar uma query string para identificar inquilinos, uma página de destino central precisará de direcionar os utilizadores para a página do inquilino correto adicionando a query string?
• Você tem um ponto de entrada central, como uma página de destino ou página de login, que todos os inquilinos usam? Se você fizer isso, como os usuários selecionarão o tenant que precisam de aceder?
• A sua aplicação fornece APIs? Por exemplo, a sua aplicação Web é uma aplicação de página única (SPA) ou uma aplicação 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

Muitas aplicações usam autenticação baseada em afirmaçõ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 claims podem ser usadas para comunicar informações como o endereço de e-mail de um usuário. O seu sistema pode então incluir o endereço de e-mail do utilizador, procurar o mapeamento do utilizador para o tenant e, em seguida, encaminhar o pedido para o deployment adequado. Ou pode até incluir o mapeamento de locatários no seu sistema de identidade e adicionar uma claim de ID de locatário ao token.

Se você estiver usando claims para mapear solicitações para inquilinos, considere as seguintes perguntas:

• Você usará uma declaração para identificar um inquilino? Que reclamação irá utilizar?
• Um usuário pode ser membro de vários inquilinos? Se isso for possível, como os utilizadores selecionarão o inquilino com quem gostariam de trabalhar para um pedido específico?
• Existe um sistema central de autenticação e autorização para todos os locatários? Se não, como 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ê registar a ID do locatário para a qual uma chave foi emitida, poderá então procurar a ID do locatário quando a chave 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 numa tabela de consulta, ao lado do ID do inquilino. Quando um pedido é recebido, o seu sistema encontra a chave de API na tabela de pesquisa e depois associa-a a um ID de tenant.
• 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, verifica-se a assinatura e, em seguida, extrai-se o ID do locatário.

Considere as perguntas seguintes:

• Como vai gerar e emitir chaves de API?
• Como os seus clientes de API receberão e armazenarão a chave de API com segurança?
• Precisa que as suas chaves de API expirem após um período de tempo? Como vai efetuar a rotação das chaves de API dos seus clientes, sem causar indisponibilidade?
• As chaves de API geradas pelo cliente fornecem um nível adequado de segurança para as 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 irá emitir e renovar em segurança os certificados de cliente em que o seu serviço confia? Os certificados de cliente podem ser complexos de utilizar, uma vez que requerem uma infraestrutura especial para gerir 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 irá implementar o mapeamento entre o certificado do cliente e o tenant?

Proxies reversos

Um proxy reverso, também conhecido como proxy de aplicativo, pode ser usado para rotear solicitações HTTP. Um proxy reverso aceita um pedido de um ponto final de entrada e pode encaminhar o pedido para um dos muitos pontos finais de back-end. Os proxies reversos são úteis para aplicações multi-inquilino, pois podem executar o mapeamento entre algum elemento da informação do pedido, retirando essa tarefa da sua infraestrutura aplicacional.

Muitos proxies reversos podem usar as propriedades de um pedido para tomar uma decisão sobre o roteamento do inquilino. 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 claims dentro de tokens ou partes do corpo do pedido.

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 aplicações Web rápidas, seguras e altamente escaláveis. Pode usar conjuntos de regras para extrair identificadores de cliente e colocá-los noutra parte da solicitação.
• Gateway de Aplicação do Azure é um balanceador de carga de tráfego da Web gerido que implementa na mesma região física do respetivo serviço de back-end.
• API Management do Azure é otimizado para o tráfego da API. O API Management do Azure 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 aloja você mesmo) incluem nginx, Traefik e HAProxy.

Validação do pedido

É importante que seu aplicativo valide se quaisquer pedidos que receba estão autorizados para o locatário. Por exemplo, se a sua aplicação usa um nome de domínio personalizado para mapear pedidos para o inquilino, então a sua aplicação deve ainda verificar se cada pedido recebido pela aplicação está autorizado para esse inquilino. 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 todas as solicitações à sua aplicação? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
• Utilize 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 tenant provavelmente é executada em todas as solicitações à sua aplicação. Considere o quão bem o processo de mapeamento de locatários será dimensionado à medida que sua solução cresce. Por exemplo, se consultar uma tabela de base de dados como parte do mapeamento de inquilino, a base de dados suportará uma grande quantidade de carga? Se o mapeamento do inquilino 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 tem uma aplicação de alta escala, no entanto, a sobrecarga envolvida nesse mapeamento pode tornar-se 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 todos os pedidos subsequentes do cliente nessa sessão.

Considere as perguntas seguintes:

• Você pode usar cookies de sessão para reduzir a sobrecarga de solicitações de mapeamento para inquilinos?
• Que serviços utiliza para encaminhar pedidos para as implementações físicas de cada inquilino? 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 inquilino é movido para uma nova implantação, os pontos finais HTTP a que acede podem mudar. Quando isso acontecer, considere que o processo de mapeamento do inquilino 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 endpoints durante o processo de migração, considere redirecionar temporariamente as solicitações do tenant 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óximo passo

Aprenda sobre identidade numa aplicação multiinquilino.