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

Sempre que uma solicitação chega ao seu aplicativo, você precisa determinar o locatário ao qual a solicitação se destina. Quando você tem uma infraestrutura específica do locatário que pode até ser hospedada em regiões geográficas diferentes, 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 abaixo:

Nesta página, fornecemos 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.

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 cabeçalho ou outro cabeçalho HTTP que inclua o Host 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 identificarão o locatário que precisam acessar?
• Que outras informações você está usando para verificar o acesso ao 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. Isso pode ser comunicado usando o seguinte:

• 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 X-Tenant-Id: tailwindtraders.

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

• 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 o 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 identificarã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 estiver, você poderá usar um gateway de API ou proxy reverso para executar o mapeamento de locatário.

Declarações de token

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 declarações, que são partes de informações sobre o aplicativo cliente ou usuário. 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 os locatários com quem gostariam de trabalhar?
• 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 de API. As chaves de API são fornecidas com cada solicitação e podem ser usadas para procurar o locatário.

As chaves de API podem ser geradas de várias maneiras. Uma abordagem comum é gerar um valor criptograficamente aleatório e armazená-lo em uma tabela de pesquisa, juntamente com o 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. Outra abordagem é criar uma cadeia de caracteres significativa com um ID de locatário incluído dentro dela e, em seguida, você assinaria digitalmente a chave, usando uma abordagem como 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?
• Depender apenas de chaves de API roladas pelo cliente fornece 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. Os certificados de cliente fornecem uma maneira segura de autenticar clientes. Da mesma forma que tokens e declarações, os certificados de cliente fornecem atributos que podem ser usados para determinar o locatário. Por exemplo, o assunto do certificado pode conter o endereço de e-mail do usuário, que pode ser usado para procurar o locatário.

Ao planejar o uso de certificados de cliente para mapeamento de locatário, considere o seguinte:

• 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.
• 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.

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.
• 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.
• 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. Ao usar o OAuth 2.0, você executa a validação inspecionando as declarações de audiência e escopo .

Ao implementar a validação de solicitação, você deve considerar o seguinte:

• 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.

Desempenho

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.

Afinidade de sessão

Uma abordagem para reduzir a sobrecarga de desempenho da lógica de mapeamento de locatário é usar afinidade 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 a afinidade 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 afinidade de sessão baseada em cookies?

Migração de locatários

Os inquilinos muitas vezes 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 que eles acessam podem mudar. Quando isso acontecer, considere que seu processo de mapeamento de locatários precisa ser atualizado. Pode ser necessário considerar o seguinte:

• 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 tempo para se propagar para os clientes, dependendo do tempo de vida útil 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.

Contribuidores

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

Autor principal:

• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros

Outros contribuidores:

• John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

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

Próximos passos

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