Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa Azure Service Bus obsługuje używanie identyfikatora Entra firmy Microsoft do autoryzowania żądań do jednostek usługi Service Bus (kolejek, tematów, subskrypcji lub filtrów). Za pomocą identyfikatora Entra firmy Microsoft możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, podmiotem usługi aplikacji lub tożsamością zarządzaną dla zasobów platformy Azure.
Kluczową zaletą korzystania z identyfikatora Entra firmy Microsoft w usłudze Azure Service Bus jest to, że nie trzeba już przechowywać poświadczeń w kodzie. Zamiast tego możesz zażądać tokenu dostępu OAuth 2.0 z Platforma tożsamości Microsoft. Jeśli uwierzytelnianie powiedzie się, identyfikator Entra firmy Microsoft zwraca token dostępu do aplikacji. Następnie aplikacja może użyć tokenu dostępu do autoryzowania żądań do zasobów usługi Service Bus.
Możesz wyłączyć uwierzytelnianie klucza sygnatury dostępu lokalnego lub współdzielonego (SAS) dla obszaru nazw Service Bus i zezwolić tylko na uwierzytelnianie Microsoft Entra. Aby uzyskać instrukcje krok po kroku, zobacz Wyłączanie uwierzytelniania lokalnego.
Omówienie
Gdy podmiot zabezpieczeń (użytkownik, grupa lub aplikacja) próbuje uzyskać dostęp do jednostki usługi Service Bus, żądanie musi być autoryzowane. W przypadku identyfikatora Entra firmy Microsoft dostęp do zasobu jest procesem dwuetapowym:
- Tożsamość podmiotu zabezpieczeń jest uwierzytelniana i zwracany jest token OAuth 2.0. Nazwa zasobu do żądania tokenu to
https://servicebus.azure.net. - Token jest przekazywany jako część żądania do usługi Service Bus w celu autoryzowania dostępu do określonego zasobu.
Krok uwierzytelniania wymaga, aby żądanie aplikacji zawiera token dostępu OAuth 2.0 w czasie wykonywania. Jeśli aplikacja działa w ramach jednostki platformy Azure, takiej jak maszyna wirtualna platformy Azure, zestaw skalowania maszyn wirtualnych lub aplikacja funkcji, może użyć tożsamości zarządzanej w celu uzyskania dostępu do zasobów. Aby dowiedzieć się, jak uwierzytelniać żądania wysyłane przez tożsamość zarządzaną do usługi Service Bus, zobacz Używanie tożsamości zarządzanych za pomocą usługi Azure Service Bus.
Krok autoryzacji wymaga przypisania co najmniej jednej roli platformy Azure do podmiotu zabezpieczeń. Usługa Service Bus udostępnia role platformy Azure, które obejmują zestawy uprawnień dla zasobów usługi Service Bus. Role przypisane do podmiotu zabezpieczeń określają uprawnienia, które podmiot zabezpieczeń ma w zasobach usługi Service Bus. Aby dowiedzieć się więcej na temat przypisywania ról platformy Azure do usługi Service Bus, zobacz Role wbudowane platformy Azure dla usługi Azure Service Bus.
Aplikacje natywne i aplikacje internetowe, które wysyłają żądania do usługi Service Bus, mogą również autoryzować za pomocą identyfikatora Entra firmy Microsoft. W tym artykule pokazano, jak zażądać tokenu dostępu i użyć go do autoryzowania żądań dotyczących zasobów usługi Service Bus.
Wbudowane role platformy Azure dla usługi Azure Service Bus
Microsoft Entra uprawnia prawa dostępu do zabezpieczonych zasobów za pomocą Azure RBAC. Usługa Azure Service Bus definiuje zestaw wbudowanych ról platformy Azure, które obejmują typowe zestawy uprawnień używanych do uzyskiwania dostępu do jednostek usługi Service Bus. Możesz również zdefiniować role niestandardowe na potrzeby uzyskiwania dostępu do danych.
Po przypisaniu roli platformy Azure do podmiotu zabezpieczeń firmy Microsoft Entra platforma Azure udziela dostępu do tych zasobów dla tego podmiotu zabezpieczeń. Zakres dostępu można ograniczyć do poziomu subskrypcji, grupy zasobów, przestrzeni nazw usługi Service Bus lub jednostki (kolejka, temat lub subskrypcja). Podmiot zabezpieczeń firmy Microsoft Entra może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną dla zasobów platformy Azure.
W przypadku usługi Azure Service Bus model RBAC platformy Azure pomaga chronić zarządzanie przestrzeniami nazw i wszystkimi powiązanymi zasobami za pośrednictwem witryny Azure Portal i interfejsu API zarządzania zasobami platformy Azure. Platforma Azure udostępnia następujące wbudowane role umożliwiające autoryzowanie dostępu do przestrzeni nazw usługi Service Bus:
- Właściciel danych usługi Azure Service Bus: użyj tej roli, aby zapewnić pełny dostęp do zasobów usługi Service Bus.
- Nadawca danych usługi Azure Service Bus: ta rola umożliwia wysyłanie dostępu do przestrzeni nazw usługi Service Bus i jej jednostek.
- Odbiornik danych usługi Azure Service Bus: użyj tej roli, aby udzielić dostępu do odbioru danych w przestrzeni nazw usługi Service Bus i jej jednostkach.
Zakres zasobu
Przed przypisaniem roli platformy Azure do podmiotu zabezpieczeń określ zakres dostępu, który powinien mieć podmiot zabezpieczeń. Najlepsze rozwiązania określają, że zawsze najlepiej przyznać tylko najwęższy możliwy zakres.
Poniższa lista zawiera opis poziomów, na których można określić zakres dostępu do zasobów usługi Service Bus, począwszy od najwęższego zakresu:
Kolejka, temat lub subskrypcja: Przypisanie roli ma zastosowanie do określonej jednostki usługi Service Bus. Obecnie portal Azure nie obsługuje przypisywania użytkowników, grup ani tożsamości zarządzanych do ról Azure usługi Service Bus na poziomie subskrypcji tematu.
Przestrzeń nazw usługi Service Bus: przypisanie roli obejmuje całą topologię usługi Service Bus w przestrzeni nazw oraz do skojarzonej z nią kolejki lub subskrypcji tematu.
Grupa zasobów: przypisanie roli dotyczy wszystkich zasobów usługi Service Bus w grupie zasobów.
Subskrypcja platformy Azure: przypisanie roli dotyczy wszystkich zasobów usługi Service Bus we wszystkich grupach zasobów w subskrypcji.
Należy pamiętać, że propagacja przypisań ról w usłudze Azure może potrwać do pięciu minut.
Aby uzyskać więcej informacji na temat sposobu definiowania ról wbudowanych, zobacz Omówienie definicji ról platformy Azure. Aby uzyskać informacje na temat tworzenia ról niestandardowych platformy Azure, zobacz Role niestandardowe platformy Azure.
Uwierzytelnianie z aplikacji
Kluczową zaletą korzystania z identyfikatora Entra firmy Microsoft z usługą Service Bus jest to, że poświadczenia nie muszą być już przechowywane w kodzie. Zamiast tego możesz zażądać tokenu dostępu OAuth 2.0 z Platforma tożsamości Microsoft.
Microsoft Entra uwierzytelnia podmiot zabezpieczeń (użytkownika, grupę, podmiot usługi lub tożsamość zarządzaną dla zasobów platformy Azure) działający w aplikacji. Jeśli uwierzytelnianie powiedzie się, identyfikator Entra firmy Microsoft zwraca token dostępu do aplikacji. Następnie aplikacja może użyć tokenu dostępu do autoryzowania żądań do usługi Service Bus.
W poniższych sekcjach pokazano, jak skonfigurować aplikację natywną lub aplikację internetową na potrzeby uwierzytelniania przy użyciu platformy tożsamości firmy Microsoft 2.0. Aby uzyskać więcej informacji na temat platformy, zobacz Co to jest platforma tożsamości firmy Microsoft?.
Aby zapoznać się z omówieniem przepływu udzielania kodu OAuth 2.0, zobacz Platforma tożsamości firmy Microsoft i przepływ kodu autoryzacji OAuth 2.0.
Zarejestruj swoją aplikację w dzierżawie Microsoft Entra.
Pierwszym krokiem używania Microsoft Entra ID do autoryzowania elementów usługi Service Bus jest zarejestrowanie aplikacji klienckiej w dzierżawie Microsoft Entra z portalu Azure. Podczas rejestrowania aplikacji klienckiej należy podać informacje o aplikacji w usłudze Active Directory. Identyfikator Entra firmy Microsoft udostępnia następnie identyfikator klienta (nazywany również identyfikatorem aplikacji), którego można użyć do skojarzenia aplikacji ze środowiskiem uruchomieniowym Microsoft Entra. Aby dowiedzieć się więcej o identyfikatorze klienta, zobacz Application and service principal objects in Microsoft Entra ID (Obiekty aplikacji i jednostki usługi w identyfikatorze Entra firmy Microsoft).
Aby zarejestrować aplikację przy użyciu identyfikatora Entra firmy Microsoft, wykonaj kroki opisane w temacie Rejestrowanie aplikacji w identyfikatorze Entra firmy Microsoft.
Uwaga
Jeśli zarejestrujesz aplikację jako aplikację natywną, możesz określić dowolny prawidłowy identyfikator URI przekierowania. W przypadku aplikacji natywnych ta wartość nie musi być rzeczywistym adresem URL. W przypadku aplikacji internetowych identyfikator URI przekierowania musi być poprawnym identyfikatorem URI, ponieważ określa adres URL, do którego są dostarczane tokeny.
Po zarejestrowaniu aplikacji w obszarze Ustawienia są wyświetlane identyfikatory aplikacji (klienta) i identyfikator katalogu (dzierżawy). Zanotuj te wartości. Będą one potrzebne do uruchomienia aplikacji.
Utwórz tajny klucz klienta
Aplikacja potrzebuje klucza tajnego klienta, aby potwierdzić swoją tożsamość podczas żądania tokenu. Aby dodać klucz tajny klienta, wykonaj następujące kroki:
W witrynie Azure Portal przejdź do rejestracji aplikacji, jeśli nie jesteś jeszcze na stronie.
W menu po lewej stronie wybierz pozycję Certyfikaty i wpisy tajne.
W obszarze Wpisy tajne klienta wybierz pozycję Nowy klucz tajny klienta, aby utworzyć nowy wpis tajny.
Podaj opis tajemnicy, wybierz interwał wygaśnięcia, a następnie wybierz Dodaj.
Natychmiast skopiuj wartość nowej tajemnicy do bezpiecznej lokalizacji. Pełna wartość jest wyświetlana tylko raz.
Dodaj uprawnienia dla interfejsu API usługi Service Bus
Jeśli aplikacja jest aplikacją konsolową, musisz zarejestrować aplikację natywną i dodać uprawnienia Microsoft.ServiceBus interfejsu API do zestawu wymaganych uprawnień.
Aplikacje natywne również potrzebują URI przekierowania w Microsoft Entra ID, które pełni rolę identyfikatora. Identyfikator URI nie musi być miejscem docelowym sieci. Użyj https://servicebus.microsoft.com w tym przykładzie, ponieważ przykładowy kod używa już tego identyfikatora URI.
Przypisywanie ról platformy Azure za pośrednictwem witryny Azure Portal
Przypisz jedną z ról usługi Service Bus do jednostki usługi aplikacji w żądanym zakresie (jednostka, przestrzeń nazw usługi Service Bus, grupa zasobów lub subskrypcja platformy Azure). Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal.
Po zdefiniowaniu roli i jej zakresu możesz przetestować to zachowanie za pomocą przykładu w witrynie GitHub.
Uwierzytelnianie klienta usługi Service Bus
Po zarejestrowaniu aplikacji i przyznaniu jej uprawnień do wysyłania i odbierania danych w usłudze Azure Service Bus, możesz uwierzytelnić klienta przy użyciu tajnych poświadczeń klienta. To uwierzytelnianie umożliwia wykonywanie żądań względem usługi Azure Service Bus.
Aby zapoznać się z listą scenariuszy, w których jest obsługiwane uzyskiwanie tokenów, zobacz sekcję Scenariusze w repozytorium Microsoft Authentication Library (MSAL) dla repozytorium GitHub platformy .NET .
Korzystając z najnowszej biblioteki Azure.Messaging.ServiceBus , można uwierzytelnić element ServiceBusClient za pomocą elementu ClientSecretCredential, który jest zdefiniowany w bibliotece Azure.Identity .
TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);
Jeśli używasz starszych pakietów platformy .NET, zobacz przykłady Azure RBAC dla usługi Service Bus na GitHubie.
Treści powiązane
Aby uzyskać więcej informacji na temat Azure RBAC, zobacz Co to jest kontrola dostępu oparta na rolach na platformie Azure (Azure RBAC)?.
Aby dowiedzieć się, jak przypisywać role platformy Azure i zarządzać nimi przy użyciu narzędzia Azure PowerShell, Azure CLI lub interfejsu API REST, zobacz następujące artykuły:
Aby dowiedzieć się więcej o komunikatach usługi Service Bus, zobacz następujące artykuły: