Een toepassing verifiëren en autoriseren met Microsoft Entra-id voor toegang tot Azure Service Bus-entiteiten
Azure Service Bus ondersteunt het gebruik van Microsoft Entra ID voor het autoriseren van aanvragen voor Service Bus-entiteiten (wachtrijen, onderwerpen, abonnementen of filters). Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. Dit kan een gebruiker, groep, toepassingsservice-principal of een beheerde identiteit voor Azure-resources zijn. Een belangrijk voordeel van het gebruik van Microsoft Entra ID met Azure Service Bus is dat u uw referenties niet meer hoeft op te slaan in de code. In plaats daarvan kunt u een OAuth 2.0-toegangstoken aanvragen via het Microsoft Identity Platform. Als de verificatie slaagt, retourneert Microsoft Entra-id een toegangstoken naar de toepassing en kan de toepassing vervolgens het toegangstoken gebruiken om aanvragen voor Service Bus-resources te autoriseren.
Belangrijk
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
Wanneer een beveiligingsprincipaal (een gebruiker, groep of toepassing) toegang probeert te krijgen tot een Service Bus-entiteit, moet de aanvraag worden geautoriseerd. Met Microsoft Entra ID is de toegang tot een resource een proces in twee stappen.
- 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. - Vervolgens wordt het token doorgegeven als onderdeel van een aanvraag aan de Service Bus-service om toegang tot de opgegeven resource te autoriseren.
Voor de verificatiestap is vereist dat een toepassingsaanvraag tijdens runtime een OAuth 2.0-toegangstoken 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 om toegang te krijgen tot de resources. Zie Toegang tot Azure Service Bus-resources verifiëren met Microsoft Entra ID en beheerde identiteiten voor Azure-resources voor meer informatie over het verifiëren van aanvragen van een beheerde identiteit voor de Service Bus-service.
Voor de autorisatiestap moeten 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 welke machtigingen de principal heeft voor Service Bus-resources. Zie ingebouwde Azure-rollen voor Azure Service Bus voor meer informatie over het toewijzen van Azure-rollen aan Azure Service Bus.
Systeemeigen toepassingen en webtoepassingen die aanvragen indienen bij Service Bus, kunnen ook autoriseren met Microsoft Entra-id. In dit artikel leest u hoe u een toegangstoken aanvraagt en gebruikt om aanvragen voor Service Bus-resources te autoriseren.
Ingebouwde Azure-rollen voor Azure Service Bus
Microsoft Entra autoriseert 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 is toegewezen aan een Microsoft Entra-beveiligingsprincipaal, verleent Azure toegang tot deze resources voor die beveiligingsprincipaal. Toegang kan worden beperkt tot het niveau van het abonnement, de resourcegroep of de Service Bus-naamruimte. Een Microsoft Entra-beveiligingsprincipaal kan een gebruiker, een groep, een toepassingsservice-principal of een beheerde identiteit voor Azure-resources zijn.
Voor Azure Service Bus is het beheer van naamruimten en alle gerelateerde resources via Azure Portal en de Azure Resource Management-API al beveiligd met behulp van het Azure RBAC-model. Azure biedt de volgende ingebouwde rollen voor het autoriseren van toegang tot een Service Bus-naamruimte:
- Azure Service Bus-gegevenseigenaar: gebruik deze rol om volledige toegang te verlenen tot de Service Bus-resources.
- Azure Service Bus-gegevenszender: gebruik deze rol om de verzendtoegang tot de Service Bus-naamruimte en de bijbehorende entiteiten te geven.
- Azure Service Bus-gegevensontvanger: gebruik deze rol om toegang te verlenen tot de Service Bus-naamruimte en de bijbehorende entiteiten.
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 instellen, te beginnen met het smalste bereik:
- Wachtrij, onderwerp of abonnement: roltoewijzing is van toepassing op de specifieke Service Bus-entiteit. Op dit moment biedt Azure Portal geen ondersteuning voor het toewijzen van gebruikers/groepen/beheerde identiteiten aan Service Bus Azure-rollen op abonnementsniveau.
- Service Bus-naamruimte: roltoewijzing beslaat de hele topologie van Service Bus onder de naamruimte en de daaraan gekoppelde consumentengroep.
- Resourcegroep: Roltoewijzing is van toepassing op alle Service Bus-resources onder de resourcegroep.
- Abonnement: Roltoewijzing is van toepassing op alle 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 informatie over het maken van aangepaste Azure-rollen.
Verifiëren vanuit een toepassing
Een belangrijk voordeel van het gebruik van Microsoft Entra-id met Service Bus is dat uw referenties niet meer hoeven te worden opgeslagen in uw code. In plaats daarvan kunt u een OAuth 2.0-toegangstoken aanvragen bij het Microsoft Identity Platform. Microsoft Entra verifieert de beveiligingsprincipaal (een gebruiker, een groep, een service-principal of een beheerde identiteit voor Azure-resources) die de toepassing uitvoert. Als de verificatie slaagt, retourneert Microsoft Entra ID het toegangstoken naar de toepassing en kan de toepassing vervolgens het toegangstoken gebruiken om aanvragen voor Azure Service Bus te autoriseren.
In de volgende secties ziet u hoe u uw systeemeigen toepassing of webtoepassing configureert voor verificatie met Microsoft Identity Platform 2.0. Zie het overzicht van Microsoft Identity Platform (v2.0) voor meer informatie over Microsoft Identity Platform 2.0.
Zie Toegang verlenen tot Microsoft Entra-webtoepassingen autoriseren met behulp van de stroom voor het verlenen van OAuth 2.0-code voor een overzicht van de stroom voor het verlenen van OAuth 2.0-code.
Uw toepassing registreren bij een Microsoft Entra-tenant
De eerste stap bij het gebruik van Microsoft Entra-id voor het autoriseren van Service Bus-entiteiten is het registreren van uw clienttoepassing bij een Microsoft Entra-tenant vanuit Azure Portal. Wanneer u uw clienttoepassing registreert, geeft u informatie over de toepassing aan AD op. Microsoft Entra-id biedt vervolgens een client-id (ook wel een toepassings-id genoemd) die u kunt gebruiken om uw toepassing te koppelen aan Microsoft Entra Runtime. Zie Toepassings- en service-principalobjecten in Microsoft Entra-id voor meer informatie over de client-id.
Volg de stappen in de quickstart: Registreer een toepassing bij het Microsoft Identity Platform om uw toepassing te registreren bij Microsoft Entra ID.
Notitie
Als u uw toepassing registreert als een systeemeigen toepassing, kunt u elke geldige URI voor de omleidings-URI opgeven. Voor systeemeigen 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 waarnaar tokens worden opgegeven.
Nadat u uw toepassing hebt geregistreerd, ziet u de id van de toepassing (client) en de map-id (tenant) onder Instellingen:
Belangrijk
Noteer de TenantId en de ApplicationId. U hebt deze waarden nodig om de toepassing uit te voeren.
Zie Toepassingen integreren met Microsoft Entra ID voor meer informatie over het registreren van een toepassing bij Microsoft Entra ID.
Een clientgeheim maken
De toepassing heeft een clientgeheim nodig om de identiteit ervan te bewijzen bij het aanvragen van een token. Volg deze stappen om het clientgeheim toe te voegen.
Ga naar uw app-registratie in Azure Portal als u zich nog niet op de pagina bevindt.
Selecteer Certificaten en geheimen in het linkermenu.
Selecteer onder Clientgeheimen het nieuwe clientgeheim om een nieuw geheim te maken.
Geef een beschrijving op voor het geheim en kies het gewenste verloopinterval en selecteer vervolgens Toevoegen.
Kopieer onmiddellijk de waarde van het nieuwe geheim naar een veilige locatie. De opvulwaarde wordt slechts eenmaal weergegeven.
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 . Systeemeigen toepassingen hebben ook een omleidings-URI in Microsoft Entra-id nodig, die als id fungeert. De URI hoeft geen netwerkbestemming te zijn. Gebruik https://servicebus.microsoft.com dit voorbeeld omdat de voorbeeldcode die URI al gebruikt.
Azure-rollen toewijzen met behulp van het Azure Portal
Wijs een van de Service Bus-rollen toe aan de service-principal van de toepassing op het gewenste bereik (Service Bus-naamruimte, resourcegroep, abonnement). Raadpleeg Azure-rollen toewijzen met Azure Portal voor informatie over het toewijzen van rollen.
Zodra u de rol en het bijbehorende bereik hebt gedefinieerd, kunt u dit gedrag testen met het voorbeeld op GitHub.
De Service Bus-client verifiëren
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 referenties van het clientgeheim, zodat u aanvragen kunt indienen bij Azure Service Bus.
Zie de sectie Scenario's van de Microsoft Authentication Library (MSAL) voor .NET GitHub-opslagplaats voor een lijst met scenario's waarvoor het verkrijgen van tokens wordt ondersteund.
Met behulp van 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
- Voor meer informatie over Azure RBAC raadpleegt u Wat is op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)?
- Zie de volgende artikelen voor meer informatie over het toewijzen en beheren van Azure-roltoewijzingen met Azure PowerShell, Azure CLI of de REST API:
- Azure-roltoewijzingen toevoegen of verwijderen met behulp van Azure PowerShell
- Azure-roltoewijzingen toevoegen of verwijderen met behulp van Azure CLI
- Azure-roltoewijzingen toevoegen of verwijderen met behulp van de REST API
- Azure-roltoewijzingen toevoegen of verwijderen met behulp van Azure Resource Manager-sjablonen
Zie de volgende onderwerpen voor meer informatie over de Service Bus-berichtenservice