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

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 Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen sein.

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 die Microsoft Entra-ID ein Zugriffstoken an die Anwendung zurück. Die Anwendung kann dann das Zugriffstoken verwenden, um Anforderungen an Service Bus-Ressourcen zu autorisieren.

Sie können die Lokale oder freigegebene Zugriffssignatur (SAS)-Schlüsselauthentifizierung für einen Service Bus-Namespace deaktivieren und nur die 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. Die Identität des Sicherheitsprinzipals wird authentifiziert, und ein OAuth 2.0-Token wird zurückgegeben. Der Ressourcenname zum Anfordern eines Tokens ist https://servicebus.azure.net.
  2. Das Token wird als Teil einer Anforderung an den ServiceBus-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 wie einem virtuellen Azure-Computer, einem Skalierungssatz eines virtuellen Computers oder einer Funktions-App ausgeführt wird, kann sie eine verwaltete Identität verwenden, um auf die Ressourcen zuzugreifen. Informationen zum Authentifizieren von Anforderungen, die eine verwaltete Identität am Service Bus-Dienst vorgibt, finden Sie unter Verwenden von verwalteten Identitäten mit Azure Service Bus.

Der Autorisierungsschritt erfordert die Zuweisung einer oder mehrerer Azure-Rollen zum Sicherheitsprinzipal. Service Bus stellt Azure-Rollen bereit, die Sätze von Berechtigungen für Service Bus-Ressourcen umfassen. Die Rollen, die einem Sicherheitsprinzipal zugewiesen sind, bestimmen die Berechtigungen, die der Prinzipal für Service Bus-Ressourcen besitzt. Weitere Informationen zum Zuweisen von Azure-Rollen zu Service Bus finden Sie in den integrierten 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 bietet eine Reihe in Azure integrierter Rollen mit allgemeinen Berechtigungen für den Zugriff auf Service Bus-Entitäten. 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 auf die Ebene des Abonnements, der Ressourcengruppe, des ServiceBus-Namespaces oder der Entität (Warteschlange, Thema oder Abonnement) festgelegt werden. Ein Microsoft Entra-Sicherheitsprinzipal kann ein Benutzer/eine Benutzerin, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen sein.

Für Azure Service Bus schützt das Azure RBAC-Modell die Verwaltung von Namespaces und alle zugehörigen Ressourcen über das Azure-Portal und die Azure-Ressourcenverwaltungs-API. 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: Rollenzuweisung gilt für die spezifische ServiceBus-Entität. Derzeit unterstützt das Azure-Portal das Zuweisen von Benutzern, Gruppen oder verwalteten Identitäten zu Service Bus Azure-Rollen auf Abonnementebene nicht.

  • Service Bus-Namespace: Die Rollenzuweisung erstreckt sich über die gesamte Topologie des Service Bus innerhalb des Namespace und auf die damit verbundene Warteschlange oder das zugehörige Themenabonnement.

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

  • Azure-Abonnement: Rollenzuweisung gilt für alle ServiceBus-Ressourcen in allen Ressourcengruppen im Abonnement.

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

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

Authentifizierung aus einer 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 der 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 die Microsoft Entra-ID das Zugriffstoken an die Anwendung zurück. Die Anwendung kann dann das Zugriffstoken verwenden, um Anforderungen an Service Bus zu autorisieren.

In den folgenden Abschnitten wird gezeigt, wie Sie Ihre systemeigene Anwendung oder Webanwendung für die Authentifizierung mit Microsoft Identity Platform 2.0 konfigurieren. Weitere Informationen zur Plattform finden Sie unter Was ist die Microsoft Identity Platform?.

Eine Übersicht über den OAuth 2.0-Codeerteilungsfluss finden Sie unter Microsoft Identity Platform und OAuth 2.0-Autorisierungscodefluss.

Registrieren Sie Ihre Anwendung bei einem Microsoft Entra-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, geben Sie Informationen zur Anwendung an Active Directory an. Microsoft Entra-ID stellt dann eine Client-ID (auch als Anwendungs-ID bezeichnet) bereit, die Sie verwenden können, um Ihre Anwendung der Microsoft Entra-Laufzeit zuzuordnen. Weitere Informationen zur Client-ID finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.

Führen Sie die Schritte unter Registrieren einer Anwendung in der Microsoft Entra-ID aus, um Ihre Anwendung mit der 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. Für systemeigene 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, werden die Anwendungs-ID (Client-ID) und die Verzeichnis-ID (Mandant) unter "Einstellungen" angezeigt. Notieren Sie sich diese Werte. Sie benötigen sie, um die Anwendung auszuführen.

Ein Screenshot, der eine Anwendungs-ID und eine Mandanten-ID im Bereich für die App-Registrierung zeigt.

Erstellen eines Clientgeheimnisses

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

  1. Wechseln Sie im Azure-Portal zu Ihrer App-Registrierung, wenn Sie sich noch nicht auf der Seite befinden.

  2. Wählen Sie im linken Menü "Zertifikate und Geheime Schlüssel" 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 der Schaltfläche zum Erstellen eines geheimen Clientschlüssels im Bereich für Zertifikate und geheime Schlüssel.

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

    Screenshot des Bereichs zum 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 vollständige Wert wird nur einmal angezeigt.

    Screenshot des Bereichs für geheime Clientschlüssel zusammen mit der Schaltfläche zum Kopieren eines geheimen Schlüssels.

Hinzufügen von Berechtigungen für die Dienstbus-API

Wenn Ihre Anwendung eine Konsolenanwendung ist, müssen Sie eine native Anwendung registrieren und API-Berechtigungen für Microsoft.ServiceBus zu den erforderlichen Berechtigungen hinzufügen.

Native Anwendungen benötigen auch einen Umleitungs-URI in Microsoft Entra ID, der als Bezeichner dient. Der URI muss kein Netzwerkziel sein. Verwenden Sie in diesem Beispiel https://servicebus.microsoft.com, da der Beispielcode diesen URI bereits verwendet.

Zuweisung von Azure-Rollen über das Azure-Portal

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

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

Authentifizierung des ServiceBus-Clients

Nachdem Sie Ihre Anwendung registriert und ihm Berechtigungen zum Senden/Empfangen von Daten in Azure Service Bus erteilt haben, können Sie Ihren Client mit den geheimen Anmeldeinformationen des Clientschlüssels authentifizieren. Mit dieser Authentifizierung können Sie Anforderungen an Azure Service Bus senden.

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

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

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, lesen Sie die Azure RBAC-Beispiele für Service Bus auf GitHub.

Verwandte Inhalte

  • Last updated on