Dela via

Implementera kommunikation mellan klientorganisationer med hjälp av program för flera klientorganisationer

  • Artikel

Den här guiden innehåller en lösning för att uppnå dubbelriktad och säker kommunikation mellan tjänster som finns i Azure-prenumerationer som olika Microsoft Entra-klienter hanterar.

Det kan vara svårt att skydda kommunikation med flera klientorganisationer i Azure på grund av begränsningar som är inbyggda i många tjänster. Du kan eliminera behovet av att hantera autentiseringsuppgifter direkt med hjälp av Azure-hanterade identiteter för att hämta token från Microsoft Entra-ID. Azure-hanterade identiteter fungerar dock inte över klientorganisationens gränser, och det vanliga alternativet är att använda delade hemligheter, till exempel url:er för signatur för delad åtkomst. Kom ihåg att om du använder delade hemligheter måste du distribuera och rotera hemligheterna över Microsoft Entra-klientgränserna på ett säkert sätt.

Ett alternativ som undviker den här kostnaden är att skapa ett program med flera klientorganisationer som representerar arbetsbelastningens identitet. Genom en medgivandeprocess kan du göra den här arbetsbelastningsidentiteten känd för en extern klientorganisation och slutligen tillåta den att autentisera tjänster i den externa klientorganisationen.

Den här artikeln visar ett exempel på en implementering av det här mönstret som använder exempelkod.

Det här mönstret kan återanvändas för alla scenarier med flera klienter som har olika tjänster som behöver kommunicera över Microsoft Entra-klientgränserna.

Arkitektur

Ett diagram över kommunikationsarkitekturen mellan klientorganisationer.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Arbetsflöde

Följande arbetsflöde motsvarar föregående diagram:

  1. En administratör på providersidan skapar en programregistrering med flera klienter och konfigurerar en klienthemlighet för den.

  2. En administratör på kundsidan etablerar ett huvudnamn för tjänsten i klientorganisationen. Tjänstens huvudnamn baseras på det program för flera klientorganisationer som providern skapade. Du kan göra det här steget på flera olika sätt. I exemplet valde vi att skapa en URL som ska tillhandahållas kundens klientorganisationsadministratör, men du kan använda Microsoft Graph-API:et i stället.

  3. Kunden tillämpar rollbaserade åtkomstkontrollroller (RBAC) på det nya tjänstens huvudnamn så att det har behörighet att komma åt Azure Service Bus.

  4. Providerns funktionsapp använder klient-ID:t och klienthemligheten för programregistreringen för att skicka ett autentiserat meddelande till kundens Service Bus-kö.

  5. Kundens funktionsapp använder en hanterad identitet för att läsa leverantörens meddelande från kön via en Service Bus-utlösare.

  6. När meddelandet har fåtts utför kundens funktionsapp vanligtvis en del arbete innan ett statusmeddelande skickas tillbaka till providern. I det här fallet skickar funktionsappen i demosyfte omedelbart ett statusmeddelande till providern i en separat kö i samma Service Bus.

  7. Den här funktionsappen läser från statuskön från kundens klient via en timer som Azure Functions utlöser.

Information om scenario

En leverantör har flera kunder. Leverantören och varje kund har sina egna enskilda Microsoft Entra-ID-klientorganisationer och Azure-resurser. Leverantören och varje kund behöver en säker, dubbelriktad kommunikationsmetod så att de kan utbyta meddelanden via Service Bus-köer. Lösningen bör ha en övertygande identitetshistoria som undviker att införa onödiga autentiseringsuppgifter eller hemligheter.

Vad du bör veta om program med flera klienter

  • Ett programobjekt är en globalt unik instans av programmet.

  • När ett program registreras i Microsoft Entra skapas automatiskt ett programobjekt och ett objekt för tjänstens huvudnamn i klientorganisationen.

  • Ett objekt för tjänstens huvudnamn skapas i varje klientorganisation som använder programmet och refererar till programobjektet. Ett programobjekt har en en-till-många-relation med motsvarande objekt för tjänstens huvudnamn.

  • Programobjektet är den globala representationen av ditt program och används för alla klienter. Objektet för tjänstens huvudnamn är den lokala representation som används i en specifik klientorganisation.

  • Ett objekt för tjänstens huvudnamn måste skapas i varje klientorganisation där programmet används så att det kan upprätta en identitet för åtkomst till resurser som klientorganisationen skyddar. Ett program med en klientorganisation har bara ett huvudnamnsobjekt för tjänsten i sin hemklientorganisation. Det här objektet för tjänstens huvudnamn skapas och tillåts för användning under programregistreringen. Ett program med flera klienter har också ett objekt för tjänstens huvudnamn som skapas i varje klientorganisation och en användare från den klientorganisationen har samtyckt till dess användning.

  • För att få åtkomst till resurser som skyddas av en Microsoft Entra-klient måste ett säkerhetsobjekt representera den entitet som kräver åtkomst.

  • När ett program får behörighet att komma åt resurser i en klientorganisation vid registrering eller medgivande skapas ett objekt för tjänstens huvudnamn. Den här arkitekturen implementeras med medgivandeflödet.

Hur gör providern för att meddela kunden?

Helst kan providern tilldela en hanterad identitet till Den Azure-beräkningsresurs som ansvarar för att skicka meddelanden till en kunds kö. Kundens klientorganisation är konfigurerad för att lita på hanterade identiteter från leverantörens klientorganisation. En sann federation mellan två Microsoft Entra-klienter, som i princip skulle tillåta "delning" av identiteter från en klientorganisation till en annan, är dock för närvarande inte möjlig. Leverantören måste därför autentisera med hjälp av en identitet som kunden känner igen. Leverantören måste autentisera till kundens Microsoft Entra-klientorganisation som ett tjänsthuvudnamn som kunden känner till.

Vi rekommenderar att providern registrerar ett program med flera klienter i sin egen klientorganisation och sedan har varje kund etablerat ett associerat tjänsthuvudnamn i sin klientorganisation. Providern kan sedan autentisera till kundens klientorganisation och de kundvärdade API:erna med hjälp av tjänstens huvudnamn. Providern behöver aldrig dela en klienthemlighet i den här metoden. Hantering av autentiseringsuppgifter är leverantörens enda ansvar.

Hur gör kunden för att meddela leverantören?

Vi rekommenderar att kunden skapar eller är värd för en kö som providern kan läsa från. Kunden skriver ett meddelande i kön. Providern avsöker upprepade gånger varje kundkö efter meddelanden med hjälp av ett objekt för tjänstens huvudnamn. Nackdelen med den här metoden är att den introducerar svarstid för avsökning när providern tar emot ett meddelande. Koden måste också köras oftare i providern eftersom den måste aktiveras och utföra avsökningslogik i stället för att vänta på att en händelse ska utlösa den. Hantering av autentiseringsuppgifter är dock fortfarande leverantörens enda ansvar, vilket ökar säkerheten.

En annan möjlig lösning är att låta leverantören skapa eller vara värd för en kö för var och en av sina kunder. Varje kund skapar ett eget program för flera klienter och begär att providern etablerar det i sin klientorganisation som ett objekt för tjänstens huvudnamn. Kunden använder sedan det här objektet för tjänstens huvudnamn för att skicka meddelanden till en kundspecifik kö på providersidan. Hantering av autentiseringsuppgifter förblir kundens enda ansvar. En nackdel med den här metoden är att providern måste etablera tjänstens huvudnamn som är associerade med kundprogram i klientorganisationen. Den här processen är manuell och leverantörer vill förmodligen inte att manuella steg ska ingå i flödet för registrering av en ny kund.

Exempel på kodkonfiguration

Följande steg vägleder dig genom processen för att konfigurera kommunikation mellan klientorganisationer mellan en leverantör och kund.

Providerkonfiguration

Providerkonfigurationen innehåller stegen för att generera och etablera ett huvudnamn för programtjänsten för flera klienter och stegen för att etablera kundklientorganisationen.

  1. Skapa en HTTP-utlöst funktionsapp för att skicka ett meddelande för att skriva till kundens Service Bus-kommandokö i kundens klientorganisation.

  2. Skapa en tidsutlöst funktionsapp för att regelbundet kontrollera en statuskö i kundens Service Bus i kundklientorganisationen.

Skapa ett program för flera klienter i providerns klientorganisation

Skapa först ett program med flera klienter i providerns klientorganisation och etablera identiteten i kundens klientorganisation. I det här scenariot är identiteten tjänstens huvudnamn. Arkitekturen tidigare i den här artikeln visar hur du konfigurerar och etablerar ett huvudnamn för tjänsten från leverantörens klientorganisation till kundens klientorganisation. Arkitekturen beskriver också hur du etablerar med flera Microsoft Entra-klienter.

  1. Välj alternativet för flera klientorganisationer.

  2. Lägg till följande webbplats som omdirigerings-URI: https://entra.microsoft.com. Du kan ändra den här URI:n så att den passar dina affärsbehov.

  3. Registrera och anteckna programmets (klient)-ID-värdet.

Skapa en ny klienthemlighet

  1. När du har skapat programmet för flera klienter skapar du en klienthemlighet för tjänstens huvudnamn.

  2. Spara den genererade hemligheten på en säker plats. Hemligheten och klient-ID:t är dina klientautentiseringsuppgifter som krävs för att utbyta koden, i auktoriseringskodflödet och för en ID-token i nästa steg.

Azure Functions – HTTP-utlöst

Använd HTTP-funktionen för att starta distributionen från providerns klientorganisation genom att skicka ett meddelande till kundens Service Bus-distributionskö. Vi valde den HTTP-utlösta funktionen som leveransmetod för att starta det här koncepttestet. Tjänstens huvudnamn som du genererade tidigare fungerar som autentiseringsuppgifter för att få åtkomst till kundklientorganisationen och skriva till en specifik kö i Service Bus. Du måste också slutföra kundkonfigurationen för att det här steget ska fungera korrekt.

Azure Functions – Timerutlöst

Använd den timerutlösta funktionen för att avsöka distributionsstatuskön inifrån kundens klientorganisation. Vi avsöker distributionsstatuskön var 10:e sekund i demosyfte i det här koncepttestet. Den här metoden tar bort behovet av att kunden har ett huvudnamn för tjänsten för att få åtkomst till leverantörens klientorganisation.

Kundkonfiguration

  1. Etablera tjänstens huvudnamn genom att ändra och använda den angivna URL:en.

  2. Omfång för providertjänstens huvudnamn för att använda lämpliga RBAC-kontroller.

  3. Skapa en Service Bus-utlöst funktion för att läsa ett meddelande från en Service Bus-meddelandekö och placera ett meddelande i en annan kö. I demosyfte är det här flödet optimalt för att testa funktionerna.

  4. Skapa en systemtilldelad hanterad identitet för den Service Bus-utlösta funktionen.

  5. Tilldela den systemtilldelade hanterade identiteten Service Bus-omfånget.

Etablera tjänstens huvudnamn från leverantörens klientorganisation till kundens klientorganisation

  1. Besök följande URL när du har ersatt frågesträngsparametern client_id med ditt eget klient-ID: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    Du kan också etablera tjänstens huvudnamn i en annan Microsoft Entra-klientorganisation med ett Microsoft Graph API-administratörsanrop, ett Azure PowerShell-kommando eller ett Azure CLI-kommando.

  2. Logga in med ett konto från kundens klientorganisation.

  3. På medgivandeskärmen väljer du Acceptera för att etablera providerns program i kundklientorganisationen. URL:en omdirigeras så småningom till microsoft.com, vilket fortfarande har den önskade effekten att etablera identiteten i kundklientorganisationen.

  4. Verifiera identiteten i kundens Microsoft Entra-klient genom att gå till Företagsprogram för att se det nyligen etablerade tjänstens huvudnamn.

Konfigurera RBAC för det etablerade tjänstens huvudnamn

Omfånget för providertjänstens huvudnamn från konfigurationen av providertjänstens huvudnamn för att ha "Service Bus Data Owner"-roller på Service Bus. Tjänstens huvudnamn används både när du skriver till en kö med en HTTP-utlöst funktion och läser från en kö från en timerutlöst funktion. Se till att du lägger till rollen "Azure Service Bus-dataägare" i tjänstens huvudnamn.

Azure Functions – Service Bus-utlösare

Följ stegen i självstudien identitetsbaserade funktioner för att definiera funktionsutlösaren från Service Bus-kön och lära dig hur du konfigurerar en hanterad identitet. Den här vägledningen hjälper dig att utlösa funktionsappen från Service Bus-kön när ett meddelande läggs till i kön. Du använder också den hanterade identiteten när du placerar ett meddelande i en annan kö. I demosyfte använder vi samma funktion för att skicka meddelandet.

I det nyligen skapade Service Bus-namnområdet väljer du Åtkomstkontroll (IAM).. Du kan visa och konfigurera vem som har åtkomst till resursen i kontrollplanet.

Ge funktionsappen åtkomst till Service Bus-namnområdet med hjälp av hanterade identiteter

  1. Se till att du lägger till rollen "Azure Service Bus Data Receiver" i den hanterade identiteten.

  2. I väljaren för hanterad identitet väljer du Funktionsapp i kategorin Systemtilldelad hanterad identitet . Etiketten Funktionsapp kan ha ett tal inom parenteser bredvid sig. Det talet anger hur många appar som har systemtilldelade identiteter i prenumerationen.

Ansluta till Service Bus i funktionsappen

  1. I portalen söker du efter din funktionsapp eller går till den på sidan Funktionsapp .

  2. I Programinställningar väljer du + Ny för att skapa en ny programinställning i tabellen. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Hantering av klienthemlighetslivscykel för tjänstens huvudnamn

Om du introducerar hemligheter i arkitekturen mellan klientorganisationer måste du hantera livscykeln för de genererade klienthemligheterna. Se Metodtips för hantering av hemligheter för att lära dig hur du lagrar, roterar och övervakar klienthemligheter på ett säkert sätt.

Lokala inställningar

Varje underkatalog innehåller en stubbversion av local.settings.json filerna, som kan ändras för att köra Azure-funktionerna lokalt. Om du vill konfigurera inställningar i Azure uppdaterar du programinställningarna.

Kommandot DefaultAzureCredential räknar upp flera inställningar innan det når Azure CLI-autentiseringsuppgifterna. För att undvika förvirring rekommenderar vi att du kör az login -t <tenant ID> kommandot för att välja rätt autentiseringsuppgifter när du utvecklar lokala funktioner.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Nästa steg