Partager via

Mettre en place une communication inter-locataires en utilisant des applications multi-locataires

  • Article

Ce guide fournit une solution pour réaliser des communications bidirectionnelles et sécurisées entre les services qui sont hébergés dans les abonnements Azure que différents locataires Microsoft Entra gèrent.

La sécurisation des communications multi-locataires dans Azure peut s'avérer difficile en raison des limitations inhérentes à de nombreux services. Vous pouvez éliminer le besoin de gérer les informations d'identification directement en utilisant les identités gérées Azure pour obtenir des jetons de Microsoft Entra ID. Cependant, les identités gérées par Azure ne fonctionnent pas au-delà des limites des locataires, et l'alternative typique est d'utiliser des secrets partagés, comme des URL de signature d'accès partagées. N'oubliez pas que si vous utilisez des secrets partagés, vous devez distribuer et faire tourner les secrets de manière sécurisée à travers les limites des locataires Microsoft Entra.

Une option qui permet d'éviter ces frais généraux consiste à créer une application multilocataire pour représenter l'identité de votre charge de travail. Par le biais d'un processus de consentement, vous pouvez faire connaître l'identité de cette charge de travail à un locataire externe et lui permettre d'authentifier des services dans le locataire externe.

Cet article présente un exemple de mise en œuvre de ce modèle qui utilise un exemple de code.

Ce modèle peut être réutilisé pour n'importe quel scénario multi-locataire comportant divers services qui doivent communiquer à travers les limites des locataires de Microsoft Entra.

Architecture

Diagramme de l'architecture de communication entre locataires.

Téléchargez un fichier PowerPoint de cette architecture.

Workflow

Le workflow suivant correspond au diagramme précédent :

  1. Un administrateur du côté du fournisseur crée un enregistrement d'application multitenant et met en place un secret client pour cette application.

  2. Un administrateur du côté du client fournit un principal de service dans son locataire. Ce principal de service est basé sur l'application multitenant créée par le fournisseur. Vous pouvez réaliser cette étape de différentes manières. Dans l'exemple, nous avons choisi de créer une URL à fournir à l'administrateur du locataire du client, mais vous pouvez utiliser l'API Microsoft Graph à la place.

  3. Le client applique des rôles de contrôle d'accès basé sur les rôles (RBAC) à ce nouveau principal de service afin qu'il soit autorisé à accéder à Azure Service Bus.

  4. L'application de fonction du fournisseur utilise l'ID client et le secret client de l'enregistrement de l'application pour envoyer un message authentifié à la file d'attente Service Bus du client.

  5. L'application de fonction du client utilise une identité gérée pour lire le message du fournisseur dans la file d'attente via un déclencheur Service Bus.

  6. Après avoir reçu le message, l'application de fonction du client effectue généralement quelques applications avant de renvoyer un message d'état au fournisseur. Dans ce cas, à des fins de démonstration, l'application de fonction envoie immédiatement un message d'état au fournisseur dans une file d'attente distincte du même bus de service.

  7. Cette application de fonction lit la file d'attente d'état à partir du locataire du client via un minuteur déclenché par Azure Functions.

Détails du scénario

Un fournisseur a plusieurs clients. Le fournisseur et chaque client disposent de leur propre locataire Microsoft Entra ID individuel et de leurs propres ressources Azure. Le fournisseur et chaque client ont besoin d'une méthode de communication sécurisée et bidirectionnelle pour pouvoir échanger des messages via les files d'attente Service Bus. La solution doit présenter une histoire d'identité convaincante qui évite d'introduire des informations d'identification ou des secrets inutiles.

Ce qu'il faut savoir sur les applications multilocataires

  • Un objet d'application est une instance globalement unique de l'application.

  • Lorsqu'une application est enregistrée dans Microsoft Entra, un objet d'application et un objet principal de service sont automatiquement créés dans le locataire.

  • Un objet principal de service est créé dans chaque locataire qui utilise l'application et fait référence à l'objet d'application. Un objet d'application a une relation de type « un pour plusieurs » avec l'objet principal de service correspondant.

  • L'objet application est la représentation globale de votre application et est utilisé par tous les locataires. L'objet principal de service est la représentation locale utilisée dans un locataire spécifique.

  • Un objet principal de service doit être créé dans chaque locataire où l'application est utilisée afin qu'elle puisse établir une identité pour accéder aux ressources sécurisées par le locataire. Une application à locataire unique ne possède qu'un seul objet principal de service dans son locataire d'origine. Cet objet principal de service est créé et autorisé à être utilisé lors de l'enregistrement de l'application. Une application multi-locataires dispose également d'un objet principal de service créé dans chaque locataire et dont l'utilisation a été autorisée par un utilisateur de ce locataire.

  • Pour accéder aux ressources sécurisées par un locataire Microsoft Entra, un principal de sécurité doit représenter l'entité qui requiert l'accès.

  • Lorsqu'une application reçoit la permission d'accéder aux ressources d'un locataire lors de l'enregistrement ou du consentement, un objet principal de service est créé. Cette architecture est mise en œuvre avec le flux de consentement.

Comment le fournisseur envoie-t-il un message au client ?

Idéalement, le fournisseur est en mesure d'attribuer une identité gérée à la ressource de calcul Azure chargée d'envoyer des messages à la file d'attente d'un client. Le locataire du client est configuré pour faire confiance aux identités gérées du locataire du fournisseur. Cependant, une véritable fédération entre deux locataires Microsoft Entra, qui permettrait essentiellement le « partage » des identités d'un locataire à l'autre, n'est pas possible actuellement. Le fournisseur doit donc s'authentifier en utilisant une identité reconnue par le client. Le fournisseur doit s'authentifier auprès du locataire Microsoft Entra du client en tant que principal de service connu du client.

Nous recommandons au fournisseur d'enregistrer une application multitenant dans son propre locataire, puis de demander à chaque client de provisionner un principal de service associé dans son locataire. Le fournisseur peut alors s'authentifier auprès du locataire du client et des API hébergées par le client en utilisant ce principal de service. Dans cette approche, le fournisseur n'a jamais besoin de partager le secret du client. La gestion des justificatifs d'identité relève de la seule responsabilité du fournisseur.

Comment le client envoie-t-il un message au fournisseur ?

Nous recommandons au client de créer ou d'héberger une file d'attente que le fournisseur peut lire. Le client écrit un message dans la file d'attente. Le fournisseur interroge de manière répétée chaque file d'attente du client à l'aide d'un objet principal de service. L'inconvénient de cette approche est qu'elle introduit une latence d'interrogation lorsque le fournisseur reçoit un message. Le code doit également être exécuté plus souvent dans le fournisseur, car il doit se réactiver et exécuter la logique d'interrogation au lieu d'attendre qu'un événement le déclenche. Toutefois, la gestion des informations d'identification reste de la seule responsabilité du fournisseur, ce qui renforce la sécurité.

Une autre solution possible consiste à demander au fournisseur de créer ou d'héberger une file d'attente pour chacun de ses clients. Chaque client crée sa propre application multilocataire et demande au fournisseur de la mettre à disposition dans son locataire en tant qu'objet principal de service. Le client utilise ensuite cet objet principal de service pour envoyer des messages à une file d'attente spécifique au client du côté du fournisseur. La gestion des justificatifs d'identité reste de la seule responsabilité du client. L'inconvénient de cette approche est que le fournisseur doit fournir les principaux de service qui sont associés aux applications du client dans son locataire. Ce processus est manuel, et les fournisseurs ne souhaitent probablement pas que des étapes manuelles fassent partie du flux d'intégration d'un nouveau client.

Exemple de code de configuration

Les étapes suivantes vous guident dans le processus de configuration de la communication inter-locataires entre un fournisseur et un client.

Configuration du fournisseur

La configuration du fournisseur comprend les étapes de génération et de provisionnement d'un principal de service d'application multitenant et les étapes de provisionnement du locataire du client.

  1. Créez une application de fonction déclenchée par HTTP pour envoyer un message à écrire dans la file d'attente de commandes du bus de service du client dans le locataire du client.

  2. Créez une application de fonction déclenchée par le temps pour vérifier périodiquement une file d'attente d'état dans le Service Bus du client au sein du locataire client.

Créer une application multitenant dans le locataire du fournisseur

Tout d'abord, créez une application multitenant dans le locataire du fournisseur et fournissez cette identité dans le locataire du client. Dans ce scénario, l'identité est un principal de service. L'architecture présentée plus haut dans cet article vous montre comment configurer et approvisionner un principal de service depuis le locataire du fournisseur vers le locataire du client. L'architecture décrit également la manière de provisionner avec plusieurs locataires Microsoft Entra.

  1. Choisissez l'option d'organisation multi-locataires.

  2. Ajoutez le site web suivant comme URI de redirection : https://entra.microsoft.com. Vous pouvez modifier cet URI en fonction de vos besoins.

  3. Enregistrez et prenez note de la valeur de l'ID de l'application (client).

Créer une nouvelle clé secrète client

  1. Après avoir créé l'application multitenant, créez un secret client pour ce principal de service.

  2. Enregistrez le secret généré dans un endroit sûr. Le secret et l'ID client sont vos informations d'identification client qui sont nécessaires pour échanger le code, dans le flux de code d'autorisation, et pour un jeton d'identification dans l'étape suivante.

Azure Functions - Déclenché par HTTP

Utilisez la fonction HTTP pour lancer le déploiement à partir du locataire du fournisseur en envoyant un message dans la file d'attente de déploiement du Service Bus du client. Nous avons choisi la fonction déclenchée par HTTP comme méthode de livraison pour commencer cette preuve de concept. Le principal de service que vous avez généré précédemment sert de justificatif d'identité pour accéder au locataire du client et écrire dans une file d'attente spécifique au sein de Service Bus. Vous devez également terminer la configuration du client pour que cette étape fonctionne correctement.

Azure Functions - Déclenché par le temps

Utilisez la fonction timer-triggered pour interroger la file d'attente de l'état de déploiement à partir du locataire du client. Nous interrogeons la file d'attente de l'état du déploiement toutes les 10 secondes à des fins de démonstration dans cette preuve de concept. Cette approche supprime la nécessité pour le client de disposer d'un principal de service pour accéder au locataire du fournisseur.

Configuration du client

  1. Fournissez le principal de service en modifiant et en utilisant l'URL fournie.

  2. Étendez le principal de service du fournisseur pour utiliser les contrôles RBAC appropriés.

  3. Créez une fonction déclenchée par le Bus de service pour lire un message à partir d'une file d'attente de messages du Bus de service et placer un message dans une autre file d'attente. À des fins de démonstration, ce flux est optimal pour tester la fonctionnalité.

  4. Créez une identité gérée attribuée par le système pour la fonction déclenchée par le bus de service.

  5. Attribuez à l'identité gérée attribuée par le système l'étendue du bus de service.

Fournir le principal de service du locataire du fournisseur au locataire du client.

  1. Visitez l'URL suivante après avoir remplacé le paramètre client_id de la chaîne de requête par votre propre identifiant de client : https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    Vous pouvez également approvisionner le principal de service dans un autre locataire Microsoft Entra avec un appel API Microsoft Graph admin, une commande Azure PowerShell ou une commande Azure CLI.

  2. Connectez-vous avec un compte du locataire du client.

  3. Sur l'écran de consentement, sélectionnez Accepter pour provisionner l'application du fournisseur dans le locataire du client. L'URL est finalement redirigée vers microsoft.com, ce qui a toujours pour effet de provisionner l'identité dans le locataire du client.

  4. Vérifiez l'identité au sein du locataire Microsoft Entra du client en allant sur Enterprise Applications pour voir le principal de service nouvellement provisionné.

Configurez le RBAC pour le principal de service provisionné

Étendez le principal de service du fournisseur à partir de la configuration du principal de service du fournisseur pour avoir des rôles « Service Bus Data Owner » sur le bus de service. Ce principal de service est utilisé à la fois pour écrire dans une file d'attente avec une fonction déclenchée par HTTP et pour lire dans une file d'attente à partir d'une fonction déclenchée par un minuteur. Veillez à ajouter le rôle "Azure Service Bus Data Owner" au principal de service.

Azure Functions - Déclenchement du bus de service

Suivez les étapes du tutoriel sur les fonctions basées sur l'identité pour définir le déclencheur de fonction à partir de la file d'attente du bus de service et pour apprendre à configurer une identité gérée. Cette orientation vous aide à déclencher l'application de la fonction à partir de la file d'attente du Bus de service lorsqu'un message est ajouté à la file d'attente. Vous utilisez également l'identité gérée lorsque vous placez un message dans une file d'attente différente. À des fins de démonstration, nous utilisons la même fonction pour pousser le message.

Dans l'espace de noms du bus de services que vous venez de créer, sélectionnez Contrôle d'accès (IAM). Vous pouvez voir et configurer qui a accès à la ressource dans le plan de contrôle.

Accordez à l'application de fonction l'accès à l'espace de noms du bus de service en utilisant des identités gérées.

  1. Veillez à ajouter le rôle « Azure Service Bus Data Receiver » à l'identité gérée.

  2. Dans le sélecteur d'identité gérée, choisissez Application de fonction dans la catégorie Identité gérée attribuée par le système. L'application de fonction peut être assortie d'un numéro entre parenthèses. Ce nombre indique combien d'applications ayant des identités attribuées par le système se trouvent dans l'abonnement.

Se connecter à Service Bus dans votre application de fonction

  1. Dans le portail, recherchez votre application de fonction ou accédez à celle-ci sur la page Application de fonction.

  2. Dans Paramètres d'application, sélectionnez + Nouveau pour créer un nouveau paramètre d'application dans le tableau. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Gestion du cycle de vie des secrets du client principal du service

Si vous introduisez des secrets dans votre architecture multi-locataires, vous devez gérer le cycle de vie des secrets clients générés. Pour savoir comment stocker, faire pivoter et contrôler les secrets des clients en toute sécurité, reportez-vous à la rubrique Meilleures pratiques pour la gestion des secrets.

Paramètres locaux

Chaque sous-répertoire contient une version abrégée des fichiers local.settings.json, qui peut être modifiée pour exécuter les fonctions Azure localement. Pour configurer les paramètres dans Azure, mettez à jour les paramètres de l'application.

La commande DefaultAzureCredential énumère plusieurs paramètres avant d'atteindre l'identifiant Azure CLI. Pour éviter toute confusion, nous vous recommandons d'exécuter la commande az login -t <tenant ID> afin d'accorder les informations d'identification correctes lorsque vous développez des fonctions locales.

Contributeurs

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

Principaux auteurs :

Étapes suivantes