Service Bus-Zugriffssteuerung mit Shared Access Signatures
In diesem Artikel werden Shared Access Signatures (SAS), ihre Funktionsweise und die plattformunabhängige Verwendung mit Azure Service Bus beschrieben.
SAS überwacht den Zugriff auf Service Bus auf der Grundlage von Autorisierungsregeln, die entweder für einen Namespace oder eine Messagingentität (Warteschlange oder Thema) konfiguriert werden. Eine Autorisierungsregel hat einen Namen, ist mit bestimmten Rechten verknüpft und enthält ein Paar kryptografischer Schlüssel. Sie verwenden den Namen und den Schlüssel der Regel über das Service Bus SDK oder in Ihrem eigenen Code, um ein SAS-Token zu generieren. Ein Client kann dann das Token an Service Bus übergeben, um die Autorisierung für den angeforderten Vorgang zu bestätigen.
Hinweis
Azure Service Bus unterstützt das Autorisieren des Zugriffs auf einen Service Bus-Namespace und dessen Entitäten mithilfe von Microsoft Entra ID. Das Autorisieren von Benutzern oder Anwendungen mithilfe eines von Microsoft Entra ID zurückgegebenen OAuth 2.0-Tokens bietet mehr Sicherheit und Benutzerfreundlichkeit als die Autorisierung per SAS (Shared Access Signature). SAS-Schlüssel haben keine fein abgestufte Zugriffssteuerung, sind schwierig zu verwalten/rotieren und verfügen nicht über die Überwachungsfunktionen, um ihre Verwendung einem bestimmten Benutzer oder Dienstprinzipal zuzuordnen. Aus diesen Gründen empfehlen wir die Verwendung von Microsoft Entra ID.
Microsoft empfiehlt die Verwendung von Microsoft Entra ID für Ihre Azure Service Bus-Anwendungen, wenn dies möglich ist. Weitere Informationen finden Sie in den folgenden Artikeln:
- Authentifizieren und Autorisieren einer Anwendung mit Microsoft Entra ID für den Zugriff auf Azure Service Bus-Entitäten.
- Authentifizieren einer verwalteten Identität mit Microsoft Entra ID für den Zugriff auf Azure Service Bus-Ressourcen
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 über SAS
Shared Access Signatures sind ein anspruchsbasierter Autorisierungsmechanismus mit einfachen Token. Wenn Sie SAS verwenden, werden Schlüssel nie über das Netzwerk übergeben. Schlüssel werden verwendet, um Informationen kryptografisch zu signieren, die später vom Dienst überprüft werden können. SAS kann wie ein Schema aus Benutzername und Kennwort verwendet werden, bei dem der Client unmittelbar den Namen einer Autorisierungsregel und einen passenden Schlüssel besitzt. SAS kann auch ähnlich wie ein Verbundsicherheitsmodell verwendet werden, bei dem der Client ein zeitlich begrenztes und signierte Zugriffstoken von einem Sicherheitstokendienst erhält, ohne den Signaturschlüssel überhaupt zu besitzen.
Die SAS-Authentifizierung wird in Service Bus mit benannten SAS-Autorisierungsrichtlinien, denen Zugriffsrechte zugeordnet sind, und einem Paar aus primären und sekundären kryptografischen Schlüsseln konfiguriert. Die Schlüssel sind 256-Bit-Werte in Base64-Darstellung. Sie können Regeln auf Namespaceebene für Service Bus-Warteschlangen und -Themen konfigurieren.
Hinweis
Bei diesen Schlüsseln handelt es sich um Nur-Text-Zeichenfolgen, die eine Base64-Darstellung verwenden und nicht decodiert werden dürfen, bevor sie verwendet werden.
Das Shared Access Signature-Token enthält den Namen der ausgewählten Autorisierungsrichtlinie, den URI der Ressource, auf die zugegriffen werden muss, einen Ablaufwert und eine kryptografische HMAC-SHA256-Signatur, die mithilfe des primären oder sekundären Kryptografieschlüssels für die ausgewählte Autorisierungsregel über diese Felder berechnet wird.
SAS-Autorisierungsrichtlinien
Alle Service Bus-Namespaces und Service Bus-Entitäten verfügen über eine SAS-Autorisierungsrichtlinie, die aus Regeln besteht. Die Richtlinie auf Namespaceebene gilt für alle Entitäten innerhalb des Namespace, unabhängig von ihrer jeweiligen Richtlinienkonfiguration.
Jede Regel einer Autorisierungsrichtlinie erfordert drei Angaben: Name, Bereich und Rechte. Der Name ist ein eindeutiger Name innerhalb des Bereichs. Der Bereich ist der URI der betreffenden Ressource. Für einen Service Bus-Namespace ist der Bereich der vollqualifizierte Namespace, z. B. https://<yournamespace>.servicebus.windows.net/.
Die durch die Richtlinienregel gewährten Rechte können eine Kombination aus Folgendem sein:
- Senden: gewährt das Recht zum Senden von Nachrichten an die Entität.
- Lauschen: gewährt das Recht zum Empfangen (Warteschlangen, Abonnements) und zur zugehörigen Nachrichtenverarbeitung.
- Verwalten: gewährt das Recht zum Verwalten der Topologie des Namespace, einschließlich Erstellen und Löschen von Entitäten.
Das Recht Verwalten umfasst auch die Rechte „Senden“ und „Lauschen“.
Eine Namespace- oder Entitätenrichtlinie kann bis zu 12 SAS-Autorisierungsregeln aufweisen und bietet so Platz für drei Sätze von Regeln, die jeweils die grundlegenden Rechte und die Kombination aus „Senden“ und „Lauschen“ abdecken. Dieser Grenzwert gilt pro Entität, d. h. der Namespace und jede Entität kann bis zu 12 SAS-Autorisierungsregeln aufweisen. Mit dieser Einschränkung wird verdeutlicht, dass der SAS-Richtlinienspeicher nicht als Benutzer- oder Dienstkontospeicher vorgesehen ist. Wenn Ihre Anwendung Zugriff auf Service Bus basierend auf Benutzer- oder Dienstidentitäten gewähren muss, sollte sie einen Sicherheitstokendienst implementieren, der nach einer Authentifizierungs- und Zugriffsprüfung SAS-Token ausstellt.
Einer Autorisierungsregel wird ein Primärschlüssel und ein Sekundärschlüssel zugewiesen. Hierbei handelt es sich um sichere Kryptografieschlüssel. Achten Sie darauf, dass sie Ihnen nicht abhanden kommen: Sie sind immer im Azure-Portal verfügbar. Sie können einen beliebigen der generierten Schlüssel verwenden und die Schlüssel jederzeit erneut generieren. Wenn Sie einen Schlüssel in der Richtlinie neu erstellen oder ändern, sind alle zuvor basierend auf diesem Schlüssel ausgestellten Token sofort ungültig. Ausgehende Verbindungen, die basierend auf solchen Token erstellt wurden, funktionieren allerdings weiterhin, bis das Token abgelaufen ist.
Wenn Sie einen Service Bus-Namespace erstellen, wird automatisch eine Richtlinie namens RootManageSharedAccessKey für den Namespace erstellt. Diese Richtlinie hat die Berechtigung „Verwalten“ für den gesamten Namespace. Es wird empfohlen, dass Sie diese Regel wie ein administratives Stammkonto behandeln und nicht in Ihrer Anwendung verwenden. Sie können auf der Registerkarte SAS-Richtlinien für den Namespace im Portal, mit PowerShell oder über die Azure-Befehlszeilenschnittstelle weitere Richtlinienregeln erstellen.
Es wird empfohlen, die im SharedAccessAuthorizationRule-Objekt verwendeten Schlüssel in regelmäßigen Abständen neu zu generieren. Die Primär- und Sekundärschlüsselslots sind vorhanden, damit Sie Schlüssel schrittweise rotieren können. Wenn Ihre Anwendung im Allgemeinen den Primärschlüssel verwendet, können Sie den Primärschlüssel in den Sekundärschlüsselslot kopieren und erst dann den Primärschlüssel erneut generieren. Der neue Primärschlüsselwert kann dann in den Clientanwendungen konfiguriert werden, die ununterbrochenen Zugriff mit dem alten Primärschlüssel im sekundären Slot haben. Sobald alle Clients aktualisiert wurden, können Sie den Sekundärschlüssel erneut generieren, um schließlich den alten Primärschlüssel außer Kraft zu setzen.
Wenn Sie wissen oder vermuten, dass ein Schlüssel gefährdet ist, und Sie die Schlüssel widerrufen müssen, können Sie sowohl den PrimaryKey als auch den SecondaryKey eines SharedAccessAuthorizationRule-Objekts neu generieren und so durch neue Schlüssel ersetzen. Durch dieses Verfahren werden alle Token, die mit den alten Schlüsseln signiert wurden, für ungültig erklärt.
Bewährte Methoden bei Verwendung von SAS
Wenn Sie Shared Access Signatures in Ihren Anwendungen verwenden, müssen Sie sich der potenziellen Risiken bewusst sein:
- Offengelegte SAS können von allen Personen, in deren Besitz sie gelangen, verwendet werden. Dies kann die Sicherheit Ihrer Service Bus-Ressourcen gefährden.
- Wenn die SAS einer Clientanwendung abläuft und die Anwendung keine neue SAS von Ihrem Dienst abrufen kann, wird die Funktionsweise der Anwendung unter Umständen eingeschränkt.
Mit den folgenden Empfehlungen für die Verwendung von Shared Access Signatures können Sie diese Risiken verringern:
- Sorgen Sie dafür, dass die Clients die SAS bei Bedarf automatisch erneuern müssen: Die Clients sollten ihre SAS rechtzeitig vor der Ablaufzeit erneuern, um Zeit für Wiederholungsversuche zuzulassen, falls der entsprechende Dienst nicht verfügbar sein sollte. Falls Ihre SAS für eine kleine Anzahl sofortiger und kurzfristiger Vorgänge gilt, die normalerweise innerhalb des Ablaufzeitraums abgeschlossen werden, ist dies unter Umständen nicht notwendig, da die SAS nicht erneuert werden müssen. Wenn Ihre Clients jedoch immer wieder Anfragen über die SAS stellen, müssen Sie sich mit dem Ablaufmechanismus auseinander setzen. Dabei müssen Sie zwischen der Notwendigkeit der Kurzlebigkeit einer SAS (wie zuvor beschrieben) und der Sicherstellung einer rechtzeitigen Anforderung der Erneuerung durch den Client abwägen. So verhindern Sie, dass die SAS vor einer erfolgreichen Erneuerung abläuft.
- Seien Sie vorsichtig bei der SAS-Startzeit: Wenn Sie die Startzeit der SAS auf jetzt festlegen, können aufgrund von Zeitunterschieden zwischen unterschiedlichen Computern in den ersten Minuten Probleme auftreten. Üblicherweise sollten Sie als Startzeit eine Uhrzeit angeben, die mindestens 15 Minuten in der Vergangenheit liegt. Sie können auch so vorgehen, dass Sie keine Startzeit festlegen, damit die Aktivierung immer sofort erfolgt. Dasselbe gilt auch für die Ablaufzeit. Beachten Sie, dass es für alle Anforderungen in beiden Richtungen zu Zeitabweichungen von bis zu 15 Minuten kommen kann.
- Geben Sie die Ressource, auf die zugegriffen werden soll, exakt an: Aus Sicherheitsgründen sollten Benutzer nur die minimal erforderlichen Berechtigungen erhalten. Wenn ein Benutzer nur Lesezugriff auf eine einzige Entität benötigt, dann geben Sie auch nur Lesezugriff auf diese Entität, und nicht Lese-/Schreib-/Löschzugriff auf alle Entitäten. So lässt sich auch der Schaden verringern, wenn eine SAS kompromittiert wurde, weil die SAS dem Angreifer weniger Angriffsmöglichkeiten bietet.
- Nicht nur SAS verwenden: Manchmal überwiegen die Risiken eines bestimmten Vorgangs für Ihre Service Bus-Instanz gegenüber den Vorzügen von SAS. Erstellen Sie für Vorgänge dieser Art einen Dienst auf der mittleren Ebene, der in Ihre Service Bus-Instanz schreibt, nachdem die Überprüfung der Geschäftsregeln, die Authentifizierung und die Überwachung durchgeführt wurden.
- Verwenden Sie immer HTTPs: Verwenden Sie zum Erstellen oder Verteilen einer SAS immer HTTPS. Wenn eine SAS über HTTP weitergegeben und abgefangen wird, kann ein Angreifer diese mit einem Man-in-the-Middle-Angriff auslesen, anschließend im Namen des Benutzers verwenden und somit unter Umständen sensible Daten gefährden oder böswillig beschädigen.
Konfiguration für SAS-Authentifizierung (Shared Access Signature)
Sie können die SAS-Autorisierungsrichtlinie für Service Bus-Namespaces, -Warteschlangen oder -Themen konfigurieren. Die Konfiguration für ein Service Bus-Abonnement wird zurzeit nicht unterstützt, Sie können die Regeln, die für einen Namespace oder ein Thema konfiguriert wurden, allerdings verwenden, um den Zugriff auf Abonnements zu sichern.
In dieser Abbildung gelten die Autorisierungsregeln manageRuleNS, sendRuleNS und listenRuleNS sowohl für die Warteschlange Q1 als auch für das Thema T1. listenRuleQ und sendRuleQ gelten nur für Warteschlange Q1, und sendRuleT gilt nur für Thema T1.
Generieren eines SAS-Tokens
Jeder Client mit Zugriff auf den Namen einer Autorisierungsregel und einen von deren Signaturschlüsseln kann ein SAS-Token generieren. Zur Tokengenerierung wird eine Zeichenfolge im folgenden Format erstellt:
SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>
se: Tokenablaufwert. Ganze Zahl, die die Sekunden seit der Epoche00:00:00 UTCam 1. Januar 1970 (UNIX-Epoche) darstellt, als Ablaufdatum des Tokens.skn: Name der Autorisierungsregel.sr: URL-codierter URI der Ressource, auf die zugegriffen wirdsig: URL-codierte HMACSHA256-Signatur. Die Berechnung des Hashwerts ähnelt dem folgenden Pseudocode und gibt die Base64-Codierung einer unformatierten binären Ausgabe zurück.urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
Wichtig
Beispiele zum Generieren eines SAS-Tokens unter Verwendung verschiedener Programmiersprachen finden Sie unter Generieren eines SAS-Tokens.
Das Token enthält die Werte ohne Hash, sodass der Empfänger den Hash mit den gleichen Parametern neu berechnen und überprüfen kann, ob der Aussteller im Besitz eines gültigen Signaturschlüssels ist.
Der Ressourcen-URI ist der vollständige URI der Service Bus-Ressource, auf die der Zugriff beansprucht wird. Beispiel: http://<namespace>.servicebus.windows.net/<entityPath> oder sb://<namespace>.servicebus.windows.net/<entityPath>, also http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.
Der URI muss als Prozentwert codiert sein.
Die zum Signieren verwendete SAS-Autorisierungsregel muss für die durch diesen URI angegebene Entität oder eines seiner hierarchisch übergeordneten Elemente konfiguriert werden. Beispiel: http://contoso.servicebus.windows.net/contosoTopics/T1 oder http://contoso.servicebus.windows.net im vorherigen Beispiel.
Ein SAS-Token ist für alle Ressourcen mit dem Präfix <resourceURI> gültig, das in signature-string verwendet wird.
Neugenerieren von Schlüsseln
Es wird empfohlen, die in der SAS-Autorisierungsrichtlinie verwendeten Schlüssel in regelmäßigen Abständen neu zu generieren. Die Primär- und Sekundärschlüsselslots sind vorhanden, damit Sie Schlüssel schrittweise rotieren können. Wenn Ihre Anwendung im Allgemeinen den Primärschlüssel verwendet, können Sie den Primärschlüssel in den Sekundärschlüsselslot kopieren und erst dann den Primärschlüssel erneut generieren. Der neue Primärschlüsselwert kann dann in den Clientanwendungen konfiguriert werden, die ununterbrochenen Zugriff mit dem alten Primärschlüssel im sekundären Slot haben. Sobald alle Clients aktualisiert wurden, können Sie den Sekundärschlüssel erneut generieren, um schließlich den alten Primärschlüssel außer Kraft zu setzen.
Wenn Sie wissen oder vermuten, dass ein Schlüssel gefährdet ist, und Sie die Schlüssel widerrufen müssen, können Sie sowohl den Primärschlüssel als auch den Sekundärschlüssel einer SAS-Autorisierungsrichtlinie neu generieren und so durch neue Schlüssel ersetzen. Durch dieses Verfahren werden alle Token, die mit den alten Schlüsseln signiert wurden, für ungültig erklärt.
Führen Sie die folgenden Schritte aus, um primäre und sekundäre Schlüssel im Azure-Portal neu zu generieren:
Navigieren Sie im Azure-Portal zum Service Bus-Namespace.
Wählen Sie Menü auf der linken Seite Freigegebene Zugriffsrichtlinien aus.
Wählen Sie die Richtlinie aus der Liste aus. Im folgenden Beispiel ist RootManageSharedAccessKey ausgewählt.
Um den Primärschlüssel neu zu generieren, wählen Sie auf der Seite RootManageSharedAccessKey auf der Befehlsleiste die Option Primärschlüssel erneut generieren aus.
Um den sekundären Schlüssel neu zu generieren, wählen Sie auf der Seite SAS-Richtlinie: RootManageSharedAccessKey auf der Befehlsleiste die Auslassungspunkte ... und dann Sekundären Schlüssel erneut generieren aus.
Wenn Sie Azure PowerShell verwenden, verwenden Sie das Cmdlet New-AzServiceBusKey, um primäre und sekundäre Schlüssel für einen Service Bus-Namespace neu zu generieren. Sie können auch Werte für primäre und sekundäre Schlüssel angeben, die generiert werden, indem Sie den Parameter -KeyValue verwenden.
In der Azure-Befehlszeilenschnittstelle verwenden Sie den Befehl az servicebus namespace authorization-rule keys renew, um primäre und sekundäre Schlüssel für einen Service Bus-Namespace neu zu generieren. Sie können auch Werte für primäre und sekundäre Schlüssel angeben, die generiert werden, indem Sie den Parameter --key-value verwenden.
SAS-Authentifizierung bei Service Bus
Das im Folgenden beschriebene Szenario umfasst die Konfiguration von Autorisierungsregeln, das Generieren von SAS-Token und die Clientautorisierung.
Ein Beispiel für eine Service Bus-Anwendung, das die Konfiguration veranschaulicht und SAS-Autorisierung verwendet, finden Sie unter SAS-Authentifizierung bei Service Bus.
Zugreifen auf SAS-Autorisierungsregeln für eine Entität
Verwenden Sie die get/update-Vorgänge für Warteschlangen oder Themen in den Verwaltungsbibliotheken für Service Bus, um auf die entsprechenden SAS-Autorisierungsregeln zuzugreifen bzw. sie zu aktualisieren. Sie können die Regeln auch hinzufügen, wenn Sie die Warteschlangen oder Themen mithilfe dieser Bibliotheken erstellen.
Verwenden der Shared Access Signature-Authentifizierung
Anwendungen, die ein Service Bus SDK in einer der offiziell unterstützten Programmiersprachen wie .NET, Java, JavaScript oder Python verwenden, können die SAS-Autorisierung über die Verbindungszeichenfolgen nutzen, die an den Clientkonstruktor übergeben werden.
Verbindungszeichenfolgen können einen Regelnamen (SharedAccessKeyName) und einen Regelschlüssel (SharedAccessKey) oder ein zuvor ausgestelltes Token (SharedAccessSignature) enthalten. Wenn diese in der Verbindungszeichenfolge vorhanden sind, die an eine Konstruktor- oder eine Factorymethode übergeben wird, die eine Verbindungszeichenfolge akzeptiert, wird der SAS-Tokenanbieter automatisch erstellt und aufgefüllt.
Zum Verwenden der SAS-Autorisierung mit Service Bus-Abonnements können Sie SAS-Schlüssel nutzen, die für einen Service Bus-Namespace oder ein Thema konfiguriert sind.
Verwenden einer Shared Access Signature (auf HTTP-Ebene)
Nachdem Sie nun mit der SAS-Erstellung für beliebige Entitäten in Service Bus vertraut sind, können Sie einen Vorgang vom Typ „HTTP POST“ ausführen:
POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8
Das funktioniert überall. Sie können SAS für eine Warteschlange, ein Thema oder ein Abonnement erstellen.
Wenn Sie einem Absender oder Client ein SAS-Token zuweisen, verfügt er nicht direkt über den Schlüssel, und er kann den Hash nicht umkehren und so den Schlüssel ermitteln. Dadurch haben Sie die Kontrolle darüber, worauf er wie lange Zugriff hat. Vergessen Sie nicht: Wenn Sie den Primärschlüssel in der Richtlinie ändern, werden alle auf deren Grundlage erstellten Shared Access Signatures ungültig.
Verwenden der Shared Access Signature (auf AMQP-Ebene)
Im vorherigen Abschnitt wurde gezeigt, wie Sie das SAS-Token mit einer HTTP POST-Anforderung zum Senden von Daten an den Service Bus verwenden. Wie Sie wissen, können Sie mit dem AMQP (Advanced Message Queue Protocol) auf Service Bus zugreifen, das in zahlreichen Szenarien aus Leistungsgründen bevorzugt verwendet wird. Die Verwendung des SAS-Tokens mit AMQP wird im Dokument AMQP Claim-Based Security Version 1.0 beschrieben, einem seit 2013 gültigen Arbeitsentwurf, der jedoch heute von Azure unterstützt wird.
Bevor Sie beginnen, Daten an Service Bus zu senden, muss der Herausgeber das SAS-Token in einer AMQP-Nachricht an einen ordnungsgemäß definierten AMQP-Knoten mit dem Namen $cbs senden (dieser kann als spezielle Warteschlange betrachtet werden, die vom Dienst zum Abrufen und Überprüfen aller SAS-Token verwendet wird). Der Herausgeber muss das Feld ReplyTo in der AMQP-Nachricht angeben. Hierbei handelt es sich um den Knoten, den der Dienst für die Antwort an den Herausgeber mit dem Ergebnis der Tokenüberprüfung verwendet (einfaches Anforderungs-/Antwortmuster zwischen Herausgeber und Dienst). Dieser spontan erstellte Antwortknoten beschäftigt sich mit der dynamischen Erstellung von Remoteknoten (siehe AMQP 1.0-Spezifikation). Nachdem die Gültigkeit des SAS-Tokens überprüft wurde, kann der Verleger mit dem Senden von Daten an den Dienst beginnen.
Die folgenden Schritte zeigen, wie das SAS-Token mit dem AMQP-Protokoll über die AMQP.NET Lite-Bibliothek gesendet wird. Dies ist hilfreich, wenn Sie das offizielle Service Bus SDK bei der Entwicklung in C# nicht verwenden können (z. B. bei WinRT, .NET Compact Framework, .NET Micro Framework und Mono). Dank dieser nützlichen Bibliothek können Sie nachvollziehen, wie die anspruchsbasierte Sicherheit auf AMQP-Ebene funktioniert. Wie sie auf HTTP-Ebene funktioniert, haben Sie bereits gesehen (HTTP POST-Anforderung und SAS-Token werden im Autorisierungsheader gesendet). Wenn Sie nicht so tiefgreifende Kenntnisse zu AMQP benötigen, können Sie das offizielle Service Bus SDK in einer der unterstützten Programmiersprachen wie .NET, Java, JavaScript, Python oder Go verwenden, das dies für Sie erledigt.
C#
/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
bool result = true;
Session session = new Session(connection);
string cbsClientAddress = "cbs-client-reply-to";
var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");
// construct the put-token message
var request = new Message(sasToken);
request.Properties = new Properties();
request.Properties.MessageId = Guid.NewGuid().ToString();
request.Properties.ReplyTo = cbsClientAddress;
request.ApplicationProperties = new ApplicationProperties();
request.ApplicationProperties["operation"] = "put-token";
request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
cbsSender.Send(request);
// receive the response
var response = cbsReceiver.Receive();
if (response == null || response.Properties == null || response.ApplicationProperties == null)
{
result = false;
}
else
{
int statusCode = (int)response.ApplicationProperties["status-code"];
if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
{
result = false;
}
}
// the sender/receiver might be kept open for refreshing tokens
cbsSender.Close();
cbsReceiver.Close();
session.Close();
return result;
}
Die PutCbsToken()-Methode empfängt die PutCbsToken() (von der AMQP .NET Lite-Bibliothek bereitgestellte AMQP-Verbindungsklasseninstanz), die die TCP-Verbindung mit dem Dienst darstellt, und den sasToken-Parameter, bei dem es sich um das zu sendende SAS-Token handelt.
Hinweis
Beim Erstellen der Verbindung muss der SASL-Authentifizierungsmechanismus auf ANONYMOUS festgelegt werden (nicht auf den Standardmechanismus PLAIN mit Benutzername und Kennwort – dieser wird verwendet, wenn Sie das SAS-Token nicht senden müssen).
Im nächsten Schritt erstellt der Herausgeber zwei AMQP-Links zum Senden des SAS-Tokens und zum Empfangen der Antwort (Ergebnis der Tokenüberprüfung) vom Dienst.
Die AMQP-Nachricht enthält eine Reihe von Eigenschaften und mehr Informationen als eine einfache Nachricht. Das SAS-Token ist der Text der Nachricht (mit dem entsprechenden Konstruktor). Als ReplyTo -Eigenschaft wird der Knotenname zum Empfangen des Überprüfungsergebnisses über den Empfängerlink festgelegt. (Sie können den Namen nach Bedarf ändern, der Link wird vom Dienst dynamisch erstellt.) Anhand der letzten drei Anwendungseigenschaften/benutzerdefinierten Eigenschaften gibt der Dienst an, welche Art von Vorgang ausgeführt werden soll. Wie in der CBS-Entwurfsspezifikation beschrieben, müssen hier der Vorgangsname („put-token“), der Tokentyp (in diesem Fall servicebus.windows.net:sastoken) und der „Name“ der Zielgruppe angegeben werden, für die das Token gilt (die gesamte Entität).
Nachdem der Herausgeber das SAS-Token über den Senderlink gesendet hat, muss der Herausgeber die Antwort über den Empfängerlink lesen. Bei der Antwort handelt es sich um eine einfache AMQP-Nachricht mit einer Anwendungseigenschaft namens status-code , die dieselben Werte wie ein HTTP-Statuscode enthalten kann.
Erforderliche Rechte für Service Bus-Vorgänge
Die folgende Tabelle zeigt die Zugriffsrechte, die für verschiedene Vorgänge für Service Bus-Ressourcen erforderlich sind.
| Vorgang | Erforderlicher Anspruch | Anspruchsbereich |
|---|---|---|
| Namespace | ||
| Konfigurieren einer Autorisierungsregel für einen Namespace | Verwalten | Jede Namespaceadresse |
| Dienstregistrierung | ||
| Aufzählen privater Richtlinien | Verwalten | Jede Namespaceadresse |
| Starten des Lauschvorgangs an einem Namespace | Lauschen | Jede Namespaceadresse |
| Senden von Nachrichten an einen Listener in einem Namespace | Send | Jede Namespaceadresse |
| Warteschlange | ||
| Erstellen einer Warteschlange | Verwalten | Jede Namespaceadresse |
| Löschen einer Warteschlange | Verwalten | Beliebige gültige Warteschlangenadresse |
| Aufzählen von Warteschlangen | Verwalten | /$Resources/Queues |
| Abrufen der Warteschlangenbeschreibung | Verwalten | Beliebige gültige Warteschlangenadresse |
| Konfigurieren einer Autorisierungsregel für eine Warteschlange | Verwalten | Beliebige gültige Warteschlangenadresse |
| Senden in die Warteschlange | Send | Beliebige gültige Warteschlangenadresse |
| Empfangen von Nachrichten aus einer Warteschlange | Lauschen | Beliebige gültige Warteschlangenadresse |
| Verwerfen oder Abschließen von Nachrichten nach dem Empfang der Nachricht im Peek/Lock-Modus | Lauschen | Beliebige gültige Warteschlangenadresse |
| Zurückstellen einer Nachricht für den späteren Abruf | Lauschen | Beliebige gültige Warteschlangenadresse |
| Platzieren einer Nachricht in die Warteschlange für unzustellbare Nachrichten | Lauschen | Beliebige gültige Warteschlangenadresse |
| Abrufen des einer Nachrichtenwarteschlangensitzung zugeordneten Status | Lauschen | Beliebige gültige Warteschlangenadresse |
| Festlegen des einer Nachrichtenwarteschlangensitzung zugeordneten Status | Lauschen | Beliebige gültige Warteschlangenadresse |
| Planen einer Nachricht für spätere Zustellung | Lauschen | Beliebige gültige Warteschlangenadresse |
| Thema | ||
| Erstellen eines Themas | Verwalten | Jede Namespaceadresse |
| Löschen eines Themas | Verwalten | Beliebige gültige Themenadresse |
| Auflisten von Themen | Verwalten | /$Resources/Topics |
| Abrufen der Themenbeschreibung | Verwalten | Beliebige gültige Themenadresse |
| Konfigurieren einer Autorisierungsregel für ein Thema | Verwalten | Beliebige gültige Themenadresse |
| Senden an das Thema | Send | Beliebige gültige Themenadresse |
| Abonnement | ||
| Erstellen eines Abonnements | Verwalten | Jede Namespaceadresse |
| Löschen eines Abonnements | Verwalten | ../myTopic/Subscriptions/mySubscription |
| Aufzählen von Abonnements | Verwalten | ../myTopic/Subscriptions |
| Abrufen der Abonnementbeschreibung | Verwalten | ../myTopic/Subscriptions/mySubscription |
| Verwerfen oder Abschließen von Nachrichten nach dem Empfang der Nachricht im Peek/Lock-Modus | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Zurückstellen einer Nachricht für den späteren Abruf | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Platzieren einer Nachricht in die Warteschlange für unzustellbare Nachrichten | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Abrufen des einer Themensitzung zugeordneten Status | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Festlegen des einer Themensitzung zugeordneten Status | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Regeln | ||
| Erstellen einer Regel | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Löschen einer Regel | Lauschen | ../myTopic/Subscriptions/mySubscription |
| Aufzählen von Regeln | Verwalten oder Lauschen | ../myTopic/Subscriptions/mySubscription/Rules |
Nächste Schritte
Weitere Informationen zu Service Bus Messaging finden Sie in folgenden Themen.