Mapper les demandes aux locataires dans une solution mutualisée

Chaque fois qu’une demande arrive dans votre application, vous devez déterminer le contexte du locataire, qui est le locataire qui effectue la requête. Lorsque vous disposez d’une infrastructure spécifique au locataire qui peut ê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 de ce locataire, comme illustré dans le diagramme suivant :

De nombreuses applications mutualisées disposent également d’autorisations basées sur l’utilisateur. Le mappage de locataire est une activité distincte. Vous devez connaître à la fois l’utilisateur qui effectue la demande et le locataire dans lequel il travaille.

Cet article fournit des conseils aux 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. Chaque approche nécessite l’inspection d’un aspect de la requête entrante.

Noms de domaine

Si vous utilisez des noms de domaine ou de sous-domaine spécifiques au locataire, il est probable que les requêtes puissent être facilement mappées aux locataires à l’aide de l’en-tête, de l’en-tête HostX-Forwarded-Host ou d’un autre en-tête HTTP qui inclut le nom d’hôte d’origine pour chaque requête.

Toutefois, tenez compte des questions suivantes :

• Comment les utilisateurs sauront-ils quel nom de domaine utiliser pour accéder au service ?
• Avez-vous un point d’entrée central, comme une page d’accueil ou une page de connexion, que tous les locataires utilisent ? Si vous le faites, comment les utilisateurs sélectionnent-ils le locataire avec lequel ils travaillent ?
• Quelles autres informations utilisez-vous pour vérifier l’accès aux ressources du locataire, telles que les jetons d’autorisation ? Les jetons d’autorisation incluent-ils les noms de domaine spécifiques au locataire ?

Propriétés de requête HTTP

Si vous n’utilisez pas de noms de domaine spécifiques au locataire, vous pouvez toujours utiliser des aspects de la requête HTTP pour identifier le locataire pour lequel une requête particulière est utilisée. Par exemple, considérez une requête HTTP qui identifie le nom du locataire en tant que tailwindtraders. Cela peut être communiqué à l’aide de l’une des approches suivantes :

• Structure du chemin d’accès d’URL, par https://app.contoso.com/tailwindtraders/exemple .
• Chaîne de requête dans l’URL, telle que https://contoso.com/app?tenant=tailwindtraders.
• En-tête de requête HTTP personnalisé, tel que Tenant-Id: tailwindtraders.

Lorsque vous utilisez cette approche, vous devez prendre en compte les questions suivantes :

• Les utilisateurs sauront-ils comment accéder au service ? Par exemple, si vous utilisez une chaîne de requête pour identifier les locataires, une page d’accueil centrale doit-elle diriger les utilisateurs vers la page du locataire approprié en ajoutant la chaîne de requête ?
• Avez-vous un point d’entrée central, comme une page d’accueil ou une page de connexion, que tous les locataires utilisent ? Si vous le faites, comment les utilisateurs sélectionnent-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 back-end d’API ? Dans ce cas, vous pourriez utiliser une passerelle d’API ou un proxy inverse pour le mappage des locataires.

Revendications de jeton

De nombreuses applications utilisent des protocoles d’authentification et d’autorisation basés sur des revendications, tels que OAuth 2.0 ou SAML. Ces protocoles fournissent des jetons d’autorisation au client. Un jeton contient un ensemble de déclarations, qui sont des informations 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-client, puis transférer la demande au déploiement approprié. Vous pouvez également 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 des demandes à des locataires, vous devez prendre en compte les questions suivantes :

• Utiliserez-vous une revendication pour identifier un locataire ? Quelle revendication utiliserez-vous ?
• Un utilisateur peut-il être membre de plusieurs locataires ? Si c’est possible, comment les utilisateurs sélectionnent-ils le locataire avec lequel ils souhaitent travailler pour une demande spécifique ?
• Existe-t-il un système d’authentification et d’autorisation central pour tous les locataires ? Si ce n’est pas le cas, comment garantirez-vous que toutes les autorités de jeton émettent des jetons et des revendications cohérents ?

Clés API

De nombreuses applications exposent des API. Il peut s’agir d’une utilisation interne au sein de votre organisation ou d’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. Si vous enregistrez l’ID de locataire pour lequel une clé a été émise, vous pouvez ensuite rechercher l’ID de locataire lorsque la clé utilisée.

Les clés API peuvent être générées de plusieurs façons. Voici deux approches courantes :

• Générez une valeur aléatoire par chiffrement et stockez-la dans une table de recherche, en même temps que l’ID de locataire. Lorsqu’une demande est reçue, votre système recherche la clé API dans la table de recherche, puis la correspond à un ID de locataire.
• Créez une chaîne significative avec un ID de locataire inclus dans celui-ci. Signez numériquement la clé à l’aide d’une approche telle que HMAC. Lorsque vous traitez chaque requête, vous vérifiez la signature, puis extrayez l’ID de locataire.

Considérez les questions suivantes :

• Comment générer et émettre des clés API ?
• Comment vos clients API recevront-ils et stockent-ils en toute sécurité la clé API ?
• Avez-vous besoin de vos clés API pour expirer après une période de temps ? Comment faire pivoter les clés API de vos clients, sans provoquer de temps d’arrêt ?
• Les clés API générées par le client fournissent-elles un niveau de sécurité adéquat pour vos API ?

Certificats de client

L’authentification par certificat client, parfois appelée tls mutuel (mTLS), est couramment utilisée pour la communication de service à service et pour les appareils ou kiosques sans assistance utilisés par les utilisateurs non authentifiés. Les certificats clients offrent un moyen sécurisé d’authentifier les clients. Comme pour les jetons et les revendications, les certificats clients fournissent des attributs qui peuvent être utilisés pour déterminer le locataire. Par exemple, l’objet 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 facteurs suivants :

• Comment allez-vous émettre et renouveler en toute sécurité les certificats clients approuvés par votre service ? Les certificats clients peuvent être complexes à utiliser, car ils nécessitent une infrastructure spéciale pour gérer et émettre des certificats. Si elles sont gérées de manière incorrecte, ces complexités peuvent réduire votre sécurité au lieu de l’augmenter.
• Les certificats clients seront-ils utilisés uniquement pour les demandes de connexion initiales ou attachés à toutes les demandes à votre service ?
• Le processus d’émission et de gestion des certificats devient-il inmanageable lorsque vous avez un grand nombre de clients ?
• Comment allez-vous implémenter le mappage entre le certificat client et le locataire ?

Proxys inversés

Un proxy inverse, également appelé proxy d’application, peut être utilisé pour router les requêtes HTTP. Un proxy inverse accepte une demande à partir d’un point de terminaison d’entrée et peut transférer la requête à l’un des nombreux points de terminaison back-end. Les proxys inverses sont utiles pour les applications mutualisées, car elles peuvent effectuer le mappage entre certaines informations de requête, déchargeant la tâche à partir de votre infrastructure d’application.

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

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ériphérie mondiale Microsoft pour créer des applications web rapides, sécurisées et hautement évolutives. Vous pouvez utiliser des ensembles de règles pour extraire des identificateurs de locataire et les placer dans une autre partie de la requête.
• 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. Gestion des API Azure fournit un moteur de stratégie complet qui offre une grande flexibilité pour extraire des informations de locataire à partir de requêtes.
• Les technologies commerciales et open source (que vous hébergez vous-même) incluent nginx, Traefik et HAProxy.

Validation des demandes

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

Lors de l’implémentation de la validation des demandes, tenez compte des facteurs suivants :

• Comment autoriserez-vous toutes les demandes à votre application ? Vous devez autoriser les demandes, quelle que soit l’approche que vous utilisez pour les mapper à l’infrastructure physique.
• Utilisez des frameworks d’authentification et d’autorisation approuvés, largement utilisés et bien gérés, au lieu d’implémenter vous-même toute la logique de validation. Par exemple, ne créez pas de logique de validation de signature de jeton ou de bibliothèques de chiffrement de certificat client. Utilisez plutôt des fonctionnalités de votre plateforme d’application (ou des packages approuvés connus) qui ont été validées et testées.

Performance

La logique de mappage de locataire s’exécute probablement sur chaque requête adressée à votre application. Réfléchissez à la façon dont le processus de mappage de locataire sera mis à l’échelle, à mesure que votre solution augmente. Par exemple, si vous interrogez une table de base 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 votre mappage de locataire nécessite le déchiffrement d’un jeton, les exigences de calcul seront-elles trop élevées au fil du temps ? Si votre trafic est assez modeste, cela n’est probablement pas susceptible d’affecter vos performances globales. Toutefois, lorsque vous disposez d’une application à grande échelle, la surcharge impliquée dans ce mappage peut devenir significative.

Cookies de session

Une approche pour réduire la surcharge de performances de la logique de mappage de locataire consiste à utiliser des cookies de session. Au lieu d’effectuer le mappage sur chaque requête, envisagez de calculer les informations uniquement sur la première demande 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 clientes suivantes au sein de cette session.

Considérez les questions suivantes :

• Pouvez-vous utiliser des cookies de session pour réduire la surcharge liée au mappage des demandes aux locataires ?
• Quels services utilisez-vous pour router les demandes vers les déploiements physiques de chaque locataire ? Ces services prennent-ils en charge les sessions basées 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 accèdent peuvent changer. Lorsque cela se produit, considérez que votre processus de mappage de locataire doit changer. Vous devrez peut-être prendre en compte les facteurs suivants :

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

Contributors

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

Auteur principal :

• Daniel Scott-Raynsford | Stratège de la technologie partenaire

Autres contributeurs :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
• 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

Découvrez les considérations à prendre en compte lorsque vous travaillez avec des noms de domaine dans une application multilocataire.