Mapper des requêtes à des locataires dans une solution multi-locataire

Lorsqu’une requête arrive dans votre application, vous devez déterminer quel est le locataire pour lequel la requête est prévue. Lorsque vous disposez d’une infrastructure spécifique à un locataire qui peut même être hébergée dans différentes régions géographiques, vous devez faire correspondre la requête entrante à un locataire. Ensuite, vous devez transférer la requête à l’infrastructure physique qui héberge les ressources du locataire, comme illustré ci-dessous :

Dans cette page, nous fournissons des conseils pour les décideurs techniques sur les approches que vous pouvez envisager pour mapper les demandes au locataire approprié et les compromis impliqués dans les approches.

Approches pour identifier les locataires

Il existe plusieurs façons d’identifier le locataire pour une requête entrante.

Noms de domaine

Si vous utilisez des noms de domaine ou de sous-domaine spécifiques à un locataire, il est probable que les demandes peuvent être facilement mappées à des locataires à l’aide de l’en-tête Host ou d’un autre en-tête HTTP qui comprend le nom d’hôte d’origine de chaque demande.

Toutefois, posez-vous les questions suivantes :

• Comment les utilisateurs connaissent-ils le nom de domaine à utiliser pour accéder au service ?
• Disposez-vous d’un point d’entrée central, tel qu’une page d’arrivée ou une page de connexion, que tous les locataires utilisent ? Si c’est le cas, comment les utilisateurs identifient-ils le locataire auquel ils ont besoin d’accéder ?
• Quelles sont les autres informations que vous utilisez pour vérifier l’accès au locataire, telles que les jetons d’autorisation ? Les noms de domaine spécifiques à un locataire sont-ils inclus dans les jetons d’autorisation ?

Propriétés de requête HTTP

Si vous n’utilisez pas de noms de domaine spécifiques à un locataire, vous pouvez toujours utiliser des aspects de la requête HTTP afin d’identifier le locataire pour lequel une demande particulière est destinée. Par exemple, considérez une requête HTTP qui identifie le nom du locataire comme tailwindtraders. Cela peut être communiqué à l’aide des éléments suivants :

• La structure du chemin de l’URL, telle que https://app.contoso.com/tailwindtraders/.
• La chaîne de requête dans l’URL, telle que https://contoso.com/app?tenant=tailwindtraders.
• L’en-tête de demande HTTP personnalisé, tel que Tenant-Id: tailwindtraders.

Lorsque vous utilisez cette approche, vous devez vous poser les questions suivantes :

• Les utilisateurs savent-ils comment accéder au service ? Par exemple, si vous utilisez une chaîne de requête pour identifier les locataires, une page d’arrivée centrale doit-elle diriger les utilisateurs vers le locataire correct en ajoutant la chaîne de requête ?
• Disposez-vous d’un point d’entrée central, tel qu’une page d’arrivée ou une page de connexion, que tous les locataires utilisent ? Si c’est le cas, comment les utilisateurs identifient-ils le locataire auquel ils ont besoin d’accéder ?
• Votre application fournit-elle des API ? Par exemple, votre application web est-elle une application monopage (SPA) ou une application mobile avec un backend d’API ? Si c’est le cas, vous pourriez utiliser une passerelle API ou un proxy inverse pour effectuer un mappage de locataire.

Revendications de jetons

De nombreuses applications utilisent des protocoles d’authentification et d’autorisation basés sur les revendications, tels qu’OAuth 2.0 ou SAML. Ces protocoles fournissent des jetons d’autorisation au client. Un jeton contient un ensemble de revendications, qui sont des éléments d’information sur l’application cliente ou l’utilisateur. Les revendications peuvent être utilisées pour communiquer des informations, telles que l’adresse e-mail d’un utilisateur. Votre système peut ensuite inclure l’adresse e-mail de l’utilisateur, rechercher le mappage utilisateur-locataire, puis transférer la requête au déploiement approprié. Ou vous pouvez même inclure le mappage de locataire dans votre système d’identité et ajouter une revendication d’ID de locataire au jeton.

Si vous utilisez des revendications pour mapper les requêtes aux locataires, vous devez vous poser les questions suivantes :

• Allez-vous utiliser une revendication pour identifier un locataire ? Quelles revendications utiliser ?
• Un utilisateur peut-il être membre de plusieurs locataires ? Si possible, comment les utilisateurs sélectionnent-ils les locataires avec lesquels ils aimeraient travailler ?
• Existe-t-il un système d’authentification et d’autorisation central pour tous les locataires ? Si ce n’est pas le cas, comment pouvez-vous vous assurer que toutes les autorités de jetons émettent des jetons et des revendications cohérents ?

Clés API

De nombreuses applications exposent des API. Elles peuvent être destinées à un usage interne au sein de votre organisation ou à une utilisation externe par des partenaires ou des clients. Une méthode courante d’authentification pour les API consiste à utiliser une clé API. Les clés API sont fournies avec chaque requête et peuvent être utilisées pour rechercher le locataire.

Les clés API peuvent être générées de diverses manières. Une approche courante consiste à générer une valeur aléatoire par chiffrement et à la stocker dans une table de choix à côté de l’ID locataire. Lorsqu’une requête est reçue, votre système trouve la clé API dans la table de choix et la met en correspondance avec un ID locataire. Une autre approche consiste à créer une chaîne significative qui inclut un ID locataire, puis à signer numériquement la clé en utilisant une approche telle que HMAC. Lorsque vous traitez chaque requête, vous vérifiez la signature, puis extrayez l’ID locataire.

Posez-vous les questions suivantes :

• Comment générer et émettre des clés API ?
• Comment vos clients API reçoivent-ils et stockent-ils en toute sécurité la clé API ?
• Avez-vous besoin de vos clés API pour expirer au bout d’une certaine période ? Comment faire pivoter les clés API de vos clients sans entraîner de temps d’arrêt ?
• Le fait de s’appuyer uniquement sur les clés API du client offre-t-il un niveau de sécurité adéquat pour vos API ?

Certificats clients

L’authentification par certificat client, parfois appelée mutual TLS (mTLS), est couramment utilisée pour la communication entre les services. Les certificats clients fournissent un moyen sécurisé d’authentifier les clients. Tout comme les jetons et les revendications, les certificats clients fournissent des attributs qui peuvent être utilisés pour déterminer le locataire. Par exemple, le sujet du certificat peut contenir l’adresse e-mail de l’utilisateur, qui peut être utilisée pour rechercher le locataire.

Lorsque vous envisagez d’utiliser des certificats clients pour le mappage de locataire, tenez compte des éléments suivants :

• Comment émettre et renouveler de manière sécurisée les certificats clients auxquels votre service fait confiance ? Les certificats clients peuvent être complexes à utiliser, car ils nécessitent une infrastructure spéciale pour gérer et émettre des certificats.
• Les certificats clients sont-ils utilisés uniquement pour les requêtes de connexion initiales ou attachés à toutes les requêtes vers votre service ?
• Le processus d’émission et de gestion des certificats peut-il devenir ingérable lorsque vous disposez d’un grand nombre de clients ?
• Comment implémenter le mappage entre le certificat client et le locataire ?

Proxies inverses

Un proxy inverse, aussi appelé proxy d’application, peut être utilisé pour acheminer les requêtes HTTP. Un proxy inverse accepte une requête émanant d’un point de terminaison d’entrée et peut transférer la requête à l’un des nombreux points de terminaison backend. Les proxies inverses sont utiles pour les applications multi-locataires, car ils peuvent effectuer le mappage entre certaines informations de requête et le déchargement de la tâche à partir de votre infrastructure d’application.

De nombreux proxies inverses peuvent utiliser les propriétés d’une requête pour prendre une décision concernant le routage du locataire. Ils peuvent inspecter le nom du domaine de destination, le chemin d’URL, la chaîne de requête, les en-têtes HTTP et même les revendications au sein des jetons.

Les proxys inverses courants suivants sont utilisés dans Azure :

• Azure Front Door est un équilibreur de charge global et un pare-feu d’applications web. Il utilise le réseau de périmètre mondial Microsoft pour créer des applications web rapides, sécurisées et très évolutives.
• Azure Application Gateway est un équilibreur de charge de trafic web managé que vous déployez dans la même région physique que votre service principal.
• La Gestion des API Azure est optimisée pour le trafic d’API.
• Les technologies commerciales et open source (que vous hébergez) incluent nginx, Traefik et HAProxy.

Validation des demandes

Il est important pour votre application de vérifier que toutes les requêtes qu’elle reçoit sont autorisées pour le locataire. Par exemple, si votre application utilise un nom de domaine personnalisé pour mapper les requêtes au locataire, alors votre application doit toujours vérifier que chaque requête reçue est autorisée pour ce locataire. Même si la requête comprend un nom de domaine ou un autre identificateur de locataire, cela ne signifie pas que vous devez automatiquement lui octroyer l’accès. Lorsque vous utilisez OAuth 2.0, vous effectuez la validation en inspectant les revendications d’audience et d’étendue.

Lorsque vous implémentez la validation des requêtes, vous devez tenir compte des éléments suivants :

• Comment autoriser toutes les requêtes sur votre application ? Vous devez autoriser les requêtes, quelle que soit l’approche que vous utilisez pour les mapper à l’infrastructure physique.
• Utilisez des cadres et des intergiciels intermédiaires d'authentification et d'autorisation fiables, largement utilisés et bien entretenus, au lieu de mettre en œuvre vous-même toute la logique de validation. Par exemple, ne générez pas de logique de validation des signatures du jeton ou de bibliothèques de chiffrement du certificat client. À la place, utilisez les fonctionnalités de votre plateforme d’application (ou des packages fiables connus) qui ont été validées et testées.

Performances

La logique de mappage de locataire s’exécute probablement à chaque requête adressée à votre application. Réfléchissez à la façon dont le processus de mappage de locataire est mis à l’échelle à mesure que votre solution croît. Par exemple, si vous interrogez une table de données dans le cadre de votre mappage de locataire, la base de données prend-elle en charge une grande quantité de charge ? Si le mappage de votre locataire nécessite le déchiffrement d’un jeton, les exigences de calcul sont-elles trop élevées au fil du temps ? Si votre trafic est relativement modeste, il existe peu de risque que cela affecte les performances globales. Toutefois, lorsque vous disposez d’une application à grande échelle, la surcharge impliquée dans ce mappage peut devenir importante.

Affinité de session

L’une des approches permettant de réduire la surcharge de performances de la logique de mappage de locataire consiste à utiliser l’affinité de session. Au lieu d’effectuer le mappage à chaque requête, envisagez de calculer les informations uniquement à la première requête pour chaque session. Votre application fournit ensuite un cookie de session au client. Le client transmet le cookie de session à votre service avec toutes les demandes de client suivantes au sein de cette session.

Posez-vous les questions suivantes :

• Pouvez-vous utiliser l’affinité de session pour réduire la surcharge liée au mappage des requêtes aux locataires ?
• Quels services utilisez-vous pour acheminer les requêtes vers les déploiements physiques pour chaque locataire ? Ces services prennent-ils en charge l’affinité de session basée sur les cookies ?

Migration de locataire

Les locataires doivent souvent être déplacés vers une nouvelle infrastructure dans le cadre du cycle de vie du locataire. Lorsqu’un locataire est déplacé vers un nouveau déploiement, les points de terminaison HTTP auxquels ils ont accès peuvent changer. Dans ce cas, vous devez mettre à jour le processus de mappage de locataire. Vous devriez peut-être tenir compte des éléments suivant :

• Si votre application utilise des noms de domaine pour le mappage des requêtes, elle peut également nécessiter une modification de DNS au moment de la migration. La propagation de la modification de DNS peut prendre du temps pour les clients, en fonction de la durée de vie des entrées DNS dans votre service DNS.
• Si votre migration modifie les adresses des points de terminaison au cours du processus de migration, envisagez alors de rediriger temporairement les requêtes pour le locataire vers une page de maintenance qui s’actualise automatiquement.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire

Autres contributeurs :

• John Downs | Ingénieur logiciel principal
• Paul Salvatori | Ingénieur client principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

En savoir plus sur les éléments à prendre en compte lorsque vous utilisez des noms de domaine dans une application multi-locataire.