Dela via


Överväganden för att använda Azure Active Directory B2C i en arkitektur med flera klienter

Azure Active Directory (Azure AD) B2C tillhandahåller företags-till-konsument-identitet som en tjänst. Användaridentitet är vanligtvis en av de viktigaste övervägandena när du utformar ett program med flera klienter. Din identitetslösning fungerar som gatekeeper för ditt program, vilket säkerställer att dina klienter håller sig inom de gränser som du definierar för dem. I den här artikeln beskrivs överväganden och metoder för att använda Azure AD B2C i en lösning med flera klienter.

En av de vanligaste orsakerna till att använda Azure AD B2C är att aktivera identitetsfederation för ett program. Identitetsfederation är processen att upprätta förtroende mellan två identitetsprovidrar så att användarna kan logga in med ett befintligt konto. Om du använder Azure AD B2C kan du implementera identitetsfederation så att användarna kan logga in med hjälp av sina sociala konton eller företagskonton. Om du använder federation behöver användarna inte skapa ett separat lokalt konto som är specifikt för ditt program.

Om du är nybörjare på det här avsnittet rekommenderar vi att du granskar följande resurser:

Kommentar

I den här artikeln beskrivs två begrepp med liknande namn: programklientorganisationer och Azure AD B2C-klienter.

Termen programklient används för att referera till dina klienter, vilket kan vara dina kunder eller användargrupper.

Azure AD B2C använder också klientkonceptet som referens till enskilda kataloger, och termen multitenancy används för att referera till interaktioner mellan flera Azure AD B2C-klienter. Även om termerna är desamma är begreppen inte det. När en Azure AD B2C-klientorganisation refereras till i den här artikeln används den fullständiga termen Azure AD B2C-klientorganisation .

Identitet i lösningar för flera klientorganisationer

I lösningar med flera klientorganisationer är det vanligt att kombinera flera identitetstjänster för att uppnå olika kravuppsättningar. Många lösningar har två olika uppsättningar identiteter:

  • Kundidentiteter, som gäller för slutanvändarkonton. De styr hur klientorganisationens användare får åtkomst till dina program.
  • Interna identiteter som hanterar hur ditt eget team hanterar din lösning.

Dessa olika identitetstyper använder vanligtvis också distinkta identitetstjänster. Azure AD B2C är en kundidentitets- och åtkomsthanteringstjänst (CIAM) som klientorganisationens användare använder för att få åtkomst till lösningen. Microsoft Entra ID är en IAM-tjänst (identitets- och åtkomsthantering) som du och ditt team använder för att hantera dina Azure-resurser och för att kontrollera ditt program.

Överväg ett exempel på en lösning för flera klientorganisationer som skapats av Fabrikam. Lösningen använder en kombination av de två tjänsterna för att uppfylla Fabrikams krav:

  • Fabrikam implementerar Azure AD B2C så att företagets kunder (klienter) kan logga in på program.
  • Anställda i Fabrikam använder organisationens Microsoft Entra-katalog för att få åtkomst till sin lösning i hanterings- och administrationssyfte. De använder samma identiteter som de använder för att komma åt andra Fabrikam-resurser, till exempel Microsoft kancelarija.

Följande diagram illustrerar det här exemplet:

Diagram som visar två program med två metoder för att logga in.

Isoleringsmodeller

När du använder Azure AD B2C måste du bestämma hur du ska isolera dina användarkonton mellan olika programklientorganisationer.

Du måste överväga frågor som:

  • Behöver du federera inloggningar till kundens identitetsprovidrar? Behöver du till exempel aktivera federation till SAML, Microsoft Entra-ID, leverantörer av social inloggning eller andra källor?
  • Har du eller dina klienter krav på datahemvist?
  • Behöver användaren komma åt fler än en programklientorganisation?
  • Behöver du komplexa behörigheter och/eller rollbaserad åtkomstkontroll (RBAC)?
  • Vem loggar in på ditt program? Olika användarkategorier kallas ofta användarpersoner.

I följande tabell sammanfattas skillnaderna mellan de viktigaste innehavarmodellerna för Azure AD B2C:

Att tänka på Delad Azure AD B2C-klientorganisation Vertikalt partitionerad Azure AD B2C-klientorganisation En Azure AD B2C-klientorganisation per programklientorganisation
Dataisolering Data från varje programklient lagras i en enda Azure AD B2C-klient men kan endast nås av administratörer Data från varje programklientorganisation distribueras mellan flera Azure AD B2C-klienter men kan endast nås av administratörer Data från varje programklient lagras i en dedikerad Azure AD B2C-klient men kan endast nås av administratörer
Distributionskomplexitet Låg Medelhög till hög, beroende på partitioneringsstrategin Mycket högt
Begränsningar att tänka på Begäranden per Azure AD B2C-klientorganisation, begäranden per klient-IP-adress En kombination av begäranden, antalet Azure AD B2C-klienter per prenumeration och antalet kataloger för en enskild användare, beroende på din partitioneringsstrategi Antal Azure AD B2C-klienter per prenumeration, maximalt antal kataloger för en enskild användare
Driftkomplexitet Låg Medelhög till hög, beroende på partitioneringsstrategin Mycket högt
Antal Azure AD B2C-klienter som krävs En Mellan en och n, beroende på partitioneringsstrategin n, där n är antalet programklientorganisationer
Exempelscenario Du skapar ett SaaS-erbjudande för konsumenter som har låga eller inga krav på datahemvist, till exempel en musik- eller videoströmningstjänst. Du skapar ett SaaS-erbjudande, till exempel en redovisnings- och arkivhandlingsapplikation för företag. Du måste ha stöd för krav på datahemvist eller ett stort antal anpassade federerade identitetsprovidrar. Du skapar ett SaaS-erbjudande, till exempel en myndighetsregisterföringsapplikation för företag. Dina kunder kräver en hög grad av dataisolering från andra programklientorganisationer.

Delad Azure AD B2C-klientorganisation

Det är vanligtvis enklast att hantera en enda delad Azure AD B2C-klientorganisation om dina krav tillåter det. Du behöver bara underhålla en klientorganisation på lång sikt, och det här alternativet skapar den lägsta kostnaden.

Kommentar

Vi rekommenderar att du använder en delad Azure AD B2C-klient för de flesta scenarier.

Du bör överväga en delad Azure AD B2C-klient när:

  • Du har inte krav på datahemvist eller strikta krav på dataisolering.
  • Dina programkrav ligger inom gränserna för Azure AD B2C-tjänsten.
  • Om du har federerade identitetsprovidrar kan du använda Home Realm Discovery för att automatiskt välja en provider för en användare att logga in med, eller så är det acceptabelt för användare att manuellt välja en från en lista.
  • Du har en enhetlig inloggningsupplevelse för alla programklientorganisationer.
  • Slutanvändarna måste ha åtkomst till fler än en programklientorganisation med hjälp av ett enda konto.

Det här diagrammet illustrerar den delade Azure AD B2C-klientmodellen:

Diagram som visar tre program som ansluter till en enda delad Azure AD B2C-klientorganisation.

Vertikalt partitionerade Azure AD B2C-klienter

Etableringen av vertikalt partitionerade Azure AD B2C-klienter är en strategi som är utformad för att, när det är möjligt, minimera antalet Azure AD B2C-klienter som behövs. Det är en medelväg mellan de andra innehavarmodellerna. Vertikal partitionering ger större flexibilitet i anpassningen för specifika klienter när det behövs. Det skapar dock inte de driftkostnader som är associerade med etablering av en Azure AD B2C-klientorganisation för varje programklientorganisation.

Distributions- och underhållskraven för den här innehavarmodellen är högre än för en enda Azure AD B2C-klientorganisation, men de är lägre än om du använder en Azure AD B2C-klientorganisation per programklientorganisation. Du behöver fortfarande utforma och implementera en distributions- och underhållsstrategi för flera klienter i din miljö.

Vertikal partitionering liknar datapartitioneringsmönstret. Om du vill partitionera dina Azure AD B2C-klientorganisationer lodrätt måste du organisera dina programklientorganisationer i logiska grupper. Den här kategoriseringen av klienter kallas ofta för en partitioneringsstrategi. Partitioneringsstrategin bör baseras på en vanlig, stabil faktor för programklientorganisationen, till exempel region, storlek eller en programklients anpassade krav. Om ditt mål till exempel är att lösa dina krav på datahemvist kan du välja att distribuera en Azure AD B2C-klient för varje region som är värd för programklientorganisationer. Eller om du grupperar efter storlek kan du välja att hitta de flesta av dina programklienternas identiteter på en enda Azure AD B2C-klientorganisation, men hitta de största programklienterna på sina egna dedikerade Azure AD B2C-klientorganisationer.

Viktigt!

Undvik att basera partitioneringsstrategin på faktorer som kan ändras över tid, eftersom det är svårt att flytta användare mellan Azure AD B2C-klienter. Om du till exempel skapar ett SaaS-erbjudande som har flera SKU:er eller produktnivåer bör du inte partitionera användarna baserat på den SKU de väljer, eftersom SKU:n kan ändras om kunden uppgraderar sin produkt.

Du bör överväga att etablera dina Azure AD B2C-klienter med hjälp av en vertikalt partitionerad strategi om:

  • Du har krav på datahemvist, eller så måste du separera användarna efter geografi.
  • Du har ett stort antal federerade identitetsprovidrar och kan inte använda Home Realm Discovery för att automatiskt välja en för en användare att logga in med.
  • Ditt program är, eller kan vara, medvetet om flera klientorganisationer och vet vilken Azure AD B2C-klientorganisation som användarna behöver logga in på.
  • Du tror att dina större programklienter kan nå Gränserna för Azure AD B2C.
  • Du har en långsiktig strategi för att distribuera och underhålla ett medelstort till stort antal Azure AD B2C-klienter.
  • Du har en strategi för att partitionera programklientorganisationer mellan en eller flera Azure-prenumerationer för att fungera inom gränsen för antalet Azure AD B2C-klienter som kan distribueras i en Azure-prenumeration.

Följande diagram illustrerar den lodrätt partitionerade Azure AD B2C-klientmodellen:

Diagram som visar tre program. Två är anslutna till en delad Azure AD B2C-klientorganisation. Den tredje är ansluten till en egen Azure AD B2C-klientorganisation.

En Azure AD B2C-klientorganisation per programklientorganisation

Om du etablerar en Azure AD B2C-klientorganisation för varje programklient kan du anpassa många faktorer för varje klientorganisation. Den här metoden skapar dock en betydande ökning av omkostnaderna. Du måste utveckla en distributions- och underhållsstrategi för ett potentiellt stort antal Azure AD B2C-klienter.

Du måste också vara medveten om tjänstbegränsningar. Med Azure-prenumerationer kan du bara distribuera ett begränsat antal Azure AD B2C-klienter. Om du behöver distribuera mer än vad gränsen tillåter måste du överväga en lämplig prenumerationsdesign så att du kan balansera dina Azure AD B2C-klienter mellan flera prenumerationer. Det finns även andra Microsoft Entra-gränser som gäller, till exempel antalet kataloger som en enskild användare kan skapa och antalet kataloger som en användare kan tillhöra.

Varning

På grund av komplexiteten i den här metoden rekommenderar vi starkt att du överväger de andra isoleringsmodellerna först. Det här alternativet ingår här för fullständighetens skull, men det är inte rätt metod för de flesta användningsfall.

En vanlig missuppfattning är att anta att om du använder mönstret Distributionsstämplar måste du inkludera identitetstjänster i varje stämpel. Det är inte nödvändigtvis sant, och du kan ofta använda en annan isoleringsmodell i stället. Utöva noggrannhet och ha en tydlig affärsmotivering om du använder den här isoleringsmodellen. Distributions- och underhållskostnaderna är betydande.

Du bör överväga att etablera en Azure AD B2C-klient för varje programklientorganisation endast om:

  • Du har strikta krav på dataisolering för programklientorganisationer.
  • Du har en långsiktig strategi för att distribuera och underhålla ett stort antal Azure AD B2C-klienter.
  • Du har en strategi för att partitionera dina kunder mellan en eller flera Azure-prenumerationer för att uppfylla gränsen för Azure AD B2C per prenumerationsklient.
  • Ditt program är, eller kan vara, medvetet om flera klientorganisationer och vet vilken Azure AD B2C-klientorganisation som användarna behöver logga in på.
  • Du måste utföra anpassad konfiguration för varje programklientorganisation.
  • Slutanvändarna behöver inte komma åt fler än en programklientorganisation via samma inloggningskonto.

Följande diagram illustrerar användningen av en Azure AD B2C-klientorganisation per programklientorganisation:

Diagram som visar tre program som var och en ansluter till sin egen Azure AD B2C-klientorganisation.

Identitetsfederation

Du måste konfigurera varje federerad identitetsprovider, antingen via ett användarflöde eller i en anpassad princip. Under inloggningen väljer användarna vanligtvis vilken identitetsprovider de vill använda för att autentisera. Om du använder en isoleringsmodell för delad klientorganisation eller har ett stort antal federerade identitetsprovidrar kan du överväga att använda Home Realm Discovery för att automatiskt välja en identitetsprovider under inloggningen.

Du kan också använda identitetsfederation som ett verktyg för att hantera flera Azure AD B2C-klienter genom att federera Azure AD B2C-klientorganisationer med varandra. På så sätt kan ditt program lita på en enda Azure AD B2C-klientorganisation. Programmet behöver inte vara medvetet om att dina kunder är uppdelade mellan flera Azure AD B2C-klienter. Den här metoden används oftast i den vertikalt partitionerade isoleringsmodellen när användarna partitioneras efter region. Du måste ta hänsyn till några saker om du använder den här metoden. En översikt över den här metoden finns i Globala identitetslösningar.

Identifiering av startsfär

Home Realm Discovery är processen att automatiskt välja en federerad identitetsprovider för en användares inloggningshändelse. Om du automatiskt väljer användarens identitetsprovider behöver du inte uppmana användaren att välja en provider.

Home Realm Discovery är viktigt när du använder en delad Azure AD B2C-klientorganisation och även tillåter dina kunder att ta med sin egen federerade identitetsprovider. Du kanske vill undvika en design där en användare behöver välja från en lista över identitetsprovidrar. Detta ökar komplexiteten i inloggningsprocessen. Dessutom kan en användare av misstag välja en felaktig provider, vilket gör att inloggningsförsöket misslyckas.

Du kan konfigurera Identifiering av hemsfär på olika sätt. Den vanligaste metoden är att använda domänsuffixet för användarens e-postadress för att fastställa identitetsprovidern. Anta till exempel att Northwind Traders är kund hos Fabrikams lösning för flera klientorganisationer. E-postadressen user@northwindtraders.com innehåller domänsuffixet northwindtraders.com, som kan mappas till northwind Traders federerade identitetsprovider.

Mer information finns i Identifiering av hemsfär. Ett exempel på hur du implementerar den här metoden i Azure AD B2C finns i GitHub-lagringsplatsen Azure AD B2C-exempel.

Dataresidens

När du etablerar en Azure AD B2C-klientorganisation väljer du för datahemvist en region där klientorganisationen ska distribueras. Det här valet är viktigt eftersom det anger i vilken region dina kunddata finns när de är i vila. Om du har krav på datahemvist för en delmängd av dina kunder bör du överväga att använda den vertikalt partitionerade strategin.

Auktorisering

För en stark identitetslösning måste du överväga auktorisering utöver autentisering. Det finns flera sätt att använda Microsoft platforma za identitete för att skapa en auktoriseringsstrategi för ditt program. AppRoles-exemplet visar hur du använder Azure AD B2C-approller för att implementera auktorisering i ett program. Den beskriver också alternativa auktoriseringsmetoder.

Det finns ingen enskild metod för auktorisering, och du bör överväga behoven för ditt program och dina kunder när du bestämmer dig för en metod.

Underhåll

När du planerar en distribution med flera klientorganisationer av Azure AD B2C måste du tänka på det långsiktiga underhållet av dina Azure AD B2C-resurser. En Azure AD B2C-klientorganisation, som din organisations Microsoft Entra-klientorganisation, är en resurs som du behöver för att skapa, underhålla, driva och skydda. Även om följande lista inte är omfattande bör du överväga underhållet i områden som dessa:

  • Klientorganisationsstyrning. Vem underhåller Azure AD B2C-klientorganisationen? Vilka utökade roller behöver dessa administratörer? Hur konfigurerar du principer för villkorlig åtkomst och MFA för administratörerna? Hur övervakar du Azure AD B2C-klientorganisationen på lång sikt?
  • Konfiguration av användarresa. Hur distribuerar du ändringar till din Azure AD B2C-klientorganisation eller klientorganisation? Hur testar du ändringar i dina användarflöden eller anpassade principer innan du distribuerar dem?
  • Federerade identitetsprovidrar. Behöver du lägga till eller ta bort identitetsprovidrar över tid? Hur hanterar du det i stor skala om du låter var och en av dina kunder ta med sin egen identitetsprovider?
  • App-registreringar. Många Microsoft Entra-appregistreringar använder en klienthemlighet eller ett certifikat för autentisering. Hur roterar du dessa hemligheter eller certifikat när du behöver det?
  • Principnycklar. Hur roterar du principnycklarna när du behöver om du använder anpassade principer?
  • Användarautentiseringsuppgifter. Hur hanterar du användarinformation och autentiseringsuppgifter? Vad händer om en av dina användare är utelåst eller glömmer ett lösenord och kräver administratörs- eller kundtjänstintervention?

Kom ihåg att du måste överväga dessa frågor för varje Azure AD B2C-klient som du distribuerar. Du bör också överväga hur dina processer ändras när du har flera Azure AD B2C-klienter att underhålla. Det är till exempel enkelt att distribuera anpassade principändringar till en Azure AD B2C-klientorganisation manuellt, men det är tidskrävande och riskabelt att distribuera dem till fem klienter manuellt.

Distributioner och DevOps

En väldefinierad DevOps-process kan hjälpa dig att minimera de kostnader som krävs för att underhålla dina Azure AD B2C-klienter. Du bör implementera DevOps-metoder tidigt i utvecklingsprocessen. Helst bör du försöka automatisera alla eller de flesta av dina underhållsaktiviteter, inklusive att distribuera ändringar i dina anpassade principer eller användarflöden. Du bör också planera att skapa flera Azure AD B2C-klienter för att gradvis testa ändringar i lägre miljöer innan du distribuerar dem till dina produktionsklienter. Dina DevOps-pipelines kan utföra dessa underhållsaktiviteter. Du kan använda Microsoft Graph API för att programmatiskt hantera dina Azure AD B2C-klienter.

Mer information om automatiserade distributioner och hantering av Azure AD B2C finns i följande resurser.

Viktigt!

Vissa av de slutpunkter som används för att hantera Azure AD B2C programmatiskt är inte allmänt tillgängliga. API:er i betaversionen av Microsoft Graph kan ändras när som helst och omfattas av förhandsvillkor.

Jämföra Microsoft Entra B2B med Azure AD B2C

Microsoft Entra B2B-samarbete är en funktion i Microsoft Entra Externt ID som du kan använda för att bjuda in gästanvändare till din organisations Microsoft Entra-klientorganisation så att du kan samarbeta med dem. Vanligtvis använder du B2B-samarbete när du behöver bevilja en extern användare, till exempel en leverantör, åtkomst till resurser i din Microsoft Entra-klientorganisation.

Azure AD B2C är en unik produkt förutom microsoft entra externt ID som tillhandahåller en annan uppsättning funktioner. Azure AD B2C är avsett att användas av produktens kunder. Din Azure AD B2C-klientorganisation skiljer sig från din organisations Microsoft Entra-klientorganisation.

Beroende på användarpersoner och scenarier kan du behöva använda Microsoft Entra B2B, Azure AD B2C eller till och med båda samtidigt. Om ditt program till exempel behöver autentisera flera typer av användare, till exempel personal i din organisation, användare som arbetar för en leverantör och kunder, allt inom samma app, kan du använda Microsoft Entra B2B och Azure AD B2C tillsammans för att uppfylla detta krav.

Mer information finns i:

Deltagare

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

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg