VERTRIEB: 1-800-867-1380

Service Bus-Authentifizierung und -Autorisierung mit dem Zugriffssteuerungsdienst

Windows Azure Service Bus unterstützt die Verwendung von Zugriffssteuerung für Windows Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) für die Autorisierung von Service Bus-Vorgängen.

Zugriffssteuerung für Windows Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS)

ACS ermöglicht die Authentifizierung, richtet also die Identität eines Aufrufers ein. ACS verfügt über zwei Methoden zum Einrichten der Aufruferidentität. Die Identität wird basierend auf einer Namespacebereichliste der Dienstidentitäten (oder Konten) mithilfe eines klassischen Schemas aus Benutzername und Kennwort eingerichtet, oder das Einrichten der Identität wird an einen externen Identitätsanbieter (z. B. Active Directory-Verbunddienste (Active Directory Federation Services, ADFS), Windows Live ID, Facebook, Google ID, Yahoo ID oder OpenID) delegiert.

Nachdem die Identität eingerichtet wurde, verfügt ACS über mehrere "Ansprüche" hinsichtlich der Identität (oder empfängt diese). Diese Ansprüche machen Angaben zur Person (oder zum nicht personenbezogenen Konto), und sie werden vom Identitätsanbieter, der sie ausgestellt hat, digital signiert. Dies bestätigt ACS, dass die Ansprüche richtig oder mindestens mit den Verwaltungsregeln des Ausstellers kompatibel sind. Eine Sammlung von Regeln, die besagt, dass die dargestellte Identität "Bill Gates, Chairman, Microsoft Corporation" ist, ist vertrauenswürdiger, wenn sie vom Microsoft ADFS-Gateway ausgestellt wird, und weniger vertrauenswürdig, wenn sie von einem Drittanbieter stammt. Die Ansprüche, die konsistent identitätsanbieterübergreifend und auch für die in ACS integrierten Identitäten verfügbar sind, sind der Anbieteranspruch (der den Anbieter selbst identifiziert) und der Anspruch "nameidentifier", der ein anbieterspezifischer und für den Anbieter eindeutiger Bezeichner für die angegebene Identität ist.

ACS ermöglicht die Autorisierung außerdem, indem die von Identitätsanbietern ausgestellten Ansprüche Ansprüchen zugeordnet werden können, die von einer "vertrauenden Seite" verstanden werden. Service Bus ist eine solche vertrauende Seite. Dies bedeutet, dass ACS zum Verarbeiten der Authentifizierung und Autorisierung verwendet wird. Die Zuordnung der Ansprüche dient zwei Zwecken: Einerseits werden die Ansprüche aus einer Vielzahl unterschiedlicher "Anspruchsdialekte" in einer Sammlung von Ansprüchen normalisiert, die der Dienst versteht, andererseits fungiert die Zuordnung als Autorisierungsregelsatz. Wenn für eine bestimmte Identität keine Zuordnung zu einer Regelsammlung vorhanden ist, die der Dienst versteht, besitzt die Identität keinen Zugriff auf den Dienst.

Die Authentifizierung und Autorisierung durchläuft immer den Client, und der Client ist die einzige Komponente, die direkte Netzwerksichtbarkeit für alle Parteien erfordert. Es ist beispielsweise möglich, einen ADFS-Dienst zusammen mit ACS zu verwenden, der außerhalb der Unternehmensfirewall nicht bereitgestellt wird, da ACS und ADFS niemals direkt miteinander kommunizieren. Jedes Mal, wenn der Client einen Vorgang für eine geschützte Ressource ausführen möchte (z. B. das Senden einer Nachricht an eine Service Bus-Warteschlange), muss er eine Bestätigung abrufen, dass er autorisiert ist, diesen Vorgang auszuführen. Diese Bestätigung wird von ACS in Form eines "Tokens" abgerufen. Das Token ist einfach ein Container für eine Anspruchssammlung und wird vom Aussteller digital signiert. Wenn ACS so konfiguriert ist, dass die Identität mithilfe eines externen Identitätsanbieters wie etwa ADFS eingerichtet wird, sind mindestens zwei Token erforderlich. Das erste Token wird von einem Identitätsanbieter (z. B. ADFS) abgerufen und stellt eine der zahlreichen Bestätigungsmöglichkeiten für die Identität des Benutzers als Eingabe zur Verfügung. Dieses Token wird dann an ACS übergeben, ausgewertet, die Regeln werden ausgeführt, und das Token wird dann für die vertrauende Seite ausgegeben.

Service Bus und ACS

Zwischen Service Bus und ACS besteht eine besondere Beziehung, weil jeder Service Bus-Dienstnamespace einem entsprechenden ACS-Dienstnamespace des gleichen Namens mit dem Suffix "-sb" zugeordnet wird. Der Grund für diese besondere Beziehung ist die Art und Weise, wie Service Bus und ACS ihre gegenseitige Vertrauensbeziehung und die zugehörigen kryptografischen Schlüssel verwalten.

Service Bus kann einen Partnerverbund mit ACS V1 und mit ACS V2 eingehen. Alle Dienstnamespaces, die mit einer früheren Version als der Version von Service Bus aus September 2011 erstellt wurden, bilden einen Partnerverbund mit ACS V1, und alle Dienstnamespaces, die nach dem Dienstupgrade erstellt wurden, bilden einen Partnerverbund mit ACS V2. In diesem Thema wird nur ACS V2 behandelt, die aktuelle Version des ACS-Diensts.

Innerhalb des ACS-Dienstnamespaces "-sb", den Sie im Windows Azure-Portal anzeigen können, indem Sie den Service Bus-Dienstnamespace auswählen und dann im Menüband auf das ACS-Symbol klicken, findet sich eine "ServiceBus"-Definition der vertrauenden Seite, die auf die Option Anwendungen der vertrauenden Seite folgt. Die Definition der vertrauenden Seite weist einen Wert Bereich auf, der dem Stamm des entsprechenden Service Bus-Dienstnamespaces (mithilfe des "http"-Schemas) zugeordnet ist und den Tokentyp auf "SWT" sowie die Ablaufzeit auf 1.200 Sekunden festlegt. Außerdem können die Signaturschlüssel nicht über das Portal oder die API verwaltet werden, und der Zugriff darauf ist auf diese Weise ebenfalls nicht möglich.

Der "ServiceBus"-Definition der vertrauenden Seite ist eine Standardregelgruppe für Service Bus zugeordnet, die die grundlegende Zuordnung enthält, die es dem "Besitzer" eines Dienstnamespaces ermöglicht, als Administrator für den Dienstnamespace zu agieren. Die Regelgruppe enthält standardmäßig drei einfache Regeln, die den Eingabeanspruch "nameidentifier" für die Dienstidentität "owner" den drei Berechtigungsansprüchen zuordnen, die Service Bus versteht: "Senden" für alle Sendevorgänge, "Lauschen", um Listener zu öffnen oder Nachrichten zu empfangen, und "Verwalten", um den Status der Service Bus-Instanz zu beobachten oder zu verwalten. Service Bus ignoriert alle anderen Ansprüche, die in für die Anwendung ausgestellten Token enthalten sind. Die Dienstidentität "owner" ist eine reguläre Dienstidentität im ACS-Dienstnamespace. Es ist möglich, weitere Dienstidentitäten zu erstellen. Diese Vorgehensweise wird auch empfohlen. Die Verwendung der Identität "owner" sollte auf die Ausführung von Verwaltungsaufgaben eingeschränkt werden.

Definitionen und Bereich der vertrauenden Seite

Wenn ein Client ein Autorisierungstoken zum Senden einer Nachricht an eine Warteschlange anfordert, die z. B. unter https://tenant.servicebus.windows.net/my/test gespeichert ist, enthält die Tokenanforderung eine normalisierte Form der Zieladresse als Zielbereich. Diese "Normalisierung" verwendet einfach ein gemeinsames URI-Schema für alle Protokolle. Die Anforderung eines Tokens für die Interaktion mit einer Service Bus-Entität, die unter https://tenant.servicebus.windows.net/my/test oder sb://tenant.servicebus.windows.net/my/test gespeichert ist, erfolgt immer mithilfe eines Bereichs-URIs und des "http"-Schemas http://tenant.servicebus.windows.net/foo/bar. Daher müssen alle Definitionen der vertrauenden Seite ebenfalls das "normalisierte" URI-Schema "http" für den Bereichs-URI verwenden.

Wenn die Anforderung bei ACS eingeht, ordnet ACS den Bereichs-URI Definitionen der vertrauenden Seite zu, indem eine "längste Präfixübereinstimmung" verwendet wird. Dies bedeutet, dass die vertrauende Seite, deren "Bereichs-URI"-Adresse das längste verfügbare Präfix der Adresse ist, für die das Token angefordert wird, die Definition der vertrauenden Seite und die zugehörigen Regeldefinitionen ausgewählt und ausgeführt werden. Der Bereich der "ServiceBus"-Standarddefinition der vertrauenden Seite ist der gesamte entsprechende Service Bus-Dienstnamespace. Dies bedeutet, dass ihr Bereichs-URI entsprechend der Stammadresse des Service Bus-Dienstnamespaces ein Präfix aller möglichen Adressen für einen Service Bus-Dienstnamespace ist. Daher erteilen die für diese Definition der vertrauenden Seite aktivierten Regeldefinitionen Vollzugriff auf den gesamten Service Bus-Dienstnamespace.

Wenn Sie eine Sammlung von Autorisierungsregeln mit Bereich für eine Warteschlange erstellen möchten, die z. B. unter https://tenant.servicebus.windows.net/my/test gespeichert ist, erstellen Sie eine neue Definition der vertrauenden Seite und stellen dann die Adresse der Warteschlange oder ein Präfix dieser Adresse als Bereichs-URI der neuen Definition über das ACS-Portal oder die ACS-Verwaltungs-API zur Verfügung. Im Portal sind die folgenden Schritte erforderlich:

  • Klicken Sie unter Anwendungen der vertrauenden Seite auf Hinzufügen.

  • Geben Sie einen Anzeigenamen ein, z. B. MyTest.

  • Geben Sie http://tenant.servicebus.windows.net/MyTest als Bereichs-URI für den Bereich ein.

  • Wählen Sie SWT als Tokenformat aus.

  • Legen Sie Verschlüsselungsrichtlinie auf Keine fest.

  • Legen Sie Tokengültigkeitsdauer auf 1.200 Sekunden fest.

  • Klicken Sie auf Speichern.

Das Ergebnis ist eine Definition der vertrauenden Seite, die für diese Adresse exklusiv ist. Da ihr Bereichs-URI ein Suffix der integrierten "ServiceBus"-Definition der vertrauenden Seite ist, erbt die Definition automatisch die richtigen Signaturschlüssel, sodass Service Bus Token vertraut, die basierend auf der neuen Definition ausgestellt werden. Da jedoch bisher keine zugehörigen Regeln für die neue Definition der vertrauenden Seite vorhanden sind, kann niemand – nicht einmal der Besitzer – auf die Warteschlange zugreifen, weil selbst dann keine automatische implizite Vererbung von Regeln zwischen Definitionen der vertrauenden Seite erfolgt, wenn diese eine Hierarchie bilden.

Nachdem die neue Definition erstellt wurde, ist eine Standardregelgruppe für <Anzeigename> im Abschnitt Regelgruppen des ACS-Portals vorhanden. Diese neue Gruppe ist standardmäßig leer. Damit der Zugriff auf die Warteschlange erlaubt wird, müssend er Gruppe Regeln hinzugefügt werden. Dieser Vorgang wird im folgenden Abschnitt erläutert. Alternativ kann eine bereits vorhandene Regelgruppe mit Regeln für die Definition der vertrauenden Seite aktiviert werden. Jede Regelgruppe kann als eine separate Zugriffssteuerungsliste betrachtet werden, die an einer beliebigen Position in der Hierarchie der vertrauenden Seite aktiviert werden kann. Wenn Sie dateisystemähnliche Vererbung aktivieren möchten – z. B. Vererbung der Standardregeln des Service Bus-Dienstnamespaces – können Sie einfach die "Standardregelgruppe für ServiceBus" oder eine beliebige andere Regelgruppe für die Definition der vertrauenden Seite aktivieren. Zu diesem Zweck muss das Kontrollkästchen auf der rechten Seite im Abschnitt Regelgruppen der Definition der vertrauenden Seiten im Portal aktiviert werden. Soll eine allgemeine Sammlung von Zugriffsregeln auf eine Anzahl von Ressourcen angewendet werden (z. B. allgemeine Regeln für eine Sammlung paralleler Ressourcen wie etwa gleichgeordnete Warteschlangen unter http://tenant.servicebus.windows.net/my/test und http://tenant.servicebus.windows.net/my/zoo), kann der Bereich der Definition der vertrauenden Seite auch auf den gemeinsamen Dienstnamespacezweig festgelegt werden, z. B. auf http://tenant.servicebus.windows.net/my.

Unter anderen Umständen verlangen Szenarien ggf. eine unterschiedliche Verwaltung der Zugriffssteuerung für Aspekte der gleichen Service Bus-Entität, z. B. verschiedene Berechtigungen für verschiedene Abonnements eines Themas. In diesen Fällen ist es möglich, eine Definition der vertrauenden Seite zu erstellen, deren Bereich ein bestimmter Abonnementname ist, z. B. http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/. Diese Definition kann dann die Regeln enthalten, die nur für das jeweilige benannte Abonnement gelten.

Definieren von Regeln

Regeln werden in Regelgruppen definiert und ordnen im Allgemeinen einen Eingabeanspruch einem Ausgabeanspruch zu. Alle Regeln in einer Gruppe führen zu einem einzigen, kombinierten Ergebnis. Wenn also drei übereinstimmende Regeln für eine angegebene Eingabeanspruchssammlung vorhanden sind, die drei separate Ausgabeansprüche ergeben, enthält das ausgestellte Autorisierungstoken alle drei Ansprüche. Für Service Bus lauten die drei Berechtigungsansprüche "Senden" für alle Sendevorgänge, "Lauschen", um Listener zu öffnen oder Nachrichten zu empfangen, und "Verwalten", um den Status der Service Bus-Instanz zu beobachten oder zu verwalten. "Senden", "Lauschen" und "Verwalten" sind also die zulässigen Werte des Anspruchstyps "net.windows.servicebus.action". Für das Erstellen einer Regel für Service Bus ist die Zuordnung eines Eingabeanspruchs erforderlich, z. B. von nameidentifier einer Dienstidentität zum gewünschten Berechtigungsanspruch. Wenn der Dienstidentität "contoso" die Berechtigung "Senden" für eine Warteschlange erteilt werden soll, ordnet die Regeldefinition daher den Anspruch "nameidentifier" des Ausstellers mit dem Wert "contoso" einem benutzerdefinierten Ausgabeanspruch vom Typ "net.windows.servicebus.action" mit dem Wert "Senden" zu. Wenn der Dienstidentität alle drei Berechtigungsansprüche erteilt werden sollen, sind drei separate Regeln erforderlich. Das Ziel von nur drei Berechtigungsansprüchen besteht darin, die Komplexität der Regeldefinition zu verringern.

Verwenden von Tokenanbietern

Ein Tokenanbieter ist ein generisches Konstrukt in der verwalteten .NET-API für Service Bus, das die Konvertierung von Anmeldeinformationen in ein vom ACS-Dienst ausgestelltes Autorisierungstoken ermöglicht, das dann an Service Bus übergeben werden kann, um den gewünschten Vorgang auszuführen. TokenProvider ist eine abstrakte Basisklasse mit drei konkreten Implementierungen, auf die über Factorymethoden für die meisten Grundszenarien zugegriffen werden kann:

  • Gemeinsamer geheimer Schlüssel – Ermöglicht den Abruf eines Tokens basierend auf einer Dienstidentität (und eines gemeinsamen Schlüssels, der dieser Identität zugeordnet ist), die im privaten Namespace des Service Bus-Dienstnamespaces "-sb" in ACS definiert wurde. Die vorab bereitgestellte Dienstidentität, die beim Erstellen des Dienstnamespaces erstellt wird, heißt "owner", und ihr gemeinsamer geheimer Schlüssel ist über das Verwaltungsportal verfügbar.

  • SWT (Simple Web Token) – Ermöglicht den Abruf eines Tokens basierend auf einem zuvor abgerufenen SWT-Token, das über den Tokenanbieter an ACS übergeben wird. Das Token wird an ACS als Binärtoken mithilfe einer WS-Trust/WS-Federation RST/RSTR-Anforderung übergeben. Weitere Informationen zum Konfigurieren von WS-Verbundanbietern finden Sie in der ACS-Dokumentation.

  • SAML – Ermöglicht den Abruf eines Tokens basierend auf einem zuvor abgerufenen SAML-Token, das über den Tokenanbieter an ACS übergeben wird. Das Token wird an ACS mithilfe einer WS-Trust/WS-Federation RST/RSTR-Anforderung übergeben. Weitere Informationen zum Konfigurieren von WS-Verbundanbietern finden Sie in der ACS-Dokumentation.

Die Service Bus MessagingFactory-, NamespaceManager- und TransportClientEndpointBehavior-APIs akzeptieren TokenProvider-Instanzen. Der Tokenanbieter wird aufgerufen, wenn Token erforderlich sind. Dies gilt auch in Szenarien, in denen eine langlebige Verbindung ein neues Token abrufen muss, sobald das vorhandene Token seinen Gültigkeitsdauer (standardmäßig 1.200 Sekunden) überschritten hat. In Verbundszenarien, die Benutzerinteraktion erfordern, muss ein benutzerdefinierter Tokenanbieter implementiert werden.

Beispiel: Wenn ein benutzerdefinierter Tokenanbieter einen bestimmten Benutzer von Facebook für das Senden von Nachrichten an eine bestimmte Warteschlange aktivieren möchte, muss er dem Benutzer über ACS die entsprechende Facebook-Benutzeroberfläche bereitstellen, um die Facebook-Identität herzustellen, dann eine Weiterleitung über ACS zum Eintauschen des Facebook-Tokens gegen ein ACS-Token für Service Bus einrichten und anschließend das ACS-Token extrahieren, wenn die Anforderung an die lokale Anwendung weitergeleitet wird. Die CodePlex-Website für Service Bus enthält eine stetig wachsende Sammlung von Tokenanbieterbeispielen, die angepasst werden können.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

Anzeigen:
© 2014 Microsoft