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

Azure

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, precisa corresponder a solicitação recebida 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 tenant é 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 tenant apropriado e as compensações envolvidas nas abordagens.

Note

Esta página aborda principalmente aplicações baseadas em HTTP, como sites e APIs. No entanto, muitos dos mesmos princípios subjacentes se aplicam a aplicativos multilocatários que usam outros protocolos de comunicação.

Abordagens para identificar locatários

Há várias maneiras de identificar o tenant para uma requisição recebida. Cada abordagem requer inspecionar algum aspecto da requisição recebida.

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 landing page ou página de logon, que todos os tenants usam? Se você fizer isso, como os usuários selecionarão o tenant 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 usa nomes de domínio específicos para o locatário, ainda pode aproveitar aspectos da solicitação HTTP para identificar o locatário destinatário de uma determinada solicitação. 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 string de consulta na URL, como https://contoso.com/app?tenant=tailwindtraders.
• Um cabeçalho de solicitação HTTP personalizado, como Tenant-Id: tailwindtraders.

Important

Cabeçalhos de solicitação HTTP personalizados não são úteis quando as solicitações HTTP GET são emitidas de um navegador da Web ou quando as solicitações são tratadas por alguns tipos de proxy da Web. Você só deve usar cabeçalhos HTTP personalizados para operações GET ao criar uma API ou se controlar o cliente que emite a solicitação e não houver nenhum proxy Web incluído na cadeia de processamento de solicitação que possa modificar ou remover os cabeçalhos.

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 string de consulta para identificar tenants, uma página de destino central precisará direcionar os usuários para a página do tenant correto adicionando a string de consulta?
• Você tem um ponto de entrada central, como uma landing page ou página de logon, que todos os tenants usam? Se você fizer isso, como os usuários selecionarão o tenant 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? Em caso positivo, você poderá usar um gateway de API ou proxy reverso para realizar 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 claims 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 tenant 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 claim de ID do locatário ao token.

Se você estiver usando claims para mapear solicitações para tenants, 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 tenants? Se isso for possível, como os usuários selecionarão o tenant 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 tenants? Caso contrário, como você garantirá que todas as autoridades de token emitam tokens e claims 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 o identificador do locatário para o qual uma chave foi emitida, poderá consultar o identificador do locatário quando a chave for usada.

Note

As chaves de API não fornecem um alto nível de segurança porque precisam ser criadas e gerenciadas manualmente, têm longa duração e são frequentemente reutilizadas, e porque não contêm claims. Uma abordagem mais moderna e segura é usar um mecanismo de autorização baseado em declarações com tokens de curta duração, como OAuth 2.0 ou OpenID Connect.

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 consulta, juntamente com a ID do locatário. Quando uma solicitação é recebida, seu sistema localiza a chave de API na tabela de consulta e a corresponde a uma ID do tenant.
• 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ê rotacionará as chaves de API dos clientes sem causar indisponibilidade?
• As chaves de API geradas pelo cliente fornecem um nível adequado de segurança para suas APIs?

Note

As chaves de API não são iguais às senhas. As chaves de API devem ser geradas pelo sistema e devem ser exclusivas em todos os tenants, para que cada chave de API possa ser mapeada exclusivamente para um único tenant. Os gateways de API, como o Gerenciamento de API do Azure, podem gerar e gerenciar chaves de API, validar chaves em solicitações de entrada e mapear chaves para assinantes de API individuais.

Certificados do 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 de cliente fornecem uma maneira segura de autenticar clientes. Semelhantes a tokens e declarações, os certificados do cliente incluem atributos que podem ser usados para identificar 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 em que seu serviço confia? 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 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 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 com algumas informações da solicitação, eliminando essa tarefa na 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.
• 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 que 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 .

Note

Isso faz parte do princípio de design de segurança de pressupor violação no Microsoft Azure Well-Architected Framework.

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

• Como você autorizará todas as solicitações ao seu aplicativo? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
• Use frameworks e middleware de autenticação e autorização confiáveis, amplamente usados e bem mantidos, 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 tenant 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 tenant, o banco de dados dará suporte a alta 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 volume de 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.

Note

Muitos serviços de rede e aplicativos no Azure podem emitir cookies de sessão.

Considere as seguintes perguntas:

• Você pode usar cookies de sessão para reduzir a sobrecarga de solicitações de mapeamento para tenants?
• Quais serviços você usa para rotear solicitações para as implantações físicas para cada tenant? 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 isso acontece, os pontos de extremidade HTTP acessados por esses locatários podem mudar. 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 endpoints durante o processo de migração, considere redirecionar temporariamente as solicitações do tenant 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óxima etapa

Saiba mais sobre a identidade em um aplicativo 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, precisa corresponder a solicitação recebida 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 tenant é 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 tenant apropriado e as compensações envolvidas nas abordagens.

Note

Esta página aborda principalmente aplicações baseadas em HTTP, como sites e APIs. No entanto, muitos dos mesmos princípios subjacentes se aplicam a aplicativos multilocatários que usam outros protocolos de comunicação.

Abordagens para identificar locatários

Há várias maneiras de identificar o tenant para uma requisição recebida. Cada abordagem requer inspecionar algum aspecto da requisição recebida.

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 landing page ou página de logon, que todos os tenants usam? Se você fizer isso, como os usuários selecionarão o tenant 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 usa nomes de domínio específicos para o locatário, ainda pode aproveitar aspectos da solicitação HTTP para identificar o locatário destinatário de uma determinada solicitação. 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 string de consulta na URL, como https://contoso.com/app?tenant=tailwindtraders.
• Um cabeçalho de solicitação HTTP personalizado, como Tenant-Id: tailwindtraders.

Important

Cabeçalhos de solicitação HTTP personalizados não são úteis quando as solicitações HTTP GET são emitidas de um navegador da Web ou quando as solicitações são tratadas por alguns tipos de proxy da Web. Você só deve usar cabeçalhos HTTP personalizados para operações GET ao criar uma API ou se controlar o cliente que emite a solicitação e não houver nenhum proxy Web incluído na cadeia de processamento de solicitação que possa modificar ou remover os cabeçalhos.

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 string de consulta para identificar tenants, uma página de destino central precisará direcionar os usuários para a página do tenant correto adicionando a string de consulta?
• Você tem um ponto de entrada central, como uma landing page ou página de logon, que todos os tenants usam? Se você fizer isso, como os usuários selecionarão o tenant 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? Em caso positivo, você poderá usar um gateway de API ou proxy reverso para realizar 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 claims 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 tenant 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 claim de ID do locatário ao token.

Se você estiver usando claims para mapear solicitações para tenants, 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 tenants? Se isso for possível, como os usuários selecionarão o tenant 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 tenants? Caso contrário, como você garantirá que todas as autoridades de token emitam tokens e claims 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 o identificador do locatário para o qual uma chave foi emitida, poderá consultar o identificador do locatário quando a chave for usada.

Note

As chaves de API não fornecem um alto nível de segurança porque precisam ser criadas e gerenciadas manualmente, têm longa duração e são frequentemente reutilizadas, e porque não contêm claims. Uma abordagem mais moderna e segura é usar um mecanismo de autorização baseado em declarações com tokens de curta duração, como OAuth 2.0 ou OpenID Connect.

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 consulta, juntamente com a ID do locatário. Quando uma solicitação é recebida, seu sistema localiza a chave de API na tabela de consulta e a corresponde a uma ID do tenant.
• 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ê rotacionará as chaves de API dos clientes sem causar indisponibilidade?
• As chaves de API geradas pelo cliente fornecem um nível adequado de segurança para suas APIs?

Note

As chaves de API não são iguais às senhas. As chaves de API devem ser geradas pelo sistema e devem ser exclusivas em todos os tenants, para que cada chave de API possa ser mapeada exclusivamente para um único tenant. Os gateways de API, como o Gerenciamento de API do Azure, podem gerar e gerenciar chaves de API, validar chaves em solicitações de entrada e mapear chaves para assinantes de API individuais.

Certificados do 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 de cliente fornecem uma maneira segura de autenticar clientes. Semelhantes a tokens e declarações, os certificados do cliente incluem atributos que podem ser usados para identificar 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 em que seu serviço confia? 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 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 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 com algumas informações da solicitação, eliminando essa tarefa na 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.
• 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 que 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 .

Note

Isso faz parte do princípio de design de segurança de pressupor violação no Microsoft Azure Well-Architected Framework.

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

• Como você autorizará todas as solicitações ao seu aplicativo? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
• Use frameworks e middleware de autenticação e autorização confiáveis, amplamente usados e bem mantidos, 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 tenant 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 tenant, o banco de dados dará suporte a alta 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 volume de 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.

Note

Muitos serviços de rede e aplicativos no Azure podem emitir cookies de sessão.

Considere as seguintes perguntas:

• Você pode usar cookies de sessão para reduzir a sobrecarga de solicitações de mapeamento para tenants?
• Quais serviços você usa para rotear solicitações para as implantações físicas para cada tenant? 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 isso acontece, os pontos de extremidade HTTP acessados por esses locatários podem mudar. 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 endpoints durante o processo de migração, considere redirecionar temporariamente as solicitações do tenant 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óxima etapa

Saiba mais sobre a identidade em um aplicativo multilocatário.