Authentifier et autoriser une application avec Microsoft Entra ID pour accéder aux entités Azure Service Bus
Article
Azure Service Bus prend en charge l’utilisation de Microsoft Entra ID pour autoriser les requêtes d’accès aux entités Service Bus (files d’attente, rubriques, abonnements ou filtres). Microsoft Entra ID vous permet d’utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée pour les ressources Azure. L’un des principaux avantages de l’utilisation de Microsoft Entra ID avec Azure Service Bus est que vous n’avez plus besoin de stocker vos informations d’identification dans le code. Au lieu de cela, vous pouvez demander un jeton d’accès OAuth 2.0 auprès de la plateforme d’identité Microsoft. Si l’authentification réussit, Microsoft Entra ID retourne un jeton d’accès à l’application, qui peut ensuite l’utiliser pour autoriser les requêtes d’accès aux ressources Azure Service Bus.
Important
Vous pouvez désactiver l’authentification locale ou l’authentification de clé SAS pour un espace de noms Service Bus, et autoriser uniquement l’authentification Microsoft Entra. Pour obtenir des instructions étape par étape, consultez Désactiver l’authentification locale.
Vue d’ensemble
Quand un principal de sécurité (un utilisateur, un groupe ou une application) tente d’accéder à une entité Service Bus, la requête doit être autorisée. Avec Microsoft Entra ID, l’accès à une ressource est un processus en deux étapes :
Pour commencer, l’identité du principal de sécurité est authentifiéeet un jeton OAuth 2.0 est renvoyé. Le nom de ressource à utiliser pour demander un jeton est https://servicebus.azure.net.
Ensuite, ce jeton est transmis dans une requête adressée au service Service Bus pour autoriser l’accès à la ressource spécifiée.
L’étape d’authentification nécessite qu’une requête d’application contienne un jeton d’accès OAuth 2.0 au moment de l’exécution. Si une application s’exécute dans une entité Azure telle qu’une machine virtuelle Azure, un groupe de machines virtuelles identiques ou une application de fonction Azure, elle peut utiliser une identité managée pour accéder aux ressources. Pour découvrir comment authentifier des requêtes adressées par une identité managée au service Service Bus, consultez Authentifier l’accès aux ressources Azure Service Bus avec Microsoft Entra ID et les identités managées pour les ressources Azure.
L’étape d’autorisation exige qu’un ou plusieurs rôles Azure soient attribués au principal de sécurité. Azure Service Bus fournit des rôles Azure qui englobent des ensembles d’autorisations pour les ressources Service Bus. Les rôles qui sont attribués à un principal de sécurité déterminent les autorisations dont disposera le principal sur les ressources Service Bus. Pour plus d’informations sur l’attribution de rôles Azure dans Azure Service Bus, consultez Rôles Azure intégrés pour Azure Service Bus.
Les applications natives et applications web qui adressent des requêtes à Service Bus peuvent également autoriser l’accès avec Microsoft Entra ID. Cet article explique comment demander un jeton d’accès et l’utiliser pour autoriser les demandes de ressources Service Bus.
Rôles Azure intégrés pour Azure Service Bus
Microsoft Entra autorise les droits d’accès aux ressources sécurisées via RBAC Azure. Azure Service Bus définit un ensemble de rôles Azure intégrés qui englobent les ensembles d’autorisations couramment utilisés pour accéder aux entités Service Bus. Il est également possible de définir des rôles personnalisés pour accéder aux données.
Lorsqu’un rôle Azure est attribué à un principal de sécurité Microsoft Entra, Azure octroie l’accès à ces ressources pour ce principal de sécurité. L’accès peut être limité au niveau de l’abonnement, du groupe de ressources, de l’espace de noms ou de l’entité Service Bus (file d’attente, rubrique ou abonnement). Un principal de sécurité Microsoft Entra peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée pour les ressources Azure.
Pour Azure Service Bus, la gestion des espaces de noms et de toutes les ressources associées via le Portail Azure et l’API de gestion des ressources Azure est déjà protégée à l’aide du modèle Azure RBAC. Azure fournit les rôles Azure intégrés suivants pour autoriser l’accès à un espace de noms Service Bus :
Avant d’attribuer un rôle Azure à un principal de sécurité, déterminez l’étendue de l’accès dont doit disposer le principal de sécurité. Selon les bonnes pratiques, il est toujours préférable d’accorder la plus petite étendue possible.
La liste suivante décrit les niveaux auxquels vous pouvez étendre l’accès aux ressources Service Bus, en commençant par la plus petite étendue :
File d’attente, rubrique ou abonnement : l’attribution de rôle s’applique à l’entité Service Bus spécifique. Actuellement, le portail Azure ne prend pas en charge l’affectation d’utilisateurs, de groupes ou d’identités managées aux rôles Azure Service Bus au niveau de l’abonnement de la rubrique.
Espace de noms Service Bus : l’attribution de rôle s’étend sur l’ensemble de la topologie de Service Bus sous l’espace de noms et sur l’abonnement de la file d’attente ou de la rubrique associé à celui-ci.
Groupe de ressources : l’attribution de rôle s’applique à toutes les ressources Service Bus sous le groupe de ressources.
Abonnement Azure : l’attribution de rôle s’applique à toutes les ressources Service Bus dans tous les groupes de ressources de l’abonnement.
Notes
Gardez à l’esprit que la propagation des attributions de rôles Azure peut prendre cinq minutes.
L’un des principaux avantages de l’utilisation de Microsoft Entra ID avec Service Bus est que vous n’avez plus besoin de stocker vos informations d’identification dans votre code. À la place, vous pouvez demander un jeton d’accès OAuth 2.0 sur la plateforme d’identités Microsoft. Microsoft Entra authentifie le principal de sécurité (un utilisateur, un groupe, un principal de service ou une identité managée pour les ressources Azure) qui exécute l’application. Si l’authentification réussit, Microsoft Entra ID retourne le jeton d’accès à l’application, qui peut ensuite l’utiliser pour autoriser les requêtes adressées à Azure Service Bus.
Les sections suivantes vous montrent comment configurer votre application native ou une application web pour l’authentification avec la plateforme d’identités Microsoft 2.0. Pour plus d’informations sur la plateforme d’identité Microsoft 2.0, veuillez consulter l’article Présentation de la plateforme d’identités Microsoft (v2.0).
Inscrire votre application auprès d’un locataire Microsoft Entra ID
La première étape d’utilisation de Microsoft Entra ID pour autoriser l’accès aux entités Service Bus consiste à inscrire votre application cliente auprès d’un locataire Microsoft Entra à partir du portail Azure. Lorsque vous inscrivez votre application cliente, vous fournissez des informations la concernant à Azure AD. Microsoft Entra ID fournit ensuite un ID client (également appelé ID d’application) que vous pouvez utiliser pour associer votre application au runtime Microsoft Entra. Pour en savoir plus sur l’ID client, consultez Objets application et principal de service dans Microsoft Entra ID.
Si vous inscrivez votre application comme une application native, vous pouvez spécifier n’importe quel URI valide pour l’URI de redirection. Pour les applications natives, cette valeur ne devra pas être une URL réelle. Pour les applications web, l’URI de redirection doit être un URI valide, car il spécifie l’URL à laquelle les jetons sont fournis.
Une fois votre application inscrite, l’ID d’application (client) et l’ID du répertoire (locataire) apparaîtront sous Paramètres :
Important
Notez les valeurs de TenantId et ApplicationId, car vous en aurez besoin pour exécuter l’application.
L’application a besoin d’une clé secrète client pour prouver son identité lors de la requête de jeton. Pour ajouter le secret client, effectuez ces étapes.
Accédez à la page d’inscription de votre application dans le portail Azure si vous n’y êtes pas déjà.
Dans le menu de gauche, sélectionnez Certificats et secrets.
Sous Secrets client, sélectionnez Nouveau secret client pour créer un secret.
Entrez une description pour le secret, choisissez un intervalle d’expiration, puis sélectionnez Ajouter.
Copiez immédiatement la valeur de la nouvelle clé secrète dans un emplacement sécurisé. La valeur de remplissage s’affiche pour vous une seule fois.
Autorisations pour l’API Service Bus
Si votre application est une application console, vous devez inscrire une application native et ajouter des autorisations d’API pour Microsoft.ServiceBus dans l’ensemble des autorisations requises. Les applications natives ont également besoin d’un redirect-uri dans Microsoft Entra ID, qui servira d’identificateur. Cet URI n’est pas obligatoirement une destination réseau. Utilisez https://servicebus.microsoft.com pour cet exemple, étant donné que l’exemple de code utilise déjà cet URI.
Attribuer des rôles Azure à l’aide du portail Azure
Attribuez un des rôles Service Bus au principal de service de l’application à l’étendue souhaitée (entité, espace de noms Service Bus, groupe de ressources, abonnement Azure). Pour connaître les étapes détaillées, consultez Attribuer des rôles Azure à l’aide du portail Azure.
Une fois que vous avez défini le rôle et son étendue, vous pouvez tester ce comportement à l’aide de l’exemple disponible sur GitHub.
Authentification du client Service Bus
Une fois que vous avez inscrit votre application et que vous lui avez accordé les autorisations nécessaires pour envoyer/recevoir des données dans Azure Service Bus, vous pouvez authentifier votre client avec les informations d’identification de la clé secrète client, ce qui vous permettra d’effectuer des requêtes sur Azure Service Bus.
TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);
Expliquez les fonctionnalités de Microsoft Entra ID pour moderniser des solutions d’identité, implémenter des solutions hybrides et une gouvernance des identités.