Delen via

Communicatie tussen tenants implementeren met behulp van multitenant-toepassingen

  • Artikel

Deze handleiding biedt een oplossing voor bidirectionele, beveiligde communicatie tussen services die worden gehost in Azure-abonnementen die door verschillende Microsoft Entra-tenants worden beheerd.

Het beveiligen van multitenant-communicatie in Azure kan lastig zijn vanwege beperkingen die inherent zijn aan veel services. U kunt voorkomen dat u referenties rechtstreeks hoeft te beheren met behulp van door Azure beheerde identiteiten om tokens van Microsoft Entra-id te verkrijgen. Beheerde Identiteiten van Azure werken echter niet over tenantgrenzen en het gebruikelijke alternatief is het gebruik van gedeelde geheimen, zoals SHARED Access Signature-URL's. Houd er rekening mee dat als u gedeelde geheimen gebruikt, u de geheimen veilig moet distribueren en roteren over de grenzen van de Microsoft Entra-tenant.

Een optie die deze overhead vermijdt, is door een multitenant-toepassing te maken die de identiteit van uw workload vertegenwoordigt. Via een toestemmingsproces kunt u deze workloadidentiteit bekend maken bij een externe tenant en uiteindelijk toestaan dat services in de externe tenant worden geverifieerd.

Dit artikel bevat een voorbeeld van een implementatie van dit patroon dat gebruikmaakt van voorbeeldcode.

Dit patroon kan opnieuw worden gebruikt voor elk scenario met meerdere tenants met verschillende services die moeten communiceren over de grenzen van Microsoft Entra-tenants.

Architectuur

Een diagram van de communicatiearchitectuur tussen tenants.

Download een PowerPoint-bestand van deze architectuur.

Workflow

De volgende werkstroom komt overeen met het voorgaande diagram:

  1. Een beheerder aan de providerzijde maakt een registratie voor meerdere tenants en stelt er een clientgeheim voor in.

  2. Een beheerder aan de klantzijde richt een service-principal in de tenant in. Deze service-principal is gebaseerd op de multitenant-toepassing die de provider heeft gemaakt. U kunt deze stap op meerdere manieren uitvoeren. In het voorbeeld hebben we ervoor gekozen om een URL te maken voor de tenantbeheerder van de klant, maar u kunt in plaats daarvan de Microsoft Graph API gebruiken.

  3. De klant past RBAC-rollen (op rollen gebaseerd toegangsbeheer) toe op deze nieuwe service-principal, zodat deze gemachtigd is voor toegang tot Azure Service Bus.

  4. De functie-app van de provider gebruikt de client-id en het clientgeheim van de toepassingsregistratie om een geverifieerd bericht te verzenden naar de Service Bus-wachtrij van de klant.

  5. De functie-app van de klant gebruikt een beheerde identiteit om het bericht van de provider uit de wachtrij te lezen via een Service Bus-trigger.

  6. Nadat het bericht is ontvangen, werkt de functie-app van de klant doorgaans wat voordat een statusbericht naar de provider wordt verzonden. In dit geval verzendt de functie-app voor demodoeleinden onmiddellijk een statusbericht naar de provider in een afzonderlijke wachtrij in dezelfde Service Bus.

  7. Deze functie-app leest uit de statuswachtrij van de tenant van de klant via een timer die Door Azure Functions wordt geactiveerd.

Scenariodetails

Een provider heeft meerdere klanten. De provider en elke klant hebben hun eigen Microsoft Entra ID-tenant en Azure-resources. De provider en elke klant hebben een veilige, bidirectionele communicatiemethode nodig, zodat ze berichten kunnen uitwisselen via Service Bus-wachtrijen. De oplossing moet een overtuigend identiteitsverhaal hebben dat het introduceren van onnodige referenties of geheimen voorkomt.

Wat u moet weten over multitenant-toepassingen

  • Een toepassingsobject is een wereldwijd uniek exemplaar van de toepassing.

  • Wanneer een toepassing is geregistreerd in Microsoft Entra, worden een toepassingsobject en een service-principal-object automatisch gemaakt in de tenant.

  • Er wordt een service-principal-object gemaakt in elke tenant die gebruikmaakt van de toepassing en verwijst naar het toepassingsobject. Een toepassingsobject heeft een een-op-veel-relatie met het bijbehorende service-principal-object.

  • Het toepassingsobject is de globale weergave van uw toepassing en wordt gebruikt in alle tenants. Het service-principal-object is de lokale weergave die wordt gebruikt in een specifieke tenant.

  • Er moet een service-principal-object worden gemaakt in elke tenant waarin de toepassing wordt gebruikt, zodat deze een identiteit kan instellen voor toegang tot resources die de tenant beveiligt. Een toepassing met één tenant heeft slechts één service-principal-object in de eigen tenant. Dit service-principal-object wordt gemaakt en toegestaan voor gebruik tijdens de registratie van de toepassing. Een toepassing met meerdere tenants heeft ook een service-principal-object dat in elke tenant is gemaakt en een gebruiker van die tenant heeft toestemming gegeven voor het gebruik ervan.

  • Voor toegang tot resources die worden beveiligd door een Microsoft Entra-tenant, moet een beveiligingsprincipaal de entiteit vertegenwoordigen die toegang vereist.

  • Wanneer een toepassing toegang krijgt tot resources in een tenant na registratie of toestemming, wordt er een service-principal-object gemaakt. Deze architectuur wordt geïmplementeerd met de toestemmingsstroom.

Hoe stuurt de provider de klant een bericht?

In het ideale voorbeeld kan de provider een beheerde identiteit toewijzen aan de Azure-rekenresource die verantwoordelijk is voor het verzenden van berichten naar de wachtrij van een klant. De tenant van de klant is geconfigureerd om beheerde identiteiten van de tenant van de provider te vertrouwen. Een echte federatie tussen twee Microsoft Entra-tenants, waardoor het delen van identiteiten van de ene tenant naar de andere mogelijk is, is momenteel niet mogelijk. De provider moet zich dus verifiëren met behulp van een identiteit die de klant herkent. De provider moet zich verifiëren bij de Microsoft Entra-tenant van de klant als een service-principal waarover de klant weet.

Het is raadzaam dat de provider een multitenant-toepassing in een eigen tenant registreert en vervolgens elke klant een gekoppelde service-principal inricht in hun tenant. De provider kan vervolgens worden geverifieerd bij de tenant van de klant en de door de klant gehoste API's met behulp van deze service-principal. De provider hoeft in deze benadering nooit een clientgeheim te delen. Referentiebeheer is de enige verantwoordelijkheid van de provider.

Hoe stuurt de klant de provider bericht?

Het is raadzaam dat de klant een wachtrij maakt of host van waaruit de provider kan lezen. De klant schrijft een bericht in de wachtrij. De provider peilt herhaaldelijk elke klantwachtrij voor berichten met behulp van een service-principal-object. Het nadeel van deze aanpak is dat er pollinglatentie wordt geïntroduceerd wanneer de provider een bericht ontvangt. Code moet ook vaker worden uitgevoerd in de provider omdat deze moet worden geactiveerd en pollinglogica moet uitvoeren in plaats van te wachten tot een gebeurtenis deze activeert. Referentiebeheer blijft echter de enige verantwoordelijkheid van de provider, die de beveiliging versterkt.

Een andere mogelijke oplossing is om de provider een wachtrij te laten maken of hosten voor elk van de klanten. Elke klant maakt een eigen multitenant-toepassing en vraagt aan dat de provider deze inricht in de tenant als een service-principal-object. De klant gebruikt dit service-principal-object vervolgens om berichten te verzenden naar een klantspecifieke wachtrij aan de providerzijde. Referentiebeheer blijft de enige verantwoordelijkheid van de klant. Een nadeel van deze aanpak is dat de provider service-principals moet inrichten die zijn gekoppeld aan klanttoepassingen in de tenant. Dit proces is handmatig en providers willen waarschijnlijk niet dat handmatige stappen deel uitmaken van de stroom voor het onboarden van een nieuwe klant.

Voorbeeldcode instellen

De volgende stappen begeleiden u bij het instellen van communicatie tussen meerdere tenants tussen een provider en een klant.

Provider instellen

De providerinstallatie omvat de stappen voor het genereren en inrichten van een service-principal voor meerdere tenants en de stappen voor het inrichten van de tenant van de klant.

  1. Maak een door HTTP geactiveerde functie-app om een bericht te verzenden dat moet worden geschreven naar de Service Bus-opdrachtwachtrij van de klant binnen de tenant van de klant.

  2. Maak een door tijd geactiveerde functie-app om periodiek een statuswachtrij te controleren binnen de Service Bus van de klant binnen de tenant van de klant.

Een multitenant-toepassing maken binnen de tenant van de provider

Maak eerst een multitenant-toepassing in de tenant van de provider en richt die identiteit in de tenant van de klant in. In dit scenario is de identiteit een service-principal. De architectuur eerder in dit artikel laat zien hoe u een service-principal van de tenant van de provider instelt en inricht in de tenant van de klant. In de architectuur wordt ook beschreven hoe u kunt inrichten met meerdere Microsoft Entra-tenants.

  1. Kies de optie voor meerdere tenants.

  2. Voeg de volgende website toe als de omleidings-URI: https://entra.microsoft.com. U kunt deze URI aanpassen aan de behoeften van uw bedrijf.

  3. Registreer en noteer de waarde van de toepassings-id (client).

Een nieuw clientgeheim maken

  1. Nadat u de multitenant-toepassing hebt gemaakt, maakt u een clientgeheim voor deze service-principal.

  2. Sla het gegenereerde geheim op een veilige locatie op. Het geheim en de client-id zijn uw clientreferenties die nodig zijn voor het uitwisselen van de code, in de autorisatiecodestroom en voor een id-token in de volgende stap.

Azure Functions - HTTP-geactiveerd

Gebruik de HTTP-functie om de implementatie vanuit de tenant van de provider te starten door een bericht te verzenden naar de Service Bus-implementatiewachtrij van de klant. We hebben de door HTTP geactiveerde functie gekozen als leveringsmethode om dit proof-of-concept te starten. De service-principal die u eerder hebt gegenereerd, fungeert als de referentie voor toegang tot de tenant van de klant en schrijft naar een specifieke wachtrij in Service Bus. U moet ook de installatie van de klant voltooien om deze stap goed te laten werken.

Azure Functions - Timer geactiveerd

Gebruik de door timer geactiveerde functie om de implementatiestatuswachtrij te peilen vanuit de tenant van de klant. We peilen elke 10 seconden de implementatiestatuswachtrij voor demodoeleinden in dit proof-of-concept. Met deze methode hoeft de klant geen service-principal te hebben voor toegang tot de tenant van de provider.

Installatie van de klant

  1. Richt de service-principal in door de opgegeven URL te wijzigen en te gebruiken.

  2. Beperk de providerservice-principal om de juiste RBAC-besturingselementen te gebruiken.

  3. Maak een door Service Bus geactiveerde functie om een bericht uit een Service Bus-berichtenwachtrij te lezen en een bericht in een andere wachtrij te plaatsen. Voor demodoeleinden is deze stroom optimaal om de functionaliteit te testen.

  4. Maak een door het systeem toegewezen beheerde identiteit voor de door Service Bus geactiveerde functie.

  5. Wijs het service bus-bereik van de door het systeem toegewezen beheerde identiteit toe.

De service-principal inrichten van de tenant van de provider naar de tenant van de klant

  1. Ga naar de volgende URL nadat u de client_id querytekenreeksparameter hebt vervangen door uw eigen client-id: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    U kunt de service-principal ook inrichten in een andere Microsoft Entra-tenant met een microsoft Graph API-aanroep van een beheerder, een Azure PowerShell-opdracht of een Azure CLI-opdracht.

  2. Meld u aan met een account van de tenant van de klant.

  3. Selecteer Accepteren in het toestemmingsscherm om de toepassing van de provider in te richten in de tenant van de klant. De URL wordt uiteindelijk omgeleid naar microsoft.com, wat nog steeds het gewenste effect heeft van het inrichten van de identiteit in de tenant van de klant.

  4. Controleer de identiteit binnen de Microsoft Entra-tenant van de klant door naar Bedrijfstoepassingen te gaan om de zojuist ingerichte service-principal te zien.

RBAC instellen voor de ingerichte service-principal

Beperk de providerservice-principal van de instelling van de service-principal van de provider om de rollen 'Service Bus-gegevenseigenaar' in de Service Bus te hebben. Deze service-principal wordt gebruikt bij het schrijven naar een wachtrij met een door HTTP geactiveerde functie en het lezen van een wachtrij vanuit een door een timer geactiveerde functie. Zorg ervoor dat u de rol Azure Service Bus-gegevenseigenaar toevoegt aan de service-principal.

Azure Functions - Service Bus-trigger

Volg de stappen in de zelfstudie op basis van identiteiten om de functietrigger uit de Service Bus-wachtrij te definiëren en om te leren hoe u een beheerde identiteit instelt. Deze richtlijnen helpen u bij het activeren van de functie-app uit de Service Bus-wachtrij wanneer een bericht wordt toegevoegd aan de wachtrij. U gebruikt ook de beheerde identiteit wanneer u een bericht in een andere wachtrij plaatst. Voor demodoeleinden gebruiken we dezelfde functie om het bericht door te pushen.

Selecteer toegangsbeheer (IAM) in uw zojuist gemaakte Service Bus-naamruimte. U kunt bekijken en configureren wie toegang heeft tot de resource in het besturingsvlak.

De functie-app toegang verlenen tot de Service Bus-naamruimte met behulp van beheerde identiteiten

  1. Zorg ervoor dat u de rol Azure Service Bus-gegevensontvanger toevoegt aan de beheerde identiteit.

  2. Kies in de beheerde identiteitskiezer de functie-app in de categorie Door het systeem toegewezen beheerde identiteit . De labelfunctie-app heeft mogelijk een getal tussen haakjes ernaast. Dit getal geeft aan hoeveel apps met door het systeem toegewezen identiteiten zich in het abonnement bevinden.

Verbinding maken met Service Bus in uw functie-app

  1. Zoek in de portal naar uw functie-app of ga naar de app op de pagina Functie-app .

  2. Selecteer + Nieuw in de toepassingsinstellingen om een nieuwe toepassingsinstelling in de tabel te maken. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Levenscyclusbeheer voor clientgeheim van service-principal

Als u geheimen introduceert in uw architectuur voor meerdere tenants, moet u de levenscyclus van de gegenereerde clientgeheimen beheren. Zie aanbevolen procedures voor geheimenbeheer voor meer informatie over het veilig opslaan, roteren en bewaken van clientgeheimen.

Lokale instellingen

Elke submap bevat een stubbed versie van de local.settings.json bestanden, die kan worden gewijzigd om de Azure-functies lokaal uit te voeren. Werk de toepassingsinstellingen bij om instellingen in Azure te configureren.

Met DefaultAzureCredential de opdracht worden meerdere instellingen opgesomd voordat de Azure CLI-referentie wordt bereikt. Om verwarring te voorkomen, raden we u aan om de az login -t <tenant ID> opdracht uit te voeren om de juiste referenties te selecteren wanneer u lokale functies ontwikkelt.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Volgende stappen