Authentifier et autoriser une application avec Microsoft Entra ID pour accéder aux entités Azure Service Bus

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). Avec l’ID Microsoft Entra, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité 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, l’ID Microsoft Entra retourne un jeton d’accès à l’application. L’application peut ensuite utiliser le jeton d’accès pour autoriser les demandes adressées aux ressources Service Bus.

Vous pouvez désactiver l’authentification par signature d’accès local ou partagé (SAP) 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 l’ID Microsoft Entra, l’accès à une ressource est un processus en deux étapes :

  1. L’identité du principal de sécurité est authentifiée et un jeton OAuth 2.0 est retourné. Le nom de ressource à utiliser pour demander un jeton est https://servicebus.azure.net.
  2. Le jeton est transmis dans le cadre d’une demande 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, elle peut utiliser une identité managée pour accéder aux ressources. Pour savoir comment authentifier les demandes qu’une identité managée effectue auprès du service Service Bus, consultez Utiliser des identités managées avec Azure Service Bus.

L’étape d’autorisation nécessite l’attribution d’un ou plusieurs rôles Azure au principal de sécurité. Service Bus fournit des rôles Azure qui englobent des ensembles d’autorisations pour les ressources Service Bus. Les rôles affectés à un principal de sécurité déterminent les autorisations dont dispose le principal sur les ressources Service Bus. Pour en savoir plus sur l’attribution de rôles Azure à Service Bus, consultez les rôles intégrés Azure 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 intégrés Azure qui englobent les ensembles courants d’autorisations utilisés pour accéder aux entités de Service Bus. Vous pouvez également définir des rôles personnalisés pour l’accès 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 Service Bus ou de l’entité (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, le modèle RBAC Azure permet de protéger 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. 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’attribution d’utilisateurs, de groupes ou d’identités managées aux rôles Azure Service Bus au niveau de l’abonnement à la rubrique.

  • Espace de noms Service Bus : L’attribution de rôle s'applique à l'ensemble de la topologie de Service Bus dans l'espace de noms, ainsi qu'à la file d'attente ou à l'abonnement à un sujet associé.

  • 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 de tous les groupes de ressources de l’abonnement.

Gardez à l’esprit que la propagation des affectations 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 Azure. Pour plus d’informations sur la création de rôles personnalisés Azure, consultez Rôles personnalisés Azure.

Authentification à 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. Au lieu de cela, vous pouvez demander un jeton d’accès OAuth 2.0 auprès de la plateforme d’identité 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, l’ID Microsoft Entra retourne le jeton d’accès à l’application. L’application peut ensuite utiliser le jeton d’accès pour autoriser les demandes adressées à Service Bus.

Les sections suivantes montrent comment configurer votre application native ou votre application web pour l’authentification avec La plateforme d’identités Microsoft 2.0. Pour plus d’informations sur la plateforme, consultez Qu’est-ce que la plateforme d’identités Microsoft ?.

Pour obtenir une vue d’ensemble du flux d’octroi de code OAuth 2.0, consultez la plateforme d’identités Microsoft et le flux de code d’autorisation OAuth 2.0.

Inscrire votre application auprès d’un tenant Microsoft Entra

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 sur l’application dans Active Directory. 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, voir Objets d’application et principaux de service dans Microsoft Entra ID.

Pour inscrire votre application avec l’ID Microsoft Entra, suivez les étapes de l’inscription d’une application dans l’ID Microsoft Entra.

Remarque

Si vous inscrivez votre application en tant qu’application native, vous pouvez spécifier n’importe quel URI valide pour l’URI de redirection. Pour les applications natives, cette valeur n’a pas besoin d’ê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 que vous avez inscrit votre application, l’ID d’application (client) et l’ID d’annuaire (locataire) apparaissent sous Paramètres. Notez ces valeurs. Vous en aurez besoin pour exécuter l’application.

Capture d’écran montrant un ID d’application et un ID de locataire dans le volet pour l’inscription de l’application.

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, procédez comme suit :

  1. Dans le portail Azure, accédez à votre inscription d’application si vous n’êtes pas déjà sur la page.

  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 montrant le bouton permettant de créer un secret client dans le volet pour les certificats et les secrets.

  4. Fournissez une description du secret, choisissez l’intervalle d’expiration, puis sélectionnez Ajouter.

    Capture d’écran montrant le volet permettant d’ajouter une clé secrète client.

  5. Copiez immédiatement la valeur de la nouvelle clé secrète dans un emplacement sécurisé. La valeur complète ne s’affiche qu’une seule fois.

    Capture d’écran montrant la zone des secrets client, ainsi que le bouton permettant de copier un secret.

Ajouter des 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 à l'ensemble des autorisations requises pour Microsoft.ServiceBus.

Les applications natives ont également besoin d’un URI de redirection dans Microsoft Entra ID, qui sert d’identificateur. L’URI n’a pas besoin d’être une destination réseau. Utilisez https://servicebus.microsoft.com pour cet exemple, étant donné que l’exemple de code utilise déjà cet URI.

Attribution de rôles Azure via le portail Azure

Attribuez l’un des rôles Service Bus au principal de service de l’application au niveau de l’étendue souhaitée (entité, espace de noms Service Bus, groupe de ressources ou abonnement Azure). Pour connaître les étapes détaillées, consultez Attribuer des rôles Azure à l’aide du portail Azure.

Après avoir défini le rôle et son étendue, vous pouvez tester ce comportement avec l’exemple sur GitHub.

Authentification du client Service Bus

Après avoir inscrit votre application et accordé des autorisations 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. Cette authentification vous permet d’effectuer des requêtes sur Azure Service Bus.

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

En utilisant la dernière bibliothèque Azure.Messaging.ServiceBus , vous pouvez authentifier ServiceBusClient avec 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 Azure RBAC pour Service Bus sur GitHub.

Contenu connexe

  • Last updated on