Kontrola dostępu do usługi Service Bus z sygnaturami dostępu współdzielonego

Artykuł
11/28/2023

W tym artykule omówiono sygnatury dostępu współdzielonego (SAS) oraz sposób ich działania oraz sposób ich używania w sposób niezależny od platformy w usłudze Azure Service Bus.

Sygnatura dostępu współdzielonego chroni dostęp do usługi Service Bus na podstawie reguł autoryzacji skonfigurowanych w przestrzeni nazw lub jednostki obsługi komunikatów (kolejka lub temat). Reguła autoryzacji ma nazwę, jest skojarzona z określonymi prawami i zawiera parę kluczy kryptograficznych. Nazwa i klucz reguły są używane za pośrednictwem zestawu SDK usługi Service Bus lub we własnym kodzie w celu wygenerowania tokenu SYGNATURy dostępu współdzielonego. Klient może następnie przekazać token do usługi Service Bus, aby udowodnić autoryzację dla żądanej operacji.

Uwaga

Usługa Azure Service Bus obsługuje autoryzowanie dostępu do przestrzeni nazw usługi Service Bus i jej jednostek przy użyciu identyfikatora Entra firmy Microsoft. Autoryzowanie użytkowników lub aplikacji przy użyciu tokenu OAuth 2.0 zwróconego przez identyfikator Entra firmy Microsoft zapewnia lepsze zabezpieczenia i łatwość użycia za pośrednictwem sygnatur dostępu współdzielonego (SAS). Klucze sygnatury dostępu współdzielonego nie mają szczegółowej kontroli dostępu, są trudne do zarządzania/rotacji i nie mają możliwości inspekcji, aby skojarzyć jego użycie z określonym użytkownikiem lub jednostką usługi. Z tych powodów zalecamy używanie identyfikatora Entra firmy Microsoft.

Firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z aplikacjami usługi Azure Service Bus, jeśli to możliwe. Aby uzyskać więcej informacji, zobacz następujące artykuły:

Możesz wyłączyć uwierzytelnianie za pomocą klucza lokalnego lub sygnatury dostępu współdzielonego dla przestrzeni nazw usługi Service Bus i zezwolić tylko na uwierzytelnianie firmy Microsoft Entra. Aby uzyskać instrukcje krok po kroku, zobacz Wyłączanie uwierzytelniania lokalnego.

Omówienie sygnatury dostępu współdzielonego

Sygnatury dostępu współdzielonego to mechanizm autoryzacji oparty na oświadczeniach korzystający z prostych tokenów. W przypadku korzystania z sygnatury dostępu współdzielonego klucze nigdy nie są przekazywane do przewodu. Klucze są używane do kryptograficznego podpisywania informacji, które można później zweryfikować przez usługę. Sygnatura dostępu współdzielonego może być podobna do schematu nazwy użytkownika i hasła, w którym klient jest w bezpośrednim posiadaniu nazwy reguły autoryzacji i pasującego klucza. Sygnatura dostępu współdzielonego może być również używana podobnie do modelu zabezpieczeń federacyjnych, w którym klient otrzymuje ograniczony czas i podpisany token dostępu z usługi tokenu zabezpieczającego, nie wchodząc w posiadanie klucza podpisywania.

Uwierzytelnianie sygnatury dostępu współdzielonego w usłudze Service Bus jest skonfigurowane z nazwanymi zasadami autoryzacji dostępu współdzielonego z skojarzonymi prawami dostępu oraz parą podstawowych i pomocniczych kluczy kryptograficznych. Klucze są wartościami 256-bitowymi w reprezentacji podstawowej 64. Reguły można skonfigurować na poziomie przestrzeni nazw w kolejkach i tematach usługi Service Bus.

Uwaga

Te klucze są ciągami zwykłego tekstu przy użyciu reprezentacji base 64 i nie mogą być dekodowane przed ich użyciem.

Token sygnatury dostępu współdzielonego zawiera nazwę wybranych zasad autoryzacji, identyfikator URI zasobu, do którego uzyskuje się dostęp, natychmiastowy wygaśnięcie i podpis kryptograficzny HMAC-SHA256 obliczony w tych polach przy użyciu podstawowego lub pomocniczego klucza kryptograficznego wybranej reguły autoryzacji.

Zasady autoryzacji dostępu współdzielonego

Każda przestrzeń nazw usługi Service Bus i każda jednostka usługi Service Bus ma zasady autoryzacji dostępu współdzielonego złożone z reguł. Zasady na poziomie przestrzeni nazw dotyczą wszystkich jednostek w przestrzeni nazw, niezależnie od ich konfiguracji poszczególnych zasad.

Dla każdej reguły zasad autoryzacji decydujesz się na trzy informacje: nazwa, zakres i prawa. Nazwa jest taka; unikatowa nazwa w tym zakresie. Zakres jest wystarczająco łatwy: jest to identyfikator URI danego zasobu. W przypadku przestrzeni nazw usługi Service Bus zakres jest w pełni kwalifikowaną przestrzenią nazw, taką jak https://<yournamespace>.servicebus.windows.net/.

Prawa przyznane przez regułę zasad mogą być kombinacją:

Send — przyznaje prawo do wysyłania komunikatów do jednostki
Nasłuchiwanie — przyznaje prawo do odbierania (kolejki, subskrypcji) i całej powiązanej obsługi komunikatów
Zarządzanie — przyznaje prawo do zarządzania topologią przestrzeni nazw, w tym tworzenia i usuwania jednostek

Uprawnienie Zarządzanie obejmuje prawa Do wysyłania i nasłuchiwania.

Przestrzeń nazw lub zasady jednostki mogą zawierać maksymalnie 12 reguł autoryzacji dostępu współdzielonego, zapewniając miejsce dla trzech zestawów reguł, z których każda obejmuje podstawowe prawa oraz kombinację funkcji Wyślij i Nasłuchiwanie. Ten limit dotyczy jednostki, co oznacza, że przestrzeń nazw i każda jednostka może mieć maksymalnie 12 reguł autoryzacji dostępu współdzielonego. Ten limit podkreśla, że magazyn zasad sygnatury dostępu współdzielonego nie jest przeznaczony dla użytkownika ani magazynu kont usług. Jeśli aplikacja musi udzielić dostępu do usługi Service Bus na podstawie tożsamości użytkowników lub usług, powinna zaimplementować usługę tokenu zabezpieczającego, która wystawia tokeny SAS po uwierzytelnieniu i sprawdzeniu dostępu.

Reguła autoryzacji jest przypisywana klucz podstawowy i klucz pomocniczy. Te klucze są kryptograficznie silnymi kluczami. Nie trać ich ani nie wyciekaj — będą one zawsze dostępne w witrynie Azure Portal. Możesz użyć jednego z wygenerowanych kluczy i w dowolnym momencie je ponownie wygenerować. Jeśli ponownie wygenerowasz lub zmienisz klucz w zasadach, wszystkie wcześniej wystawione tokeny oparte na tym kluczu staną się natychmiast nieprawidłowe. Jednak trwające połączenia utworzone na podstawie takich tokenów będą nadal działać do momentu wygaśnięcia tokenu.

Podczas tworzenia przestrzeni nazw usługi Service Bus dla przestrzeni nazw zostanie automatycznie utworzona reguła zasad o nazwie RootManageSharedAccessKey . Te zasady mają uprawnienia Do zarządzania dla całej przestrzeni nazw. Zaleca się traktowanie tej reguły jako konta głównego administratora i nie jest używane w aplikacji. Więcej reguł zasad można utworzyć na karcie Zasady dostępu współdzielonego dla przestrzeni nazw w portalu za pomocą programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

Zalecamy okresowe ponowne generowanie kluczy używanych w obiekcie SharedAccessAuthorizationRule . Istnieją gniazda klucza podstawowego i pomocniczego, dzięki czemu można stopniowo obracać klucze. Jeśli aplikacja zazwyczaj używa klucza podstawowego, możesz skopiować klucz podstawowy do gniazda klucza pomocniczego, a następnie ponownie wygenerować klucz podstawowy. Nową wartość klucza podstawowego można następnie skonfigurować w aplikacjach klienckich, które mają stały dostęp przy użyciu starego klucza podstawowego w miejscu pomocniczym. Po zaktualizowaniu wszystkich klientów można ponownie wygenerować klucz pomocniczy, aby w końcu wycofać stary klucz podstawowy.

Jeśli wiesz lub podejrzewasz, że klucz został naruszony i musisz odwołać klucze, możesz ponownie wygenerować zarówno klucz podstawowy , jak i secondaryKey obiektu SharedAccessAuthorizationRule, zastępując je nowymi kluczami. Ta procedura unieważnia wszystkie tokeny podpisane przy użyciu starych kluczy.

Najlepsze rozwiązania dotyczące korzystania z sygnatury dostępu współdzielonego

W przypadku korzystania z sygnatur dostępu współdzielonego w aplikacjach należy pamiętać o dwóch potencjalnych zagrożeniach:

W przypadku wycieku sygnatury dostępu współdzielonego można go użyć przez każdego, kto go uzyska, co może potencjalnie naruszyć bezpieczeństwo zasobów usługi Service Bus.
Jeśli sygnatura dostępu współdzielonego dostarczona do aplikacji klienckiej wygaśnie, a aplikacja nie może pobrać nowej sygnatury dostępu współdzielonego z usługi, funkcjonalność aplikacji może być utrudniona.

Poniższe zalecenia dotyczące używania sygnatur dostępu współdzielonego mogą pomóc w ograniczeniu tych zagrożeń:

Klienci mają automatycznie odnawiać sygnaturę dostępu współdzielonego w razie potrzeby: klienci powinni odnowić sygnaturę dostępu współdzielonego na długo przed wygaśnięciem, aby umożliwić ponawianie prób, jeśli usługa dostarczająca sygnaturę dostępu współdzielonego jest niedostępna. Jeśli sygnatura dostępu współdzielonego ma być używana w przypadku kilku natychmiastowych, krótkotrwałych operacji, które mają zostać ukończone w okresie wygaśnięcia, może to być niepotrzebne, ponieważ nie oczekuje się odnowienia sygnatury dostępu współdzielonego. Jeśli jednak masz klienta, który rutynowo wysyła żądania za pośrednictwem sygnatury dostępu współdzielonego, możliwość wygaśnięcia wchodzi w grę. Kluczową kwestią jest zrównoważenie potrzeby krótkotrwałego (jak wspomniano wcześniej) sygnatury dostępu współdzielonego z koniecznością zapewnienia, że klient żąda odnowienia wystarczająco wcześnie (aby uniknąć zakłóceń z powodu wygaśnięcia sygnatury dostępu współdzielonego przed pomyślnym odnowieniem).
Zachowaj ostrożność w czasie rozpoczęcia sygnatury dostępu współdzielonego: jeśli ustawisz czas rozpoczęcia dla sygnatury dostępu współdzielonego na teraz, z powodu niesymetryczności zegara (różnice w bieżącym czasie zgodnie z różnymi maszynami), błędy mogą występować sporadycznie przez pierwsze kilka minut. Ogólnie rzecz biorąc, ustaw czas rozpoczęcia na co najmniej 15 minut w przeszłości. Lub nie ustawiaj go w ogóle, co sprawi, że będzie ono prawidłowe natychmiast we wszystkich przypadkach. To samo zwykle dotyczy również czasu wygaśnięcia. Należy pamiętać, że możesz obserwować do 15 minut niesymetryczności zegara w dowolnym kierunku w dowolnym żądaniu.
Aby uzyskać dostęp do zasobu, należy określić, że najlepszym rozwiązaniem w zakresie zabezpieczeń jest zapewnienie użytkownikowi minimalnych wymaganych uprawnień. Jeśli użytkownik potrzebuje tylko dostępu do odczytu do pojedynczej jednostki, przyznaj im dostęp do odczytu do tej pojedynczej jednostki, a nie do odczytu/zapisu/usuwania do wszystkich jednostek. Pomaga również zmniejszyć szkody w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego, ponieważ sygnatura dostępu współdzielonego ma mniejszą moc w rękach osoby atakującej.
Nie zawsze używaj sygnatury dostępu współdzielonego: czasami ryzyko związane z określoną operacją w usłudze Service Bus przewyższa korzyści wynikające z sygnatury dostępu współdzielonego. W przypadku takich operacji utwórz usługę warstwy środkowej, która zapisuje w usłudze Service Bus po weryfikacji, uwierzytelnieniu i inspekcji reguł biznesowych.
Zawsze używaj protokołu HTTPs: zawsze używaj protokołu Https do tworzenia lub dystrybuowania sygnatury dostępu współdzielonego. Jeśli sygnatura dostępu współdzielonego jest przekazywana przez protokół HTTP i przechwycona, osoba atakująca wykonująca dołączanie typu man-in-the-middle może odczytać sygnaturę dostępu współdzielonego, a następnie użyć go tak samo jak zamierzony użytkownik, potencjalnie narażając poufne dane lub zezwalając na uszkodzenie danych przez złośliwego użytkownika.

Konfiguracja uwierzytelniania sygnatury dostępu współdzielonego

Zasady autoryzacji dostępu współdzielonego można skonfigurować w przestrzeniach nazw, kolejkach lub tematach usługi Service Bus. Konfigurowanie jej w ramach subskrypcji usługi Service Bus nie jest obecnie obsługiwane, ale można użyć reguł skonfigurowanych w przestrzeni nazw lub temacie w celu zabezpieczenia dostępu do subskrypcji.

Diagram przedstawiający przykładową przestrzeń nazw z kilkoma regułami autoryzacji.

Na tym rysunku reguły autoryzacji manageRuleNS, sendRuleNS i listenRuleNS dotyczą zarówno kolejki Q1, jak i T1 tematu, podczas gdy listenRuleQ i sendRuleQ mają zastosowanie tylko do kolejki Q1 i sendRuleT dotyczy tylko tematU T1.

Generowanie tokenu sygnatury dostępu współdzielonego

Każdy klient z dostępem do nazwy reguły autoryzacji i jeden z jego kluczy podpisywania może wygenerować token SAS. Token jest generowany przez utworzenie ciągu w następującym formacie:

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

se - Natychmiastowe wygaśnięcie tokenu. Liczba całkowita odzwierciedla sekundy od epoki 1 stycznia 1970 r. (epoka 00:00:00 UTC systemu UNIX) po wygaśnięciu tokenu.
skn - Nazwa reguły autoryzacji.
sr - Zakodowany w adresie URL identyfikator URI zasobu, do których uzyskuje się dostęp.
sig - Podpis HMACSHA256 zakodowany pod adresem URL. Obliczenie skrótu wygląda podobnie do poniższego pseudo kodu i zwraca wartość base64 nieprzetworzonych danych binarnych.
```
urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
```

Ważne

Przykłady generowania tokenu SAS przy użyciu różnych języków programowania można znaleźć w temacie Generowanie tokenu SAS.

Token zawiera wartości inne niż skróty, aby odbiorca mógł ponownie skompilować skrót z tymi samymi parametrami, sprawdzając, czy wystawca jest w posiadaniu prawidłowego klucza podpisywania.

Identyfikator URI zasobu to pełny identyfikator URI zasobu usługi Service Bus, do którego jest uzyskiwany dostęp. Na przykład lub sb://<namespace>.servicebus.windows.net/<entityPath>; http://<namespace>.servicebus.windows.net/<entityPath> czyli http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

Identyfikator URI musi być zakodowany procentowo.

Reguła autoryzacji dostępu współdzielonego używana do podpisywania musi być skonfigurowana w jednostce określonej przez ten identyfikator URI lub przez jeden z jej hierarchicznych elementów nadrzędnych. Na przykład http://contoso.servicebus.windows.net/contosoTopics/T1 lub http://contoso.servicebus.windows.net w poprzednim przykładzie.

Token SAS jest prawidłowy dla wszystkich zasobów poprzedzonych prefiksem używanym <resourceURI> w pliku signature-string.

Ponowne generowanie kluczy

Zalecamy okresowe ponowne generowanie kluczy używanych w zasadach autoryzacji dostępu współdzielonego. Istnieją gniazda klucza podstawowego i pomocniczego, dzięki czemu można stopniowo obracać klucze. Jeśli aplikacja zazwyczaj używa klucza podstawowego, możesz skopiować klucz podstawowy do gniazda klucza pomocniczego, a następnie ponownie wygenerować klucz podstawowy. Nową wartość klucza podstawowego można następnie skonfigurować w aplikacjach klienckich, które mają stały dostęp przy użyciu starego klucza podstawowego w miejscu pomocniczym. Po zaktualizowaniu wszystkich klientów można ponownie wygenerować klucz pomocniczy, aby w końcu wycofać stary klucz podstawowy.

Jeśli wiesz lub podejrzewasz, że klucz został naruszony i musisz odwołać klucze, możesz ponownie wygenerować zarówno klucz podstawowy, jak i klucz pomocniczy zasad autoryzacji dostępu współdzielonego, zastępując je nowymi kluczami. Ta procedura unieważnia wszystkie tokeny podpisane przy użyciu starych kluczy.

Aby ponownie wygenerować klucze podstawowe i pomocnicze w witrynie Azure Portal, wykonaj następujące kroki:

Przejdź do przestrzeni nazw usługi Service Bus w witrynie Azure Portal.
Wybierz pozycję Zasady dostępu współdzielonego w menu po lewej stronie.
Wybierz zasady z listy. W poniższym przykładzie jest zaznaczona opcja RootManageSharedAccessKey .
Aby ponownie wygenerować klucz podstawowy, na stronie Zasady sygnatury dostępu współdzielonego : RootManageSharedAccessKey wybierz pozycję Wygeneruj ponownie klucz podstawowy na pasku poleceń.
Aby ponownie wygenerować klucz pomocniczy, na stronie Zasady sygnatury dostępu współdzielonego: RootManageSharedAccessKey wybierz pozycję ... na pasku poleceń, a następnie wybierz pozycję Wygeneruj ponownie klucz pomocniczy.

Jeśli używasz programu Azure PowerShell, użyj New-AzServiceBusKey polecenia cmdlet , aby ponownie wygenerować klucze podstawowe i pomocnicze dla przestrzeni nazw usługi Service Bus. Można również określić wartości dla generowanych kluczy podstawowych i pomocniczych przy użyciu parametru -KeyValue .

Jeśli używasz interfejsu az servicebus namespace authorization-rule keys renew wiersza polecenia platformy Azure, użyj polecenia , aby ponownie wygenerować klucze podstawowe i pomocnicze dla przestrzeni nazw usługi Service Bus. Można również określić wartości dla generowanych kluczy podstawowych i pomocniczych przy użyciu parametru --key-value .

Uwierzytelnianie sygnatury dostępu współdzielonego za pomocą usługi Service Bus

Scenariusz opisany w następujący sposób obejmuje konfigurację reguł autoryzacji, generowanie tokenów SAS i autoryzację klienta.

Aby zapoznać się z przykładem aplikacji usługi Service Bus, która ilustruje konfigurację i używa autoryzacji sygnatury dostępu współdzielonego, zobacz Uwierzytelnianie sygnatury dostępu współdzielonego za pomocą usługi Service Bus.

Uzyskiwanie dostępu do reguł autoryzacji dostępu współdzielonego w jednostce

Użyj operacji get/update w kolejkach lub tematach w bibliotekach zarządzania dla usługi Service Bus , aby uzyskać dostęp/zaktualizować odpowiednie reguły autoryzacji dostępu współdzielonego. Reguły można również dodać podczas tworzenia kolejek lub tematów przy użyciu tych bibliotek.

Korzystanie z autoryzacji sygnatury dostępu współdzielonego

Aplikacje korzystające z dowolnego zestawu SDK usługi Service Bus w dowolnym z oficjalnie obsługiwanych języków, takich jak .NET, Java, JavaScript i Python, mogą korzystać z autoryzacji sygnatury dostępu współdzielonego za pośrednictwem parametry połączenia przekazanych do konstruktora klienta.

Parametry połączenia mogą zawierać nazwę reguły (SharedAccessKeyName) i klucz reguły (SharedAccessKey) lub wcześniej wystawiony token (SharedAccessSignature). Jeśli znajdują się one w parametry połączenia przekazane do dowolnego konstruktora lub metody fabryki akceptującej parametry połączenia, dostawca tokenu SAS zostanie automatycznie utworzony i wypełniony.

Aby użyć autoryzacji sas z subskrypcjami usługi Service Bus, możesz użyć kluczy SAS skonfigurowanych w przestrzeni nazw usługi Service Bus lub w temacie.

Korzystanie z sygnatury dostępu współdzielonego (na poziomie protokołu HTTP)

Teraz, gdy wiesz już, jak tworzyć sygnatury dostępu współdzielonego dla wszystkich jednostek w usłudze Service Bus, możesz przystąpić do wykonywania żądania HTTP POST:

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

Pamiętaj, że to działa dla wszystkiego. Sygnaturę dostępu współdzielonego dla kolejki, tematu lub subskrypcji można utworzyć.

Jeśli nadasz nadawcy lub klientowi token SAS, nie mają klucza bezpośrednio i nie mogą odwrócić skrótu, aby go uzyskać. W związku z tym masz kontrolę nad tym, do czego mogą uzyskiwać dostęp i jak długo. Należy pamiętać, że jeśli zmienisz klucz podstawowy w zasadach, wszystkie utworzone na jego podstawie sygnatury dostępu współdzielonego zostaną unieważnione.

Korzystanie z sygnatury dostępu współdzielonego (na poziomie protokołu AMQP)

W poprzedniej sekcji pokazano, jak używać tokenu SAS z żądaniem HTTP POST do wysyłania danych do usługi Service Bus. Jak wiesz, możesz uzyskać dostęp do usługi Service Bus przy użyciu protokołu Advanced Message Queuing Protocol (AMQP), który jest preferowanym protokołem do użycia ze względów wydajności w wielu scenariuszach. Użycie tokenu SAS przy użyciu protokołu AMQP zostało opisane w dokumencie AMQP Claim-Based Security Version 1.0 , który działa w wersji roboczej od 2013 r., ale jest obecnie obsługiwany przez platformę Azure.

Przed rozpoczęciem wysyłania danych do usługi Service Bus wydawca musi wysłać token SAS wewnątrz komunikatu protokołu AMQP do dobrze zdefiniowanego węzła protokołu AMQP o nazwie $cbs (można go zobaczyć jako "specjalną" kolejkę używaną przez usługę do uzyskiwania i weryfikowania wszystkich tokenów SAS). Wydawca musi określić pole ReplyTo wewnątrz komunikatu AMQP; jest to węzeł, w którym usługa odpowiada wydawcy z wynikiem weryfikacji tokenu (prosty wzorzec żądania/odpowiedzi między wydawcą i usługą). Ten węzeł odpowiedzi jest tworzony "na bieżąco", mówiąc o "dynamicznym tworzeniu węzła zdalnego", zgodnie ze specyfikacją protokołu AMQP 1.0. Po sprawdzeniu, czy token SAS jest prawidłowy, wydawca może przejść do przodu i rozpocząć wysyłanie danych do usługi.

W poniższych krokach pokazano, jak wysłać token SAS przy użyciu protokołu AMQP przy użyciu biblioteki AMQP.NET Lite . Jest to przydatne, jeśli nie możesz użyć oficjalnego zestawu SDK usługi Service Bus (na przykład w systemach WinRT, .NET Compact Framework, .NET Micro Framework i Mono) opracowywanych w języku C#. Ta biblioteka jest przydatna do zrozumienia sposobu działania zabezpieczeń opartych na oświadczeniach na poziomie protokołu AMQP, jak pokazano, jak działa na poziomie HTTP (z żądaniem HTTP POST i tokenem SAS wysyłanym wewnątrz nagłówka "Autoryzacja"). Jeśli nie potrzebujesz tak głębokiej wiedzy na temat protokołu AMQP, możesz użyć oficjalnego zestawu SDK usługi Service Bus w dowolnych obsługiwanych językach, takich jak .NET, JavaScript, Python i Go, co zrobi to za Ciebie.

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

Metoda PutCbsToken() odbiera połączenie (wystąpienie klasy połączenia AMQP udostępniane przez bibliotekę AMQP .NET Lite), które reprezentuje połączenie TCP z usługą i parametr sasToken , który jest tokenem SAS do wysłania.

Uwaga

Ważne jest, aby połączenie zostało utworzone przy użyciu mechanizmu uwierzytelniania SASL ustawionego na WARTOŚĆ ANONYMOUS (a nie domyślnego plain z nazwą użytkownika i hasłem używanym, gdy nie trzeba wysyłać tokenu SAS).

Następnie wydawca tworzy dwa linki protokołu AMQP do wysyłania tokenu SYGNATURy dostępu współdzielonego i odbierania odpowiedzi (wyniku weryfikacji tokenu) z usługi.

Komunikat AMQP zawiera zestaw właściwości i więcej informacji niż prosty komunikat. Token SAS jest treścią komunikatu (przy użyciu jego konstruktora). Właściwość "ReplyTo" jest ustawiona na nazwę węzła na potrzeby odbierania wyniku weryfikacji w linku odbiorcy (możesz zmienić jego nazwę, jeśli chcesz, i zostanie ona utworzona dynamicznie przez usługę). Ostatnie trzy właściwości aplikacji/niestandardowe są używane przez usługę, aby wskazać, jakiego rodzaju operację ma wykonać. Zgodnie ze specyfikacją wersji roboczej CBS muszą być nazwą operacji ("put-token"), typem tokenu (w tym przypadku wartością servicebus.windows.net:sastoken) i "nazwą" odbiorców , do których stosuje się token (cała jednostka).

Po wysłaniu przez wydawcę tokenu SAS na link nadawcy wydawca musi odczytać odpowiedź na link odbiorcy. Odpowiedź to prosty komunikat protokołu AMQP z właściwością aplikacji o nazwie "status-code" , która może zawierać te same wartości co kod stanu HTTP.

Prawa wymagane dla operacji usługi Service Bus

W poniższej tabeli przedstawiono prawa dostępu wymagane do różnych operacji na zasobach usługi Service Bus.

Operacja	Wymagane oświadczenie	Zakres oświadczeń
Przestrzeń nazw
Konfigurowanie reguły autoryzacji w przestrzeni nazw	Zarządzanie	Dowolny adres przestrzeni nazw
Rejestr usług
Wyliczanie zasad prywatnych	Zarządzanie	Dowolny adres przestrzeni nazw
Rozpoczynanie nasłuchiwania w przestrzeni nazw	Nasłuchiwanie	Dowolny adres przestrzeni nazw
Wysyłanie komunikatów do odbiornika w przestrzeni nazw	Wysyłanie	Dowolny adres przestrzeni nazw
Kolejka
Utwórz kolejkę	Zarządzanie	Dowolny adres przestrzeni nazw
Usuwanie kolejki	Zarządzanie	Dowolny prawidłowy adres kolejki
Wyliczanie kolejek	Zarządzanie	/$Resources/Kolejki
Pobieranie opisu kolejki	Zarządzanie	Dowolny prawidłowy adres kolejki
Konfigurowanie reguły autoryzacji dla kolejki	Zarządzanie	Dowolny prawidłowy adres kolejki
Wyślij do kolejki	Wysyłanie	Dowolny prawidłowy adres kolejki
Odbieranie komunikatów z kolejki	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Porzucanie lub uzupełnianie komunikatów po otrzymaniu komunikatu w trybie zaglądaj do blokowania	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Odroczenie komunikatu na potrzeby późniejszego pobierania	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Deadletter wiadomość	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Pobieranie stanu skojarzonego z sesją kolejki komunikatów	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Ustawianie stanu skojarzonego z sesją kolejki komunikatów	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Planowanie komunikatu na potrzeby późniejszego dostarczania	Nasłuchiwanie	Dowolny prawidłowy adres kolejki
Temat
Tworzenie tematu	Zarządzanie	Dowolny adres przestrzeni nazw
Usuwanie tematu	Zarządzanie	Dowolny prawidłowy adres tematu
Wyliczanie tematów	Zarządzanie	/$Resources/Tematy
Uzyskiwanie opisu tematu	Zarządzanie	Dowolny prawidłowy adres tematu
Konfigurowanie reguły autoryzacji dla tematu	Zarządzanie	Dowolny prawidłowy adres tematu
Wyślij do tematu	Wysyłanie	Dowolny prawidłowy adres tematu
Subskrypcja
Tworzenie subskrypcji	Zarządzanie	Dowolny adres przestrzeni nazw
Usuwanie subskrypcji	Zarządzanie	.. /myTopic/Subscriptions/mySubscription
Wyliczanie subskrypcji	Zarządzanie	.. /myTopic/Subscriptions
Uzyskiwanie opisu subskrypcji	Zarządzanie	.. /myTopic/Subscriptions/mySubscription
Porzucanie lub uzupełnianie komunikatów po otrzymaniu komunikatu w trybie zaglądaj do blokowania	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Odroczenie komunikatu na potrzeby późniejszego pobierania	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Deadletter wiadomość	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Pobieranie stanu skojarzonego z sesją tematu	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Ustawianie stanu skojarzonego z sesją tematu	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Reguły
Tworzenie reguły	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Usuń regułę	Nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription
Wyliczanie reguł	Zarządzanie lub nasłuchiwanie	.. /myTopic/Subscriptions/mySubscription/Rules

Następne kroki

Aby dowiedzieć się więcej na temat obsługi komunikatów usługi Service Bus, zobacz następujące tematy.

Udostępnij za pośrednictwem

Kontrola dostępu do usługi Service Bus z sygnaturami dostępu współdzielonego

Omówienie sygnatury dostępu współdzielonego

Zasady autoryzacji dostępu współdzielonego

Najlepsze rozwiązania dotyczące korzystania z sygnatury dostępu współdzielonego

Konfiguracja uwierzytelniania sygnatury dostępu współdzielonego

Generowanie tokenu sygnatury dostępu współdzielonego

Ponowne generowanie kluczy

Uwierzytelnianie sygnatury dostępu współdzielonego za pomocą usługi Service Bus

Uzyskiwanie dostępu do reguł autoryzacji dostępu współdzielonego w jednostce

Korzystanie z autoryzacji sygnatury dostępu współdzielonego

Korzystanie z sygnatury dostępu współdzielonego (na poziomie protokołu HTTP)

Korzystanie z sygnatury dostępu współdzielonego (na poziomie protokołu AMQP)

C#

Prawa wymagane dla operacji usługi Service Bus

Następne kroki

Opinia

Dodatkowe zasoby