Teilen über

Authentifizieren und Autorisieren einer Anwendung mit Microsoft Entra-ID für den Zugriff auf Azure Service Bus-Entitäten

  • Artikel

Azure Service Bus unterstützt die Verwendung von Microsoft Entra ID, um Anforderungen an Service Bus-Entitäten (Warteschlangen, Themen, Abonnements oder Filter) zu autorisieren. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) zum Erteilen von Berechtigungen für einen Sicherheitsprinzipal verwenden, der ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen sein kann. Ein wesentlicher Vorteil der Verwendung von Microsoft Entra ID mit Azure Service Bus besteht darin, dass Sie Ihre Anmeldeinformationen nicht mehr im Code speichern müssen. Stattdessen können Sie ein OAuth 2.0-Zugriffstoken von der Microsoft Identity Platform anfordern. Wenn die Authentifizierung erfolgreich ist, gibt Microsoft Entra ID ein Zugriffstoken an die Anwendung zurück, und die Anwendung kann dann das Zugriffstoken zum Autorisieren von Anforderungen an Service Bus-Ressourcen verwenden.

Wichtig

Sie können lokale Authentifizierung oder SAS-Schlüsselauthentifizierung für einen Service Bus-Namespace deaktivieren und nur Microsoft Entra-Authentifizierung zulassen. Eine schrittweise Anleitung finden Sie unter Deaktivieren der lokalen Authentifizierung.

Übersicht

Wenn ein Sicherheitsprinzipal (ein Benutzer, eine Gruppe oder eine Anwendung) versucht, auf eine Service Bus-Entität zuzugreifen, muss die Anforderung autorisiert werden. Mit Microsoft Entra ID ist der Zugriff auf eine Ressource ein zweistufiger Prozess:

  1. Zunächst wird die Identität des Sicherheitsprinzipals authentifiziert und ein OAuth 2.0-Token zurückgegeben. Der Ressourcenname zum Anfordern eines Tokens ist https://servicebus.azure.net.
  2. Anschließend wird das Token als Teil einer Anforderung an den Service Bus-Dienst übergeben, um den Zugriff auf die angegebene Ressource zu autorisieren.

Für den Authentifizierungsschritt ist es erforderlich, dass eine Anwendungsanforderung zur Laufzeit ein OAuth 2.0-Zugriffstoken enthält. Wenn eine Anwendung in einer Azure-Entität, z.B. einer Azure-VM, einer VM-Skalierungsgruppe oder einer Azure Functions-App, ausgeführt wird, kann der Zugriff auf die Ressourcen über eine verwaltete Identität erfolgen. Informationen zum Authentifizieren von Anforderungen, die von einer verwalteten Identität an den Service Bus-Dienst übermittelt werden, finden Sie unter Authentifizieren des Zugriffs auf Azure Service Bus-Ressourcen mit Microsoft Entra ID und verwalteten Identitäten für Azure-Ressourcen.

Der Autorisierungsschritt erfordert, dass dem Sicherheitsprinzipal mindestens eine Azure-Rolle zugewiesen wird. Azure Service Bus stellt Azure-Rollen bereit, die Berechtigungssätze für Service Bus-Ressourcen enthalten. Die Rollen, die einem Sicherheitsprinzipal zugewiesen werden, bestimmen die Berechtigungen, die der Prinzipal auf Service Bus-Ressourcen hat. Weitere Informationen zur Zuweisung von Azure-Rollen zu Azure Service Bus finden Sie unter Integrierte Azure-Rollen für Azure Service Bus.

Native Anwendungen und Webanwendungen, die Anforderungen an Service Bus senden, können die Autorisierung ebenfalls mit Microsoft Entra ID durchführen. In diesem Artikel erfahren Sie, wie Sie ein Zugriffstoken anfordern und dieses zum Autorisieren von Anforderungen für Service Bus-Ressourcen verwenden.

Integrierte Azure-Rollen für Azure Service Bus

Microsoft Entra autorisiert Zugriffsrechte für gesicherte Ressourcen über Azure RBAC. Azure Service Bus definiert eine Reihe von integrierten Azure-Rollen, die allgemeine Berechtigungen für den Zugriff auf Service Bus-Entitäten umfassen. Sie können auch benutzerdefinierte Rollen für den Zugriff auf die Daten definieren.

Wenn einem Microsoft Entra-Sicherheitsprinzipal eine Azure-Rolle zugewiesen wird, gewährt Azure diesem Sicherheitsprinzipal Zugriff auf diese Ressourcen. Der Zugriff kann sich auf den Bereich des Abonnements, der Ressourcengruppe, des Namespace von Service Bus oder der Entität (Warteschlange, Thema oder Abonnement) beziehen. Ein Microsoft Entra-Sicherheitsprinzipal kann ein Benutzer/eine Benutzerin, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen sein.

Bei Azure Service Bus ist die Verwaltung der Namespaces und aller zugehörigen Ressourcen über das Azure-Portal und die Azure-Ressourcenverwaltungs-API bereits durch das Azure RBAC-Modell geschützt. Azure stellt die folgenden integrierten Rollen zum Autorisieren des Zugriffs auf einen Service Bus-Namespace bereit:

Ressourcenumfang

Bevor Sie einem Sicherheitsprinzipal eine Azure-Rolle zuweisen, legen Sie den Zugriffsbereich fest, den der Sicherheitsprinzipal haben soll. Es hat sich als am besten bewährt, stets nur den kleinstmöglichen Umfang an Zugriffsrechten zu gewähren.

In der folgenden Liste werden die Ebenen beschrieben, auf denen Sie den Zugriff auf Service Bus-Ressourcen einschränken können, beginnend mit dem kleinstmöglichen Bereich:

  • Warteschlange, Thema oder Abonnement: Die Rollenzuweisung gilt für die jeweilige Service Bus-Entität. Derzeit wird das Zuweisen von Benutzern/Gruppen/verwalteten Identitäten zu Service Bus-Azure-Rollen auf Themenabonnementebene vom Azure-Portal nicht unterstützt.

  • Service Bus-Namespace: Die Rollenzuweisung umfasst die gesamte Topologie von Service Bus unter dem Namespace und für die zugeordnete Warteschlange oder das zugeordnete Themenabonnement.

  • Ressourcengruppe: Die Rollenzuweisung gilt für alle Service Bus-Ressourcen unter der Ressourcengruppe.

  • Azure-Abonnement; Die Rollenzuweisung gilt für alle Service Bus-Ressourcen in allen Ressourcengruppen im Abonnement.

Hinweis

Denken Sie daran, dass die Weitergabe von Azure-Rollenzuweisungen bis zu fünf Minuten dauern kann.

Weitere Informationen dazu, wie integrierte Rollen definiert sind, finden Sie unter Grundlegendes zu Rollendefinitionen. Informationen zum Erstellen von benutzerdefinierten Azure-Rollen finden Sie unter Benutzerdefinierte Azure-Rollen.

Authentifizieren über eine Anwendung

Ein wesentlicher Vorteil der Verwendung von Microsoft Entra ID mit Service Bus besteht darin, dass Ihre Anmeldeinformationen nicht mehr im Code gespeichert werden müssen. Stattdessen können Sie ein OAuth 2.0-Zugriffstoken von Microsoft Identity Platform anfordern. Microsoft Entra authentifiziert den Sicherheitsprinzipal (ein Benutzer, eine Gruppe, ein Dienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen), der die Anwendung ausführt. Wenn die Authentifizierung erfolgreich ist, gibt Microsoft Entra ID das Zugriffstoken an die Anwendung zurück, und die Anwendung kann dann das Zugriffstoken zum Autorisieren von Anforderungen an Azure Service Bus verwenden.

In den folgenden Abschnitten wird gezeigt, wie Sie Ihre native Anwendung oder Webanwendung für die Authentifizierung mit Microsoft Identity Platform 2.0 konfigurieren. Weitere Informationen zu Microsoft Identity Platform 2.0 finden Sie unter Übersicht über Microsoft Identity Platform (v2.0).

Eine Übersicht über den Datenfluss für OAuth 2.0-Codeberechtigungen finden Sie unter Autorisieren des Zugriffs auf Microsoft Entra-Webanwendungen mit dem Flow zum Erteilen des OAuth 2.0-Codes.

Registrieren Ihrer Anwendung mit Microsoft Entra ID Mandanten

Der erste Schritt bei der Verwendung der Microsoft Entra-ID zum Autorisieren von ServiceBus-Entitäten besteht darin, Ihre Clientanwendung mit einem Microsoft Entra-Mandanten aus dem Azure-Portalzu registrieren. Wenn Sie Ihre Clientanwendung registrieren, stellen Sie Azure AD Informationen zu Ihrer Anwendung bereit. Microsoft Entra ID stellt dann eine Client-ID (auch als Anwendungs-ID bezeichnet) bereit, mit der Sie Ihre Anwendung zur Laufzeit Microsoft Entra zuordnen können. Weitere Informationen zur Client-ID finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.

Führen Sie die Schritte unter Schnellstart: Registrieren einer Anwendung mit der Microsoft-Identitätsplattform aus, um Ihre Anwendung mit Microsoft Entra ID zu registrieren.

Hinweis

Wenn Sie Ihre Anwendung als native Anwendung registrieren, können Sie jeden gültigen URI als Umleitungs-URI angeben. Bei nativen Anwendungen muss dieser Wert keine echte URL sein. Bei Webanwendungen muss der Umleitungs-URI ein gültiger URI sein, da er die URL definiert, für die Token bereitgestellt werden.

Nachdem Sie Ihre Anwendung registriert haben, wird die Anwendungs-ID (Client-ID) und die Verzeichnis-ID (Mandanten-ID) unter Einstellungen angezeigt:

Wichtig

Notieren Sie sich die Werte für TenantId und ApplicationId. Sie benötigen diese Werte, um die Anwendung auszuführen.

Screenshot zeigt die Seite „App-Registrierung“ mit Anwendungs-ID und Mandanten-ID.

Weitere Informationen zum Registrieren einer Anwendung mit der Microsoft Entra-ID finden Sie unter Integrieren von Anwendungen mit Microsoft Entra ID.

Erstellen eines Clientgeheimnisses

Die Anwendung benötigt zum Beweis ihrer Identität einen geheimen Clientschlüssel, wenn sie ein Token anfordert. Führen Sie folgende Schritte aus, um den geheimen Clientschlüssel hinzuzufügen.

  1. Navigieren Sie im Azure-Portal zu Ihrer App-Registrierung, wenn diese Seite noch nicht angezeigt wird.

  2. Wählen Sie im linken Menü Zertifikate und Geheimnisse aus.

  3. Wählen Sie unter Geheime Clientschlüssel die Option Neuer geheimer Clientschlüssel aus, um einen neuen geheimen Schlüssel zu erstellen.

    Screenshot zeig die Seite „Zertifikate und Geheimnisse“ mit ausgewählter Schaltfläche „Neuer geheimer Clientschlüssel“.

  4. Geben Sie eine Beschreibung für den geheimen Schlüssel an, und wählen Sie das gewünschte Ablaufintervall aus. Wählen Sie dann Hinzufügen aus.

    Screenshot zeigt die Seite „Hinzufügen eines geheimen Clientschlüssels“.

  5. Kopieren Sie den Wert des neuen geheimen Schlüssels sofort, und legen Sie die Kopie an einem sicheren Speicherort ab. Der Wert wird Ihnen nur ein Mal angezeigt.

    Screenshot zeigt den Abschnitt „Geheime Clientschlüssel“ mit dem von Ihnen hinzugefügten Geheimnis.

Berechtigungen für die Service Bus-API

Wenn es sich bei Ihrer Anwendung um eine Konsolenanwendung handelt, müssen Sie eine native Anwendung registrieren und den erforderlichen Berechtigungen API-Berechtigungen für Microsoft.ServiceBus hinzufügen. Native Anwendungen benötigen auch einen Umleitungs-URI in Microsoft Entra ID, der als Bezeichner fungiert. Beim URI muss es sich nicht um ein Netzwerkziel handeln. Verwenden Sie in diesem Beispiel https://servicebus.microsoft.com, da der Beispielcode diesen URI bereits verwendet.

Zuweisen von Azure-Rollen über das Azure-Portal

Weisen Sie eine der Service Bus-Rollen dem Dienstprinzipal der Anwendung im gewünschten Bereich (Entität, Service Bus-Namespace, Ressourcengruppe, Azure-Abonnement) zu. Ausführliche Informationen finden Sie unter Zuweisen von Azure-Rollen über das Azure-Portal.

Sobald Sie die Rolle und ihren Bereich definiert haben, können Sie dieses Verhalten mit dem Beispiel auf GitHub testen.

Authentifizieren des Service Bus-Clients

Nachdem Sie Ihre Anwendung registriert und ihr Berechtigungen zum Senden/Empfangen von Daten in Azure Service Bus erteilt haben, können Sie Ihren Client mit den Anmeldeinformationen mit geheimem Clientschlüssel authentifizieren, wodurch Sie Anforderungen an Azure Service Bus vornehmen können.

Eine Liste der Szenarien, für die das Abrufen von Token unterstützt wird, finden Sie im Abschnitt Szenarien im GitHub-Repository Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) für .NET.

Mithilfe der neuesten Azure.Messaging.ServiceBus-Bibliothek können Sie ServiceBusClient mit ClientSecretCredential authentifizieren (in der Azure.Identity-Bibliothek definiert).

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

Wenn Sie die älteren .NET-Pakete verwenden, sehen Sie sich die Beispiele für RoleBasedAccessControl im Repository mit Beispielen für „azure-service-bus“ an.

Nächste Schritte

Weitere Informationen zu Service Bus Messaging finden Sie in folgenden Themen.