Service Bus-toegangsbeheer met Shared Access Signatures

In dit artikel worden Shared Access Signatures (SAS) besproken, hoe ze werken en hoe u ze op een platformagnostische manier kunt gebruiken met Azure Service Bus.

SAS beveiligt de toegang tot Service Bus op basis van autorisatieregels die zijn geconfigureerd in een naamruimte of een berichtenentiteit (wachtrij of onderwerp). Een autorisatieregel heeft een naam, is gekoppeld aan specifieke rechten en bevat een paar cryptografische sleutels. U gebruikt de naam en sleutel van de regel via de Service Bus SDK of in uw eigen code om een SAS-token te genereren. Een client kan vervolgens het token doorgeven aan Service Bus om autorisatie voor de aangevraagde bewerking te bewijzen.

Notitie

Azure Service Bus ondersteunt het autoriseren van toegang tot een Service Bus-naamruimte en de bijbehorende entiteiten met behulp van Microsoft Entra-id. Het autoriseren van gebruikers of toepassingen met behulp van OAuth 2.0-token dat wordt geretourneerd door Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak ten opzichte van handtekeningen voor gedeelde toegang (SAS). Met Microsoft Entra ID hoeft u de tokens niet op te slaan in uw code en potentiële beveiligingsproblemen te riskeren.

Microsoft raadt u aan om Microsoft Entra ID te gebruiken met uw Azure Service Bus-toepassingen, indien mogelijk. Raadpleeg voor meer informatie de volgende artikelen:

• Een toepassing verifiëren en autoriseren met Microsoft Entra-id voor toegang tot Azure Service Bus-entiteiten.
• Een beheerde identiteit verifiëren met Microsoft Entra-id voor toegang tot Azure Service Bus-resources

U kunt lokale of SAS-sleutelverificatie uitschakelen voor een Service Bus-naamruimte en alleen Microsoft Entra-verificatie toestaan. Zie Lokale verificatie uitschakelen voor stapsgewijze instructies.

Overzicht van SAS

Shared Access Signatures zijn een autorisatiemechanisme op basis van claims met behulp van eenvoudige tokens. Wanneer u SAS gebruikt, worden sleutels nooit doorgegeven aan de kabel. Sleutels worden gebruikt om cryptografische gegevens te ondertekenen die later kunnen worden geverifieerd door de service. SAS kan worden gebruikt als een gebruikersnaam en wachtwoordschema waarbij de client direct een autorisatieregelnaam en een overeenkomende sleutel heeft. SAS kan ook worden gebruikt als een federatief beveiligingsmodel, waarbij de client een tijdslimiet en ondertekend toegangstoken van een beveiligingstokenservice ontvangt zonder ooit de ondertekeningssleutel in bezit te krijgen.

SAS-verificatie in Service Bus wordt geconfigureerd met een benoemd autorisatiebeleid voor gedeelde toegang met gekoppelde toegangsrechten en een paar primaire en secundaire cryptografische sleutels. De sleutels zijn 256-bits waarden in de Basis 64-weergave. U kunt regels configureren op naamruimteniveau, in Service Bus-wachtrijen en onderwerpen.

Notitie

Deze sleutels zijn tekenreeksen zonder opmaak met een Base 64-weergave en mogen niet worden gedecodeerd voordat ze worden gebruikt.

Het Shared Access Signature-token bevat de naam van het gekozen autorisatiebeleid, de URI van de resource waartoe toegang moet worden verkregen, een vervaldatum en een cryptografische HMAC-SHA256-handtekening die via deze velden wordt berekend met behulp van de primaire of secundaire cryptografische sleutel van de gekozen autorisatieregel.

Autorisatiebeleid voor gedeelde toegang

Elke Service Bus-naamruimte en elke Service Bus-entiteit heeft een autorisatiebeleid voor gedeelde toegang dat bestaat uit regels. Het beleid op het niveau van de naamruimte is van toepassing op alle entiteiten in de naamruimte, ongeacht hun afzonderlijke beleidsconfiguratie.

Voor elke autorisatiebeleidsregel bepaalt u drie soorten informatie: naam, bereik en rechten. De naam is alleen dat; een unieke naam binnen dat bereik. Het bereik is eenvoudig genoeg: dit is de URI van de betreffende resource. Voor een Service Bus-naamruimte is het bereik de volledig gekwalificeerde naamruimte, zoals https://<yournamespace>.servicebus.windows.net/.

De rechten die door de beleidsregel worden verleend, kunnen een combinatie zijn van:

• Verzenden - verleent het recht om berichten naar de entiteit te verzenden
• Luisteren - verleent het recht om te ontvangen (wachtrij, abonnementen) en alle gerelateerde berichtafhandeling
• Beheren - verleent het recht om de topologie van de naamruimte te beheren, inclusief het maken en verwijderen van entiteiten

Het recht Beheren omvat de rechten voor verzenden en luisteren.

Een naamruimte- of entiteitsbeleid kan maximaal 12 regels voor gedeelde toegang bevatten, met ruimte voor drie sets regels, die elk betrekking hebben op de basisrechten en de combinatie van Verzenden en Luisteren. Deze limiet is per entiteit, wat betekent dat de naamruimte en elke entiteit maximaal 12 regels voor autorisatie voor gedeelde toegang kan hebben. Deze limiet onderstreept dat het SAS-beleidsarchief niet bedoeld is als een opslag voor gebruikers- of serviceaccounts. Als uw toepassing toegang moet verlenen tot Service Bus op basis van gebruikers- of service-identiteiten, moet deze een beveiligingstokenservice implementeren die SAS-tokens na een verificatie- en toegangscontrole verleent.

Aan een autorisatieregel wordt een primaire sleutel en een secundaire sleutel toegewezen. Deze sleutels zijn cryptografisch sterke sleutels. Verlies ze niet of lek ze niet. Ze zijn altijd beschikbaar in Azure Portal. U kunt een van de gegenereerde sleutels gebruiken en u kunt ze op elk gewenst moment opnieuw genereren. Als u een sleutel opnieuw genereert of wijzigt in het beleid, worden alle eerder uitgegeven tokens op basis van die sleutel onmiddellijk ongeldig. Doorlopende verbindingen die zijn gemaakt op basis van dergelijke tokens, blijven echter werken totdat het token verloopt.

Wanneer u een Service Bus-naamruimte maakt, wordt automatisch een beleidsregel met de naam RootManageSharedAccessKey gemaakt voor de naamruimte. Dit beleid heeft machtigingen voor beheren voor de hele naamruimte. Het is raadzaam deze regel als een beheerdershoofdaccount te behandelen en deze niet te gebruiken in uw toepassing. U kunt meer beleidsregels maken op het tabblad Gedeeld toegangsbeleid voor de naamruimte in de portal, via PowerShell of Azure CLI.

U wordt aangeraden de sleutels die worden gebruikt in het object SharedAccessAuthorizationRule periodiek opnieuw te genereren. De primaire en secundaire sleutelsites bestaan, zodat u sleutels geleidelijk kunt draaien. Als uw toepassing in het algemeen gebruikmaakt van de primaire sleutel, kunt u de primaire sleutel naar de secundaire-sleutelsite kopiëren en vervolgens alleen de primaire sleutel opnieuw genereren. De nieuwe primaire-sleutelwaarde kan vervolgens worden geconfigureerd in de clienttoepassingen, die toegang hebben voortgezet met behulp van de oude primaire sleutel in de secundaire site. Zodra alle clients zijn bijgewerkt, kunt u de secundaire sleutel opnieuw genereren om uiteindelijk de oude primaire sleutel buiten gebruik te stellen.

Als u weet of vermoedt dat een sleutel is aangetast en u de sleutels moet intrekken, kunt u zowel de PrimaryKey als de SecondaryKey van een SharedAccessAuthorizationRule opnieuw genereren, waarbij u deze vervangt door nieuwe sleutels. Met deze procedure worden alle tokens die zijn ondertekend met de oude sleutels ongeldig gemaakt.

Best practices bij gebruik van SAS

Wanneer u handtekeningen voor gedeelde toegang in uw toepassingen gebruikt, moet u rekening houden met twee mogelijke risico's:

• Als een SAS wordt gelekt, kan deze worden gebruikt door iedereen die deze verkrijgt, waardoor uw Service Bus-resources mogelijk worden aangetast.
• Als een SAS die aan een clienttoepassing is verstrekt, verloopt en de toepassing geen nieuwe SAS kan ophalen uit uw service, kan de functionaliteit van de toepassing worden belemmerd.

De volgende aanbevelingen voor het gebruik van handtekeningen voor gedeelde toegang kunnen helpen deze risico's te beperken:

• Laat clients de SAS indien nodig automatisch vernieuwen: clients moeten de SAS vóór de vervaldatum vernieuwen om tijd te verlenen voor nieuwe pogingen als de service die de SAS levert niet beschikbaar is. Als uw SAS is bedoeld om te worden gebruikt voor enkele onmiddellijke bewerkingen met een korte levensduur die naar verwachting binnen de verloopperiode worden voltooid, is het mogelijk onnodig omdat de SAS niet wordt vernieuwd. Als u echter een client hebt die regelmatig aanvragen doet via SAS, wordt de mogelijkheid van verlooptijd in het spel gebracht. De belangrijkste overweging is om de noodzaak om de SAS kort te laten leven (zoals eerder vermeld) in balans te houden met de noodzaak om ervoor te zorgen dat de client vroeg genoeg verlenging aanvraagt (om onderbreking te voorkomen als gevolg van de SAS verloopt vóór een geslaagde verlenging).
• Wees voorzichtig met de SAS-begintijd: Als u de begintijd voor SAS instelt op nu, ziet u mogelijk fouten tijdens de eerste paar minuten vanwege scheeftrekken van de klok (verschillen in de huidige tijd op basis van verschillende computers). Over het algemeen stelt u de begintijd in op ten minste 15 minuten in het verleden. Of stel deze helemaal niet in, waardoor het in alle gevallen onmiddellijk geldig wordt. Hetzelfde geldt doorgaans ook voor de verlooptijd. Houd er rekening mee dat u maximaal 15 minuten van de klok scheeftrekken in beide richtingen op elk verzoek kunt observeren.
• Wees specifiek voor de resource die moet worden geopend: een best practice voor beveiliging is om de gebruiker de minimale vereiste bevoegdheden te bieden. Als een gebruiker alleen leestoegang tot één entiteit nodig heeft, verleent u ze leestoegang tot die ene entiteit en geen lees-/schrijf-/verwijdertoegang tot alle entiteiten. Het helpt ook de schade te verminderen als een SAS wordt aangetast omdat de SAS minder vermogen heeft in handen van een aanvaller.
• Gebruik sas niet altijd: soms wegen de risico's die zijn gekoppeld aan een bepaalde bewerking tegen uw Service Bus op tegen de voordelen van SAS. Voor dergelijke bewerkingen maakt u een service in de middelste laag die naar uw Service Bus schrijft na validatie, verificatie en controle van bedrijfsregels.
• Altijd HTTPs gebruiken: gebruik altijd Https om een SAS te maken of te distribueren. Als een SAS wordt doorgegeven via HTTP en onderschept, kan een aanvaller die een man-in-the-middle-attach uitvoert de SAS lezen en deze vervolgens gebruiken, net zoals de beoogde gebruiker zou kunnen hebben, mogelijk gevoelige gegevens in gevaar brengen of gegevensbeschadiging door de kwaadwillende gebruiker toestaan.

Configuratie voor Shared Access Signature-verificatie

U kunt het beleid voor gedeelde toegangsautorisatie configureren in Service Bus-naamruimten, wachtrijen of onderwerpen. Configureren voor een Service Bus-abonnement wordt momenteel niet ondersteund, maar u kunt regels gebruiken die zijn geconfigureerd voor een naamruimte of onderwerp om de toegang tot abonnementen te beveiligen.

In deze afbeelding zijn de autorisatieregels manageRuleNS, sendRuleNS en listenRuleNS van toepassing op zowel wachtrij Q1 als onderwerp T1, terwijl listenRuleQ en sendRuleQ alleen van toepassing zijn op wachtrij Q1 en sendRuleT alleen van toepassing op onderwerp T1.

Een Shared Access Signature-token genereren

Elke client die toegang heeft tot de naam van een autorisatieregelnaam en een van de ondertekeningssleutels kan een SAS-token genereren. Het token wordt gegenereerd door een tekenreeks te maken in de volgende indeling:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

• se - Vervaldatum van token direct. Geheel getal dat seconden weergeeft sinds het tijdvak 00:00:00 UTC op 1 januari 1970 (UNIX-epoch) wanneer het token verloopt.

• skn - Naam van de autorisatieregel.

• sr - URL-gecodeerde URI van de resource die wordt geopend.

• sig - URL-gecodeerde HMACSHA256 handtekening. De hash-berekening lijkt op de volgende pseudocode en retourneert base64 van onbewerkte binaire uitvoer.

  urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
  

Belangrijk

Zie SAS-token genereren voor voorbeelden van het genereren van een SAS-token met verschillende programmeertalen.

Het token bevat de niet-hashwaarden, zodat de ontvanger de hash opnieuw kan compileren met dezelfde parameters, waarbij wordt gecontroleerd of de verlener een geldige ondertekeningssleutel heeft.

De resource-URI is de volledige URI van de Service Bus-resource waartoe toegang wordt geclaimd. Bijvoorbeeld, http://<namespace>.servicebus.windows.net/<entityPath> of sb://<namespace>.servicebus.windows.net/<entityPath>; dat wil http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3wel.

De URI moet procent-gecodeerd zijn.

De autorisatieregel voor gedeelde toegang die wordt gebruikt voor ondertekening, moet worden geconfigureerd voor de entiteit die is opgegeven door deze URI of door een van de hiërarchische bovenliggende items. Bijvoorbeeld, http://contoso.servicebus.windows.net/contosoTopics/T1 of http://contoso.servicebus.windows.net in het vorige voorbeeld.

Een SAS-token is geldig voor alle resources met het voorvoegsel dat <resourceURI> wordt gebruikt in de signature-string.

Sleutels opnieuw genereren

U wordt aangeraden de sleutels die worden gebruikt in het autorisatiebeleid voor gedeelde toegang periodiek opnieuw te genereren. De primaire en secundaire sleutelsites bestaan, zodat u sleutels geleidelijk kunt draaien. Als uw toepassing in het algemeen gebruikmaakt van de primaire sleutel, kunt u de primaire sleutel naar de secundaire-sleutelsite kopiëren en vervolgens alleen de primaire sleutel opnieuw genereren. De nieuwe primaire-sleutelwaarde kan vervolgens worden geconfigureerd in de clienttoepassingen, die toegang hebben voortgezet met behulp van de oude primaire sleutel in de secundaire site. Zodra alle clients zijn bijgewerkt, kunt u de secundaire sleutel opnieuw genereren om uiteindelijk de oude primaire sleutel buiten gebruik te stellen.

Als u weet of vermoedt dat een sleutel is aangetast en u de sleutels moet intrekken, kunt u zowel de primaire sleutel als de secundaire sleutel van een autorisatiebeleid voor gedeelde toegang opnieuw genereren, waarbij u deze vervangt door nieuwe sleutels. Met deze procedure worden alle tokens die zijn ondertekend met de oude sleutels ongeldig gemaakt.

Voer de volgende stappen uit om primaire en secundaire sleutels opnieuw te genereren in Azure Portal:

1. Navigeer naar de Service Bus-naamruimte in Azure Portal.

2. Selecteer Beleid voor gedeelde toegang in het linkermenu.

3. Selecteer het beleid in de lijst. In het volgende voorbeeld is RootManageSharedAccessKey geselecteerd.

4. Als u de primaire sleutel opnieuw wilt genereren, selecteert u op de pagina RootManageSharedAccessKey de optie Primaire sleutel opnieuw genereren op de opdrachtbalk.

   

5. Als u de secundaire sleutel opnieuw wilt genereren, selecteert u op de pagina Sas-beleid: RootManageSharedAccessKey... op de opdrachtbalk en selecteert u Secundaire sleutel opnieuw genereren.

   

Als u Azure PowerShell gebruikt, gebruikt u de New-AzServiceBusKey cmdlet om primaire en secundaire sleutels opnieuw te genereren voor een Service Bus-naamruimte. U kunt ook waarden opgeven voor primaire en secundaire sleutels die worden gegenereerd met behulp van de -KeyValue parameter.

Als u Azure CLI gebruikt, gebruikt u de az servicebus namespace authorization-rule keys renew opdracht om primaire en secundaire sleutels opnieuw te genereren voor een Service Bus-naamruimte. U kunt ook waarden opgeven voor primaire en secundaire sleutels die worden gegenereerd met behulp van de --key-value parameter.

Shared Access Signature-verificatie met Service Bus

Het scenario dat als volgt wordt beschreven, omvat de configuratie van autorisatieregels, het genereren van SAS-tokens en clientautorisatie.

Zie Shared Access Signature-verificatie met Service Bus voor een voorbeeld van een Service Bus-toepassing die de configuratie illustreert en SAS-autorisatie gebruikt.

Toegang tot autorisatieregels voor gedeelde toegang voor een entiteit

Gebruik de get/update-bewerking voor wachtrijen of onderwerpen in de beheerbibliotheken voor Service Bus om de bijbehorende autorisatieregels voor gedeelde toegang te openen/bij te werken. U kunt ook de regels toevoegen bij het maken van de wachtrijen of onderwerpen met behulp van deze bibliotheken.

Autorisatie via Shared Access Signature gebruiken

Toepassingen die gebruikmaken van een van de Service Bus SDK's in een van de officieel ondersteunde talen, zoals .NET, Java, JavaScript en Python, kunnen gebruikmaken van SAS-autorisatie via de verbindingsreeks die worden doorgegeven aan de clientconstructor.

Verbinding maken iontekenreeksen kunnen een regelnaam (SharedAccessKeyName) en regelsleutel (SharedAccessKey) of een eerder uitgegeven token (SharedAccessSignature) bevatten. Wanneer deze aanwezig zijn in de verbindingsreeks doorgegeven aan een constructor of factory-methode die een verbindingsreeks accepteert, wordt de SAS-tokenprovider automatisch gemaakt en ingevuld.

Als u SAS-autorisatie wilt gebruiken met Service Bus-abonnementen, kunt u SAS-sleutels gebruiken die zijn geconfigureerd in een Service Bus-naamruimte of in een onderwerp.

De Shared Access Signature gebruiken (op HTTP-niveau)

Nu u weet hoe u Shared Access Signatures maakt voor entiteiten in Service Bus, kunt u een HTTP POST uitvoeren:

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

Onthoud, dit werkt voor alles. U kunt SAS maken voor een wachtrij, onderwerp of abonnement.

Als u een afzender of client een SAS-token geeft, hebben ze de sleutel niet rechtstreeks en kunnen ze de hash niet omkeren om het te verkrijgen. Als zodanig hebt u controle over waartoe ze toegang hebben en hoe lang. Een belangrijk punt om te onthouden is dat als u de primaire sleutel in het beleid wijzigt, alle Shared Access Signatures die hierop zijn gemaakt, ongeldig zijn.

De Shared Access Signature gebruiken (op AMQP-niveau)

In de vorige sectie hebt u gezien hoe u het SAS-token gebruikt met een HTTP POST-aanvraag voor het verzenden van gegevens naar de Service Bus. Zoals u weet, hebt u toegang tot Service Bus met behulp van het Advanced Message Queuing Protocol (AMQP) dat in veel scenario's het voorkeursprotocol is dat moet worden gebruikt om prestatieredenen. Het SAS-tokengebruik met AMQP wordt beschreven in het document AMQP-beveiligingsversie 1.0 dat sinds 2013 in het werkende concept is, maar dat momenteel wordt ondersteund door Azure.

Voordat u begint met het verzenden van gegevens naar Service Bus, moet de uitgever het SAS-token in een AMQP-bericht verzenden naar een goed gedefinieerd AMQP-knooppunt met de naam $cbs (u kunt het zien als een 'speciale' wachtrij die door de service wordt gebruikt om alle SAS-tokens te verkrijgen en te valideren). De uitgever moet het veld ReplyTo in het AMQP-bericht opgeven. Dit is het knooppunt waarin de service de uitgever beantwoordt met het resultaat van de tokenvalidatie (een eenvoudig aanvraag-/antwoordpatroon tussen uitgever en service). Dit antwoordknooppunt wordt 'on the fly' gemaakt, met betrekking tot 'dynamisch maken van extern knooppunt' zoals beschreven in de AMQP 1.0-specificatie. Nadat u hebt gecontroleerd of het SAS-token geldig is, kan de uitgever doorgaan en beginnen met het verzenden van gegevens naar de service.

De volgende stappen laten zien hoe u het SAS-token met het AMQP-protocol verzendt met behulp van de AMQP.NET Lite-bibliotheek . Het is handig als u de officiële Service Bus SDK niet kunt gebruiken (bijvoorbeeld op WinRT, .NET Compact Framework, .NET Micro Framework en Mono) die in C# worden ontwikkeld. Deze bibliotheek is handig om te begrijpen hoe beveiliging op basis van claims werkt op AMQP-niveau, zoals u hebt gezien hoe deze werkt op HTTP-niveau (met een HTTP POST-aanvraag en het SAS-token dat wordt verzonden in de header Autorisatie). Als u dergelijke uitgebreide kennis over AMQP niet nodig hebt, kunt u de officiële Service Bus SDK gebruiken in een van de ondersteunde talen, zoals .NET, Java, JavaScript, Python en Go, die dit voor u doen.

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;
}

De PutCbsToken() methode ontvangt de verbinding (AMQP-verbindingsklasse-exemplaar zoals opgegeven door de AMQP .NET Lite-bibliotheek) die de TCP-verbinding met de service vertegenwoordigt en de sasToken-parameter die het SAS-token is dat moet worden verzonden.

Notitie

Het is belangrijk dat de verbinding wordt gemaakt met het SASL-verificatiemechanisme dat is ingesteld op ANONIEM (en niet de standaard PLAIN met gebruikersnaam en wachtwoord dat wordt gebruikt wanneer u het SAS-token niet hoeft te verzenden).

Vervolgens maakt de uitgever twee AMQP-koppelingen voor het verzenden van het SAS-token en het ontvangen van het antwoord (het validatieresultaat van het token) van de service.

Het AMQP-bericht bevat een set eigenschappen en meer informatie dan een eenvoudig bericht. Het SAS-token is de hoofdtekst van het bericht (met behulp van de constructor). De eigenschap ReplyTo is ingesteld op de naam van het knooppunt voor het ontvangen van het validatieresultaat op de ontvangerkoppeling (u kunt de naam desgewenst wijzigen en deze wordt dynamisch gemaakt door de service). De laatste drie toepassings-/aangepaste eigenschappen worden door de service gebruikt om aan te geven welk type bewerking moet worden uitgevoerd. Zoals beschreven in de conceptspecificatie van het CBS, moeten ze de naam van de bewerking zijn (put-token), het type token (in dit geval a servicebus.windows.net:sastoken) en de 'naam' van de doelgroep waarop het token van toepassing is (de gehele entiteit).

Nadat publisher het SAS-token op de afzenderkoppeling heeft verzonden, moet de uitgever het antwoord lezen op de ontvangerkoppeling. Het antwoord is een eenvoudig AMQP-bericht met een toepassingseigenschap met de naam statuscode die dezelfde waarden kan bevatten als een HTTP-statuscode.

Vereiste rechten voor Service Bus-bewerkingen

In de volgende tabel ziet u de toegangsrechten die vereist zijn voor verschillende bewerkingen op Service Bus-resources.

Operation	Claim vereist	Claimbereik
Naamruimte
Autorisatieregel configureren voor een naamruimte	Beheren	Elk naamruimteadres
Serviceregister
Privébeleid opsommen	Beheren	Elk naamruimteadres
Beginnen met luisteren op een naamruimte	Luisteren	Elk naamruimteadres
Berichten verzenden naar een listener in een naamruimte	Verzenden	Elk naamruimteadres
Wachtrij
Een wachtrij maken	Beheren	Elk naamruimteadres
Een wachtrij verwijderen	Beheren	Een geldig wachtrijadres
Wachtrijen opsommen	Beheren	/$Resources/Wachtrijen
De beschrijving van de wachtrij ophalen	Beheren	Een geldig wachtrijadres
Autorisatieregel configureren voor een wachtrij	Beheren	Een geldig wachtrijadres
Verzenden naar de wachtrij	Verzenden	Een geldig wachtrijadres
Berichten van een wachtrij ontvangen	Luisteren	Een geldig wachtrijadres
Berichten verlaten of voltooien na ontvangst van het bericht in de modus Peek-Lock	Luisteren	Een geldig wachtrijadres
Een bericht uitstellen voor later ophalen	Luisteren	Een geldig wachtrijadres
Een bericht in een deadletter	Luisteren	Een geldig wachtrijadres
De status ophalen die is gekoppeld aan een berichtenwachtrijsessie	Luisteren	Een geldig wachtrijadres
De status instellen die is gekoppeld aan een berichtenwachtrijsessie	Luisteren	Een geldig wachtrijadres
Een bericht plannen voor latere bezorging	Luisteren	Een geldig wachtrijadres
Onderwerp
Een onderwerp maken	Beheren	Elk naamruimteadres
Een onderwerp verwijderen	Beheren	Elk geldig onderwerpadres
Onderwerpen opsommen	Beheren	/$Resources/Onderwerpen
De beschrijving van het onderwerp ophalen	Beheren	Elk geldig onderwerpadres
Autorisatieregel voor een onderwerp configureren	Beheren	Elk geldig onderwerpadres
Verzenden naar het onderwerp	Verzenden	Elk geldig onderwerpadres
Abonnement
Een abonnement maken	Beheren	Elk naamruimteadres
Abonnement verwijderen	Beheren	.. /myTopic/Subscriptions/mySubscription
Abonnementen opsommen	Beheren	.. /myTopic/Subscriptions
Beschrijving van abonnement ophalen	Beheren	.. /myTopic/Subscriptions/mySubscription
Berichten verlaten of voltooien na ontvangst van het bericht in de modus Peek-Lock	Luisteren	.. /myTopic/Subscriptions/mySubscription
Een bericht uitstellen voor later ophalen	Luisteren	.. /myTopic/Subscriptions/mySubscription
Een bericht in een deadletter	Luisteren	.. /myTopic/Subscriptions/mySubscription
De status ophalen die is gekoppeld aan een onderwerpsessie	Luisteren	.. /myTopic/Subscriptions/mySubscription
De status instellen die is gekoppeld aan een onderwerpsessie	Luisteren	.. /myTopic/Subscriptions/mySubscription
Regels
Een regel maken	Luisteren	.. /myTopic/Subscriptions/mySubscription
Een regel verwijderen	Luisteren	.. /myTopic/Subscriptions/mySubscription
Regels opsommen	Beheren of luisteren	.. /myTopic/Subscriptions/mySubscription/Rules

Volgende stappen

Zie de volgende onderwerpen voor meer informatie over de Service Bus-berichtenservice

• Service Bus-wachtrijen, -onderwerpen en -abonnementen
• Service Bus-wachtrijen gebruiken
• Service Bus-onderwerpen en -abonnementen gebruiken