Delen via

Overwegingen voor het gebruik van Azure Active Directory B2C in een architectuur met meerdere tenants

  • Artikel

Azure Active Directory (Azure AD) B2C biedt business-to-consumer-identiteit als een service. Gebruikersidentiteit is doorgaans een van de belangrijkste overwegingen bij het ontwerpen van een multitenant-toepassing. Uw identiteitsoplossing fungeert als gatekeeper voor uw toepassing, zodat uw tenants binnen de grenzen blijven die u voor hen definieert. In dit artikel worden overwegingen en benaderingen beschreven voor het gebruik van Azure AD B2C in een multitenant-oplossing.

Een van de meest voorkomende redenen voor het gebruik van Azure AD B2C is het inschakelen van identiteitsfederatie voor een toepassing. Identiteitsfederatie is het proces voor het tot stand brengen van een vertrouwensrelatie tussen twee id-providers, zodat uw gebruikers zich kunnen aanmelden met een bestaand account. Als u Azure AD B2C gebruikt, kunt u identiteitsfederatie implementeren zodat uw gebruikers zich kunnen aanmelden met hun sociale of zakelijke accounts. Als u federatie gebruikt, hoeven uw gebruikers geen afzonderlijk lokaal account te maken dat specifiek is voor uw toepassing.

Als u nog niet bekend bent met dit onderwerp, raden we u aan de volgende bronnen te bekijken:

Notitie

In dit artikel worden twee vergelijkbare concepten besproken: toepassingstenants en Azure AD B2C-tenants.

De term toepassingstenant wordt gebruikt om te verwijzen naar uw tenants, die mogelijk uw klanten of groepen gebruikers zijn.

Azure AD B2C maakt ook gebruik van het tenantconcept in verwijzing naar afzonderlijke directory's en de term multitenancy wordt gebruikt om te verwijzen naar interacties tussen meerdere Azure AD B2C-tenants. Hoewel de termen hetzelfde zijn, zijn de concepten dat niet. Wanneer in dit artikel wordt verwezen naar een Azure AD B2C-tenant, wordt de volledige term Azure AD B2C-tenant gebruikt.

Identiteit in multitenant-oplossingen

In multitenant-oplossingen is het gebruikelijk om meerdere identiteitsservices te combineren om verschillende sets vereisten te bereiken. Veel oplossingen hebben twee verschillende sets identiteiten:

  • Klantidentiteiten, die voor eindgebruikersaccounts zijn. Ze bepalen hoe de gebruikers van uw tenants toegang krijgen tot uw toepassingen.
  • Interne identiteiten, die afhandelen hoe uw eigen team uw oplossing beheert.

Deze verschillende identiteitstypen gebruiken doorgaans ook afzonderlijke identiteitsservices. Azure AD B2C is een CIAM-service (Customer Identity and Access Management) die de gebruikers van uw tenants gebruiken om toegang te krijgen tot de oplossing. Microsoft Entra ID is een IAM-service (Identity and Access Management) die u en uw team gebruiken om uw Azure-resources te beheren en uw toepassing te beheren.

Bekijk een voorbeeld van een multitenant-oplossing die is gebouwd door Fabrikam. De oplossing maakt gebruik van een combinatie van de twee services om te voldoen aan de vereisten van Fabrikam:

  • Fabrikam implementeert Azure AD B2C zodat de klanten van het bedrijf (tenants) zich kunnen aanmelden bij toepassingen.
  • Werknemers van Fabrikam gebruiken de Microsoft Entra-adreslijst van hun organisatie om toegang te krijgen tot hun oplossing voor beheer- en beheerdoeleinden. Ze gebruiken dezelfde identiteiten die ze gebruiken voor toegang tot andere Fabrikam-resources, zoals Microsoft Office.

In het volgende diagram ziet u dit voorbeeld:

Diagram met twee toepassingen met twee methoden om u aan te melden.

Isolatiemodellen

Wanneer u Azure AD B2C gebruikt, moet u beslissen hoe u uw gebruikersaccounts tussen verschillende toepassingstenants kunt isoleren.

U moet rekening houden met vragen zoals:

  • Moet u aanmeldingen federeren bij de id-providers van uw klant? Moet u bijvoorbeeld federatie inschakelen voor SAML, Microsoft Entra ID, providers voor sociale aanmelding of andere bronnen?
  • Hebben u of uw tenants vereisten voor gegevenslocatie?
  • Heeft de gebruiker toegang nodig tot meer dan één toepassingstenant?
  • Hebt u complexe machtigingen en/of op rollen gebaseerd toegangsbeheer (RBAC) nodig?
  • Wie meldt zich aan bij uw toepassing? Verschillende categorieën gebruikers worden vaak gebruikers-persona's genoemd.

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancymodellen voor Azure AD B2C:

Overweging Gedeelde Azure AD B2C-tenant Verticaal gepartitioneerde Azure AD B2C-tenant Eén Azure AD B2C-tenant per toepassingstenant
Gegevensisolatie Gegevens van elke toepassingstenant worden opgeslagen in één Azure AD B2C-tenant, maar kunnen alleen worden geopend door beheerders Gegevens van elke toepassingstenant worden verdeeld over verschillende Azure AD B2C-tenants, maar kunnen alleen worden geopend door beheerders Gegevens van elke toepassingstenant worden opgeslagen in een toegewezen Azure AD B2C-tenant, maar kunnen alleen worden geopend door beheerders
Implementatiecomplexiteit Beperkt Gemiddeld tot hoog, afhankelijk van uw partitioneringsstrategie Zeer hoog
Limieten om rekening mee te houden Aanvragen per Azure AD B2C-tenant, aanvragen per client-IP-adres Een combinatie van aanvragen, het aantal Azure AD B2C-tenants per abonnement en het aantal directory's voor één gebruiker, afhankelijk van uw partitioneringsstrategie Aantal Azure AD B2C-tenants per abonnement, maximum aantal directory's voor één gebruiker
Operationele complexiteit Beperkt Gemiddeld tot hoog, afhankelijk van uw partitioneringsstrategie Zeer hoog
Aantal vereiste Azure AD B2C-tenants Eén Tussen één en n, afhankelijk van uw partitioneringsstrategie n, waarbij n het aantal toepassingstenants is
Voorbeeldscenario U bouwt een SaaS-aanbieding voor consumenten met weinig of geen vereisten voor gegevenslocatie, zoals een muziek- of videostreamingservice. U bouwt een SaaS-aanbieding, zoals een boekhoud- en recordbeheertoepassing voor bedrijven. U moet vereisten voor gegevenslocatie of een groot aantal aangepaste federatieve id-providers ondersteunen. U bouwt een SaaS-aanbieding, zoals een overheidsrecordtoepassing voor bedrijven. Uw klanten verplichten een hoge mate van gegevensisolatie van andere toepassingstenants.

Gedeelde Azure AD B2C-tenant

Het is over het algemeen het eenvoudigst om één gedeelde Azure AD B2C-tenant te beheren als uw vereisten dit toestaan. U hoeft slechts één tenant op de lange termijn te onderhouden en met deze optie maakt u de laagste overhead.

Notitie

Voor de meeste scenario's wordt het gebruik van een gedeelde Azure AD B2C-tenant aanbevolen.

U moet een gedeelde Azure AD B2C-tenant overwegen wanneer:

  • U hebt geen vereisten voor gegevenslocatie of strikte vereisten voor gegevensisolatie.
  • Uw toepassingsvereisten vallen binnen de azure AD B2C-servicelimieten.
  • Als u federatieve id-providers hebt, kunt u Home Realm Discovery gebruiken om automatisch een provider te selecteren waarmee een gebruiker zich kan aanmelden, of het is acceptabel dat gebruikers er handmatig een selecteren in een lijst.
  • U hebt een uniforme aanmeldingservaring voor alle toepassingstenants.
  • Uw eindgebruikers moeten toegang hebben tot meer dan één toepassingstenant met één account.

Dit diagram illustreert het gedeelde Azure AD B2C-tenantmodel:

Diagram met drie toepassingen die verbinding maken met één gedeelde Azure AD B2C-tenant.

Verticaal gepartitioneerde Azure AD B2C-tenants

Het inrichten van verticaal gepartitioneerde Azure AD B2C-tenants is een strategie die is ontworpen om, indien mogelijk, het aantal Azure AD B2C-tenants te minimaliseren. Het is een middelste basis tussen de andere tenancymodellen. Verticale partitionering biedt meer flexibiliteit bij het aanpassen van specifieke tenants wanneer dat nodig is. Er wordt echter geen operationele overhead gemaakt die is gekoppeld aan het inrichten van een Azure AD B2C-tenant voor elke toepassingstenant.

De implementatie- en onderhoudsvereisten voor dit tenancymodel zijn hoger dan die van één Azure AD B2C-tenant, maar ze zijn lager dan wanneer u één Azure AD B2C-tenant per toepassingstenant gebruikt. U moet nog steeds een implementatie- en onderhoudsstrategie ontwerpen en implementeren voor meerdere tenants in uw omgeving.

Verticale partitionering is vergelijkbaar met het gegevens-Sharding-patroon. Als u uw Azure AD B2C-tenants verticaal wilt partitioneren, moet u uw toepassingstenants ordenen in logische groepen. Deze categorisatie van tenants wordt vaak een partitioneringsstrategie genoemd. Uw partitioneringsstrategie moet zijn gebaseerd op een algemene, stabiele factor van de toepassingstenant, zoals regio, grootte of aangepaste vereisten van een toepassingstenant. Als u bijvoorbeeld uw vereisten voor gegevenslocatie wilt oplossen, kunt u besluiten om een Azure AD B2C-tenant te implementeren voor elke regio die als host fungeert voor toepassingstenants. Of, als u groepeert op grootte, kunt u besluiten om de meeste identiteiten van uw toepassingstenants te vinden op één Azure AD B2C-tenant, maar uw grootste toepassingstenants te zoeken op hun eigen toegewezen Azure AD B2C-tenants.

Belangrijk

Vermijd het baseren van uw partitioneringsstrategie op factoren die na verloop van tijd kunnen veranderen, omdat het lastig is om gebruikers tussen Azure AD B2C-tenants te verplaatsen. Als u bijvoorbeeld een SaaS-aanbieding met meerdere SKU's of productlagen maakt, moet u uw gebruikers niet partitioneren op basis van de SKU die ze selecteren, omdat de SKU kan veranderen als de klant het product bijwerkt.

Overweeg om uw Azure AD B2C-tenants in te richten met behulp van een verticaal gepartitioneerde strategie als:

  • U hebt vereisten voor gegevenslocatie of u moet uw gebruikers scheiden op geografie.
  • U hebt een groot aantal federatieve id-providers en u kunt Home Realm Discovery niet gebruiken om er automatisch een te selecteren voor een gebruiker om u aan te melden.
  • Uw toepassing is of kan zich bewust zijn van multitenancy en weet bij welke Azure AD B2C-tenant uw gebruikers zich moeten aanmelden.
  • U denkt dat uw grotere toepassingstenants de Azure AD B2C-limieten kunnen bereiken.
  • U hebt een langetermijnstrategie voor het implementeren en onderhouden van een gemiddeld tot groot aantal Azure AD B2C-tenants.
  • U hebt een strategie voor het sharden van uw toepassingstenants tussen een of meer Azure-abonnementen om binnen de limiet te werken voor het aantal Azure AD B2C-tenants dat kan worden geïmplementeerd in een Azure-abonnement.

In het volgende diagram ziet u het verticaal gepartitioneerde Azure AD B2C-tenantmodel:

Diagram met drie toepassingen. Er zijn twee verbonden met een gedeelde Azure AD B2C-tenant. De derde is verbonden met een eigen Azure AD B2C-tenant.

Eén Azure AD B2C-tenant per toepassingstenant

Als u een Azure AD B2C-tenant inricht voor elke toepassingstenant, kunt u veel factoren voor elke tenant aanpassen. Deze benadering creëert echter een aanzienlijke toename van de overhead. U moet een implementatie- en onderhoudsstrategie ontwikkelen voor een potentieel groot aantal Azure AD B2C-tenants.

U moet ook rekening houden met servicelimieten. Met Azure-abonnementen kunt u slechts een beperkt aantal Azure AD B2C-tenants implementeren. Als u meer dan de limiet wilt implementeren, moet u rekening houden met een geschikt abonnementsontwerp , zodat u uw Azure AD B2C-tenants over meerdere abonnementen kunt verdelen. Er zijn ook andere Microsoft Entra-limieten die van toepassing zijn, zoals het aantal directory's dat één gebruiker kan maken en het aantal directory's waartoe een gebruiker kan behoren.

Waarschuwing

Vanwege de complexiteit van deze benadering raden we u ten zeerste aan eerst de andere isolatiemodellen te overwegen. Deze optie is hier opgenomen omwille van volledigheid, maar het is niet de juiste benadering voor de meeste gebruiksvoorbeelden.

Een veelvoorkomende misvatting is ervan uit te gaan dat als u het patroon Implementatiestempels gebruikt, u identiteitsservices in elke stempel moet opnemen. Dat is niet noodzakelijkerwijs waar en u kunt in plaats daarvan vaak een ander isolatiemodel gebruiken. Wees zorgvuldig en heb een duidelijke zakelijke reden als u dit isolatiemodel gebruikt. De overhead voor implementatie en onderhoud is aanzienlijk.

Overweeg om een Azure AD B2C-tenant in te richten voor elke toepassingstenant als:

  • U hebt strikte vereisten voor gegevensisolatie voor toepassingstenants.
  • U hebt een langetermijnstrategie voor het implementeren en onderhouden van een groot aantal Azure AD B2C-tenants.
  • U hebt een strategie voor het sharden van uw klanten tussen een of meer Azure-abonnementen om te voldoen aan de tenantlimiet van Azure AD B2C per abonnement.
  • Uw toepassing is of kan zich bewust zijn van multitenancy en weet bij welke Azure AD B2C-tenant uw gebruikers zich moeten aanmelden.
  • U moet een aangepaste configuratie uitvoeren voor elke toepassingstenant.
  • Uw eindgebruikers hoeven niet meer dan één toepassingstenant te openen via hetzelfde aanmeldingsaccount.

In het volgende diagram ziet u het gebruik van één Azure AD B2C-tenant per toepassingstenant:

Diagram met drie toepassingen, die elk verbinding maken met een eigen Azure AD B2C-tenant.

Identiteitsfederatie

U moet elke federatieve id-provider configureren via een gebruikersstroom of in een aangepast beleid. Meestal selecteren gebruikers tijdens het aanmelden de id-provider die ze willen gebruiken om zich te verifiëren. Als u een gedeeld tenantisolatiemodel gebruikt of een groot aantal federatieve id-providers hebt, kunt u overwegen om Home Realm Discovery te gebruiken om automatisch een id-provider te selecteren tijdens het aanmelden.

U kunt identiteitsfederatie ook gebruiken als hulpprogramma voor het beheren van meerdere Azure AD B2C-tenants door de Azure AD B2C-tenants met elkaar te federeren. Hierdoor kan uw toepassing één Azure AD B2C-tenant vertrouwen. De toepassing hoeft niet te weten dat uw klanten zijn verdeeld over meerdere Azure AD B2C-tenants. Deze benadering wordt meestal gebruikt in het verticaal gepartitioneerde isolatiemodel wanneer uw gebruikers worden gepartitioneerd per regio. U moet rekening houden met enkele overwegingen als u deze aanpak aanneemt. Zie Globale identiteitsoplossingen voor een overzicht van deze aanpak.

Detectie van thuisrealm

Home Realm Discovery is het proces voor het automatisch selecteren van een federatieve id-provider voor de aanmeldingsgebeurtenis van een gebruiker. Als u automatisch de id-provider van de gebruiker selecteert, hoeft u de gebruiker niet te vragen een provider te selecteren.

Home Realm Discovery is belangrijk wanneer u een gedeelde Azure AD B2C-tenant gebruikt en uw klanten ook in staat stelt om hun eigen federatieve id-provider te gebruiken. Mogelijk wilt u een ontwerp vermijden waarin een gebruiker een keuze moet maken uit een lijst met id-providers. Dit voegt complexiteit toe aan het aanmeldingsproces. Bovendien kan een gebruiker per ongeluk een onjuiste provider selecteren, waardoor de aanmeldingspoging mislukt.

U kunt Home Realm Discovery op verschillende manieren configureren. De meest voorkomende methode is om het domeinachtervoegsel van het e-mailadres van de gebruiker te gebruiken om de id-provider te bepalen. Stel dat Northwind Traders een klant is van de multitenant-oplossing van Fabrikam. Het e-mailadres bevat het domeinachtervoegsel user@northwindtraders.com northwindtraders.com, dat kan worden toegewezen aan de federatieve id-provider van Northwind Traders.

Zie Home Realm Discovery voor meer informatie. Zie de GitHub-opslagplaats met Azure AD B2C-voorbeelden voor een voorbeeld van het implementeren van deze benadering in Azure AD B2C.

Gegevensresidentie

Wanneer u een Azure AD B2C-tenant inricht, selecteert u voor gegevenslocatie een regio waarin de tenant moet worden geïmplementeerd. Deze keuze is belangrijk omdat hiermee de regio wordt opgegeven waarin uw klantgegevens zich bevinden wanneer ze in rust zijn. Als u vereisten voor gegevenslocatie hebt voor een subset van uw klanten, kunt u overwegen de verticaal gepartitioneerde strategie te gebruiken.

Autorisatie

Voor een sterke identiteitsoplossing moet u naast verificatie rekening houden met autorisatie. Er zijn verschillende benaderingen voor het gebruik van het Microsoft Identity Platform om een autorisatiestrategie voor uw toepassing te maken. Het AppRoles-voorbeeld laat zien hoe u Azure AD B2C-app-rollen gebruikt om autorisatie in een toepassing te implementeren. Ook worden alternatieve autorisatiemethoden beschreven.

Er is geen enkele benadering voor autorisatie en u moet rekening houden met de behoeften van uw toepassing en uw klanten wanneer u besluit over een aanpak.

Onderhoud

Wanneer u een multitenant-implementatie van Azure AD B2C plant, moet u nadenken over het langetermijnonderhoud van uw Azure AD B2C-resources. Een Azure AD B2C-tenant, zoals uw Microsoft Entra-tenant van uw organisatie, is een resource die u moet maken, onderhouden, gebruiken en beveiligen. Hoewel de volgende lijst niet volledig is, moet u rekening houden met het onderhoud dat wordt gemaakt op gebieden zoals deze:

  • Tenantbeheer. Wie onderhoudt de Azure AD B2C-tenant? Welke verhoogde rollen hebben deze beheerders nodig? Hoe configureert u beleid voor voorwaardelijke toegang en MFA voor de beheerders? Hoe bewaakt u de Azure AD B2C-tenant op de lange termijn?
  • Configuratie van gebruikerstraject. Hoe implementeert u wijzigingen in uw Azure AD B2C-tenant of -tenants? Hoe test u wijzigingen in uw gebruikersstromen of aangepaste beleidsregels voordat u ze implementeert?
  • Federatieve id-providers. Moet u na verloop van tijd id-providers toevoegen of verwijderen? Als u al uw klanten toestaat om hun eigen id-provider mee te nemen, hoe beheert u dat op schaal?
  • App-registraties. Veel Microsoft Entra-app-registraties maken gebruik van een clientgeheim of certificaat voor verificatie. Hoe roteert u deze geheimen of certificaten wanneer dat nodig is?
  • Beleidssleutels. Als u aangepast beleid gebruikt, hoe roteert u de beleidssleutels wanneer dat nodig is?
  • Gebruikersreferenties. Hoe beheert u gebruikersgegevens en -referenties? Wat gebeurt er als een van uw gebruikers is vergrendeld of een wachtwoord vergeet en beheerders- of klantenservice-interventie vereist?

Houd er rekening mee dat u rekening moet houden met deze vragen voor elke Azure AD B2C-tenant die u implementeert. U moet ook overwegen hoe uw processen veranderen wanneer u meerdere Azure AD B2C-tenants hebt om te onderhouden. Het handmatig implementeren van aangepaste beleidswijzigingen in één Azure AD B2C-tenant is bijvoorbeeld eenvoudig, maar handmatig implementeren naar vijf tenants is tijdrovend en riskant.

Implementaties en DevOps

Een goed gedefinieerd DevOps-proces kan u helpen de overhead te minimaliseren die nodig is voor het onderhouden van uw Azure AD B2C-tenants. U moet DevOps-procedures vroeg in uw ontwikkelingsproces implementeren. In het ideale geval moet u proberen om alle of de meeste onderhoudstaken te automatiseren, inclusief het implementeren van wijzigingen in uw aangepaste beleid of gebruikersstromen. U moet ook van plan zijn om meerdere Azure AD B2C-tenants te maken om wijzigingen in lagere omgevingen geleidelijk te testen voordat u ze implementeert in uw productietenants. Uw DevOps-pijplijnen kunnen deze onderhoudsactiviteiten uitvoeren. U kunt de Microsoft Graph API gebruiken om uw Azure AD B2C-tenants programmatisch te beheren.

Zie de volgende resources voor meer informatie over geautomatiseerde implementaties en het beheer van Azure AD B2C.

Belangrijk

Sommige eindpunten die worden gebruikt om Azure AD B2C programmatisch te beheren, zijn niet algemeen beschikbaar. API's in de bètaversie van Microsoft Graph kunnen op elk gewenst moment worden gewijzigd en zijn onderhevig aan voorlopige servicevoorwaarden.

Microsoft Entra B2B vergelijken met Azure AD B2C

Microsoft Entra B2B-samenwerking is een functie van Microsoft Entra Externe ID die u kunt gebruiken om gastgebruikers uit te nodigen in uw Microsoft Entra-tenant van uw organisatie, zodat u met hen kunt samenwerken. Normaal gesproken gebruikt u B2B-samenwerking wanneer u een externe gebruiker, zoals een leverancier, toegang moet verlenen tot resources in uw Microsoft Entra-tenant.

Azure AD B2C is een uniek product, afgezien van Microsoft Entra Externe ID die een andere set functies biedt. Azure AD B2C is bedoeld voor gebruik door de klanten van uw product. Uw Azure AD B2C-tenant verschilt van uw Microsoft Entra-tenant van uw organisatie.

Afhankelijk van uw gebruikerspersoonlijke personen en scenario's moet u mogelijk Microsoft Entra B2B, Azure AD B2C of zelfs beide tegelijk gebruiken. Als uw toepassing bijvoorbeeld meerdere typen gebruikers moet verifiëren, zoals personeel in uw organisatie, gebruikers die voor een leverancier werken en klanten, allemaal binnen dezelfde app, kunt u Microsoft Entra B2B en Azure AD B2C samen gebruiken om aan deze vereiste te voldoen.

Zie voor meer informatie:

Medewerkers

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

Hoofdauteur:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen