Een toepassing verifiëren en autoriseren met Azure Active Directory toegang tot Azure Service Bus-entiteiten

  • Artikel
  • 7 minuten om te lezen

Azure Service Bus ondersteunt het gebruik van Azure Active Directory (Azure AD) om aanvragen voor Service Bus-entiteiten (wachtrijen, onderwerpen, abonnementen of filters) te autor toestemming te geven. Met Azure AD kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal, die een gebruiker, groep of toepassingsservice-principal kan zijn. Zie Inzicht in de verschillende rollen voor meer informatie over rollen en roltoewijzingen.

Overzicht

Wanneer een beveiligingsprincipaal (een gebruiker, groep of toepassing) toegang probeert te krijgen tot een Service Bus entiteit, moet de aanvraag worden geautoriseerd. Met Azure AD is toegang tot een resource een proces in twee stappen.

  1. Eerst wordt de identiteit van de beveiligingsprincipaal geverifieerd en wordt een OAuth 2.0-token geretourneerd. De resourcenaam voor het aanvragen van een token is https://servicebus.azure.net .
  2. Vervolgens wordt het token doorgegeven als onderdeel van een aanvraag aan de Service Bus-service om toegang te verlenen tot de opgegeven resource.

De verificatiestap vereist dat een toepassingsaanvraag een OAuth 2.0-toegangsteken tijdens runtime bevat. Als een toepassing wordt uitgevoerd binnen een Azure-entiteit, zoals een Azure-VM, een virtuele-machineschaalset of een Azure Function-app, kan deze een beheerde identiteit gebruiken voor toegang tot de resources. Zie Toegang tot Azure Service Bus-resources verifiëren met Azure Active Directory en beheerde identiteiten voor Azure-resources voor meer informatie over het verifiëren van aanvragen van een beheerde identiteit naar Service Bus-service.

De autorisatiestap vereist dat een of meer Azure-rollen worden toegewezen aan de beveiligingsprincipaal. Azure Service Bus biedt Azure-rollen die sets machtigingen voor Service Bus resources omvatten. De rollen die zijn toegewezen aan een beveiligingsprincipaal bepalen de machtigingen die de principal krijgt. Zie Ingebouwde Azure-rollen voor Azure Service Bus voor meer informatie over het toewijzen van Azure-rollen aan Azure Service Bus.

Native toepassingen en webtoepassingen die aanvragen indienen bij Service Bus kunnen ook autoreren met Azure AD. In dit artikel wordt beschreven hoe u een toegangs token aanvraagt en dit gebruikt om aanvragen voor Service Bus resources.

Azure-rollen toewijzen voor toegangsrechten

Azure Active Directory (Azure AD) autoreert toegangsrechten voor beveiligde resources via Azure RBAC. Azure Service Bus definieert een set ingebouwde Azure-rollen die algemene sets machtigingen omvatten die worden gebruikt voor toegang tot Service Bus-entiteiten en u kunt ook aangepaste rollen definiëren voor toegang tot de gegevens.

Wanneer een Azure-rol wordt toegewezen aan een Azure AD-beveiligingsprincipaal, verleent Azure toegang tot deze resources voor die beveiligingsprincipaal. Toegang kan worden beperkt tot het abonnementsniveau, de resourcegroep of de Service Bus naamruimte. Een Azure AD-beveiligingsprincipaal kan een gebruiker, een groep, een toepassingsservice-principal of een beheerde identiteit voor Azure-resources zijn.

Ingebouwde Azure-rollen voor Azure Service Bus

Voor Azure Service Bus is het beheer van naamruimten en alle gerelateerde resources via de Azure Portal en de Azure Resource Management-API al beveiligd met behulp van het Azure RBAC-model. Azure biedt de onderstaande ingebouwde Azure-rollen voor het autoriseren van toegang tot Service Bus naamruimte:

Resourcebereik

Voordat u een Azure-rol toewijst een beveiligingsprincipal, moet u het toegangsbereik bepalen dat de beveiligingsprincipal moet hebben. Uit best practices blijkt dat het het beste is om het nauwst mogelijke bereik toe te wijzen.

In de volgende lijst worden de niveaus beschreven waarop u toegang tot Service Bus resources kunt beperken, te beginnen met het kleinste bereik:

  • Wachtrij, onderwerp of abonnement: Roltoewijzing is van toepassing op de specifieke Service Bus entiteit. Momenteel biedt de Azure Portal geen ondersteuning voor het toewijzen van gebruikers/groepen/beheerde identiteiten aan Service Bus Azure-rollen op abonnementsniveau.
  • Service Bus naamruimte: Roltoewijzing omvat de volledige topologie van Service Bus onder de naamruimte en aan de consumentengroep die ermee is gekoppeld.
  • Resourcegroep: Roltoewijzing is van toepassing op alle Service Bus resources onder de resourcegroep.
  • Abonnement: roltoewijzing is van toepassing op Service Bus resources in alle resourcegroepen in het abonnement.

Notitie

Houd er rekening mee dat het maximaal vijf minuten kan duren voordat Azure-roltoewijzingen zijn doorgegeven.

Zie Roldefinities begrijpen voor meer informatie over hoe ingebouwde rollen worden gedefinieerd. Zie Aangepaste Azure-rollen voor meer informatie over het maken van aangepaste Azure-rollen.

Azure-rollen toewijzen met behulp van de Azure Portal

Wijs een van de Service Bus toe aan de service-principal van de toepassing op het gewenste bereik (Service Bus naamruimte, resourcegroep, abonnement). Zie Azure-rollen toewijzen met behulp van deAzure Portal .

Zodra u de rol en het bereik ervan hebt definieert, kunt u dit gedrag testen met de voorbeelden op GitHub.

Verifiëren vanuit een toepassing

Een belangrijk voordeel van het gebruik van Azure AD Service Bus is dat uw referenties niet meer in uw code hoeven te worden opgeslagen. In plaats daarvan kunt u een OAuth 2.0-toegangsteken aanvragen bij Microsoft identity platform. Azure AD verifieert de beveiligingsprincipaal (een gebruiker, een groep of service-principal) die de toepassing uitvoeren. Als de verificatie slaagt, retourneert Azure AD het toegangsken voor de toepassing en kan de toepassing vervolgens het toegangsken gebruiken om aanvragen voor Azure-Service Bus.

In de volgende secties ziet u hoe u uw systeemeigen toepassing of webtoepassing configureert voor verificatie met Microsoft identity platform 2.0. Zie overzicht van Microsoft identity platform (v2.0) Microsoft identity platform meer informatie over Microsoft identity platform 2.0.

Zie Toegang verlenen tot Azure Active Directory-webtoepassingen met behulp van de OAuth 2.0-stroom voor het verlenen van code voor een overzicht van de stroom voor het verlenen van OAuth 2.0-code.

Uw toepassing registreren bij een Azure AD-tenant

De eerste stap bij het gebruik van Azure AD Service Bus entiteiten is het registreren van uw clienttoepassing bij een Azure AD-tenant van de Azure Portal. Wanneer u uw clienttoepassing registreert, verstrekt u informatie over de toepassing aan AD. Azure AD biedt vervolgens een client-id (ook wel een toepassings-id genoemd) die u kunt gebruiken om uw toepassing te koppelen aan Azure AD-runtime. Zie Toepassings- en service-principalobjecten in Azure Active Directory voor meer informatie over de client-id.

De volgende afbeeldingen tonen stappen voor het registreren van een webtoepassing:

Een toepassing registreren

Notitie

Als u uw toepassing registreert als een native toepassing, kunt u een geldige URI opgeven voor de omleidings-URI. Voor native toepassingen hoeft deze waarde geen echte URL te zijn. Voor webtoepassingen moet de omleidings-URI een geldige URI zijn, omdat hiermee de URL wordt opgegeven waaraan tokens worden verstrekt.

Nadat u uw toepassing hebt geregistreerd, ziet u de toepassings-id (client-id) onder Instellingen:

Toepassings-id van de geregistreerde toepassing

Zie Toepassingen integreren met Azure Active Directory voor meer informatie over het registreren van een Azure Active Directory.

Belangrijk

Noteer de TenantId en de ApplicationId. U hebt deze waarden nodig om de toepassing uit te voeren.

Een clientgeheim maken

De toepassing heeft een clientgeheim nodig om de identiteit te bewijzen bij het aanvragen van een token. Volg deze stappen om het clientgeheim toe te voegen.

  1. Navigeer naar uw app-registratie in Azure Portal als u nog niet op de pagina bent.

  2. Selecteer Certificaten & geheimen in het menu links.

  3. Selecteer onder Clientgeheimen de optie Nieuw clientgeheim om een nieuw geheim te maken.

    Nieuw clientgeheim - knop

  4. Geef een beschrijving op voor het geheim, kies het gezochte verloopinterval en selecteer vervolgens Toevoegen.

    Pagina Clientgeheim toevoegen

  5. Kopieer onmiddellijk de waarde van het nieuwe geheim naar een veilige locatie. De opvulwaarde wordt slechts één keer aan u weergegeven.

    Clientgeheim

Machtigingen voor de Service Bus-API

Als uw toepassing een consoletoepassing is, moet u een systeemeigen toepassing registreren en API-machtigingen voor Microsoft.ServiceBus toevoegen aan de vereiste machtigingenset. Voor native toepassingen is ook een omleidings-URI in Azure AD nodig, die als id fungeert; de URI hoeft geen netwerkbestemming te zijn. Gebruik https://servicebus.microsoft.com voor dit voorbeeld, omdat de voorbeeldcode die URI al gebruikt.

De client voor Service Bus authenticeren

Zodra u uw toepassing hebt geregistreerd en deze machtigingen hebt verleend voor het verzenden/ontvangen van gegevens in Azure Service Bus, kunt u uw client verifiëren met de clientgeheimreferenties, zodat u aanvragen kunt indienen bij Azure Service Bus.

Zie de sectie Scenarios van de Microsoft Authentication Library (MSAL) for .NET GitHub repository (Microsoft Authentication Library) voor een lijst met scenario's waarvoor het verkrijgen van tokens wordt ondersteund.

Met de nieuwste Azure.Messaging.ServiceBus-bibliotheek kunt u de ServiceBusClient verifiëren met een ClientSecretCredential,die is gedefinieerd in de Azure.Identity-bibliotheek.

TokenCredential credential = new ClientSecretCredential("<tenant_id>", "<client_id>", "<client_secret>");
var client = new ServiceBusClient("<fully_qualified_namespace>", credential);

Als u de oudere .NET-pakketten gebruikt, raadpleegt u de RoleBasedAccessControl-voorbeelden in de opslagplaats met azure-service-bus-voorbeelden.

Volgende stappen

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