Partager via

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 :

  1. 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.
  2. 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 :

Étendue des ressources

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.

Remarque

Gardez à l’esprit que la propagation des attributions de rôles Azure peut prendre cinq minutes.

Pour plus d’informations sur la définition des rôles intégrés, consultez Comprendre les définitions de rôles. Pour plus d’informations sur la création de rôles personnalisés Azure, consultez Rôles personnalisés Azure.

Authentifier à partir d’une application

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).

Pour avoir une vue d’ensemble du flux d’octroi de code OAuth 2.0, consultez Autoriser l’accès aux applications web Microsoft Entra à l’aide du flux d’octroi de code OAuth 2.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.

Suivez les étapes indiquées dans Démarrage rapide : Inscrire une application avec la plateforme d’identités Microsoft pour inscrire votre application auprès de Microsoft Entra ID.

Remarque

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.

Capture d’écran de la page Inscription de l’application montrant l’ID d’application et l’ID de locataire.

Pour plus d’informations sur l’inscription d’une application auprès de Microsoft Entra ID, consultez Intégration d’applications à Microsoft Entra ID.

Créer une clé secrète client

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.

  1. Accédez à la page d’inscription de votre application dans le portail Azure si vous n’y êtes pas déjà.

  2. Dans le menu de gauche, sélectionnez Certificats et secrets.

  3. Sous Secrets client, sélectionnez Nouveau secret client pour créer un secret.

    Capture d’écran de la page Certificats et secrets avec le bouton Nouveau secret client sélectionné.

  4. Entrez une description pour le secret, choisissez un intervalle d’expiration, puis sélectionnez Ajouter.

    Capture d’écran de la page Ajouter un secret client.

  5. 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.

    Capture d’écran de la section Secrets client avec le secret que vous avez ajouté.

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.

Pour obtenir la liste de scénarios pour lesquels l’acquisition de jetons est pris en charge, veuillez consulter la section Scénarios du référentiel GitHub Bibliothèque d’authentification Microsoft (MSAL) pour .NET.

À l’aide de la bibliothèque Azure.Messaging.ServiceBus la plus récente, vous pouvez authentifier le ServiceBusClient avec un ClientSecretCredential, qui est défini dans la bibliothèque Azure.Identity.

TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);

Si vous utilisez les anciens packages .NET, consultez les exemples de RoleBasedAccessControl dans le référentiel d’exemples azure-service-bus.

Étapes suivantes

Pour en savoir plus sur la messagerie Service Bus, voir les rubriques suivantes.