Freigeben über

Überlegungen zur Nutzung von Azure Active Directory B2C in einer mehrinstanzenfähigen Architektur

  • Artikel

Azure Active Directory (Azure AD) B2C dient als Identitätsdienst zwischen Unternehmen und Kunden. Benutzeridentität ist in der Regel einer der wichtigsten Aspekte beim Entwerfen einer mehrinstanzenfähigen Anwendung. Ihre Identitätslösung dient als Zugangskontrolle für Ihre Anwendung und stellt sicher, dass Ihre Mandanten innerhalb der von Ihnen festgelegten Grenzen verbleiben. In diesem Artikel werden Überlegungen und Ansätze zur Nutzung von Azure AD B2C in einer mehrinstanzenfähigen Lösung beschrieben.

Einer der häufigsten Gründe für den Einsatz von Azure AD B2C ist das Aktivieren eines Identitätsverbunds für eine Anwendung. Ein Identitätsverbund ist das Ergebnis der Einrichtung einer Vertrauensstellung zwischen zwei Identitätsanbietern, damit sich Benutzer mit einem bereits vorhandenen Konto anmelden können. Bei Verwenden von Azure AD B2C können Sie einen Identitätsverbund implementieren, um Benutzern zu ermöglichen, sich mit ihrem Social-Media- oder Unternehmenskonto anzumelden. Wenn Sie einen Verbund nutzen, müssen Ihre Benutzer kein separates lokales Konto erstellen, das für Ihre Anwendung spezifisch ist.

Wenn Sie mit diesem Thema noch nicht vertraut sind, empfehlen wir Ihnen die folgenden Ressourcen:

Hinweis

In diesem Artikel werden zwei ähnlich benannte Konzepte erläutert: Anwendungsmandanten und Azure AD B2C-Mandanten.

Der Begriff Anwendungsmandant bezieht sich auf Ihre Mandanten, bei denen es sich um Ihre Kunden oder Benutzergruppen handeln kann.

Azure AD B2C nutzt auch das Mandantenkonzept in Bezug auf einzelne Verzeichnisse. Der Begriff Mehrinstanzenfähigkeit beschreibt Interaktionen zwischen mehreren Azure AD B2C-Mandanten. Obwohl die Begriffe identisch sind, sind die Konzepte es nicht. Wenn in diesem Artikel auf einen Azure AD B2C-Mandanten verwiesen wird, wird der vollständige Begriff Azure AD B2C-Mandant verwendet.

Identität in mehrinstanzenfähigen Lösungen

In mehrinstanzenfähigen Lösungen ist es üblich, mehrere Identitätsdienste zu kombinieren, um unterschiedliche Anforderungen zu erfüllen. Viele Lösungen weisen zwei unterschiedliche Identitätstypen auf:

  • Kundenidentitäten, die für Endbenutzerkonten gelten. Sie steuern, wie Benutzer in Ihren Mandanten Zugriff auf Ihre Anwendungen erhalten.
  • Interne Identitäten, mit deren Hilfe Ihr eigenes Team Ihre Lösung verwaltet.

Diese verschiedenen Identitätstypen arbeiten in der Regel auch mit unterschiedlichen Identitätsdiensten. Azure AD B2C ist ein kundenorientierter Dienst zur Identitäts- und Zugriffsverwaltung, mit dem Benutzer in Ihren Mandanten auf die Lösung zugreifen können. Microsoft Entra ID ist ein IAM-Dienst (Identity and Access Management, Identitäts- und Zugriffsverwaltung), mit dem Sie und Ihr Team Ihre Azure-Ressourcen verwalten und Ihre Anwendung steuern.

Betrachten wir ein Beispiel für eine mehrinstanzenfähige Lösung, die von Fabrikam erstellt wurde. Die Lösung nutzt eine Kombination beider Dienste, um die Anforderungen von Fabrikam zu erfüllen:

  • Fabrikam implementiert Azure AD B2C, damit sich die Kunden (Mandanten) des Unternehmens bei Anwendungen anmelden können.
  • Mitarbeiter von Fabrikam nutzen das Microsoft Entra-Verzeichnis ihrer Organisation, um für Verwaltungszwecke Zugriff auf ihre Lösung zu erhalten. Sie nutzen dieselben Identitäten, mit denen sie auch auf andere Fabrikam-Ressourcen wie Microsoft Office zugreifen.

Das folgende Diagramm veranschaulicht dieses Beispiel:

Diagramm, das zwei Anwendungen mit zwei Anmeldemethoden zeigt.

Isolationsmodelle

Bei Verwendung von Azure AD B2C müssen Sie entscheiden, wie Sie Ihre Benutzerkonten zwischen verschiedenen Anwendungsmandanten isolieren.

Sie müssen Fragen wie die folgenden beantworten:

  • Müssen Sie für Anmeldungen bei den Identitätsanbietern Ihrer Kunden einen Verbund bilden? Müssen Sie beispielsweise einen Verbund für SAML, Microsoft Entra ID, Social-Media-Anmeldungsanbieter oder sonstige Quellen aktivieren?
  • Gibt es bei Ihnen oder Ihren Mandanten Anforderungen an Datenresidenz?
  • Muss der Benutzer auf mehr als einen Anwendungsmandanten zugreifen?
  • Benötigen Sie komplexe Berechtigungen und/oder rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC)?
  • Wer meldet sich bei Ihrer Anwendung an? Verschiedene Kategorien von Benutzern werden häufig als Benutzerpersonas bezeichnet.

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenmodelle für Azure AD B2C erläutert:

Aspekt Gemeinsam genutzter Azure AD B2C-Mandant Vertikal partitionierter Azure AD B2C-Mandant Ein Azure AD B2C-Mandant pro Anwendungsmandant
Datenisolation Daten der einzelnen Anwendungsmandanten sind in einem einzelnen Azure AD B2C-Mandanten gespeichert, aber nur Administratoren können darauf zugreifen. Daten der einzelnen Anwendungsmandanten sind auf mehrere Azure AD B2C-Mandanten verteilt, aber nur Administratoren können darauf zugreifen. Daten der einzelnen Anwendungsmandanten sind in einem dedizierten Azure AD B2C-Mandanten gespeichert, aber nur Administratoren können darauf zugreifen.
Bereitstellungskomplexität Niedrig Je nach Partitionierungsstrategie mittel bis hoch Sehr hoch
Zu berücksichtigende Grenzwerte Anforderungen pro Azure AD B2C-Mandanten, Anforderungen pro Client-IP-Adresse Eine Kombination aus Anforderungen, Anzahl von Azure AD B2C-Mandanten pro Abonnement und Anzahl von Verzeichnissen pro einzelnem Benutzer, abhängig von Ihrer Partitionierungsstrategie Anzahl von Azure AD B2C-Mandanten pro Abonnement, maximale Anzahl von Verzeichnissen pro einzelnem Benutzer
Komplexität des Betriebs Niedrig Je nach Partitionierungsstrategie mittel bis hoch Sehr hoch
Anzahl der erforderlichen Azure AD B2C-Mandanten Eine Je nach Partitionierungsstrategie 1 bis n n, wobei „n“ die Anzahl der Anwendungsmandanten ist
Beispielszenario Sie erstellen ein SaaS-Angebot für Kunden mit geringen oder keinen Anforderungen an Datenresidenz, z. B. einen Musik- oder Videostreamingdienst. Sie erstellen ein SaaS-Angebot, z. B. für eine Anwendung zur Rechnungsführung und Buchhaltung für Unternehmen. Sie müssen Anforderungen an Datenresidenz oder eine große Anzahl benutzerdefinierter Verbundidentitätsanbieter unterstützen. Sie erstellen ein SaaS-Angebot, z. B. für eine Buchhaltungsanwendung für Behörden. Ihre Kunden verlangen ein hohes Maß an Datenisolation von anderen Anwendungsmandanten.

Gemeinsam genutzter Azure AD B2C-Mandant

Es ist im Allgemeinen am einfachsten, einen einzelnen gemeinsam genutzten Azure AD B2C-Mandanten zu verwalten, sofern Ihre Anforderungen dies zulassen. Sie müssen nur einen Mandanten langfristig warten, und diese Option verursacht den geringsten Aufwand.

Hinweis

Für die meisten Szenarien wird ein gemeinsam genutzter Azure AD B2C-Mandant empfohlen.

Ziehen Sie einen gemeinsam genutzten Azure AD B2C-Mandanten in folgenden Fällen in Betracht:

  • Es gelten keine Anforderungen an Datenresidenz oder strenge Anforderungen an Datenisolation.
  • Ihre Anwendungsanforderungen bewegen sich innerhalb der Dienstgrenzwerte von Azure AD B2C.
  • Wenn es Verbundidentitätsanbieter gibt, können Sie mithilfe der Startbereichsermittlung automatisch einen Anbieter auswählen, bei dem sich ein Benutzer anmelden kann. Es ist aber auch möglich, dass Benutzer manuell einen Anbieter in einer Liste auswählen.
  • Sie verfügen über eine einheitliche Anmeldungsumgebung für alle Anwendungsmandanten.
  • Ihre Benutzer müssen über ein einzelnes Konto auf mehr als einen Anwendungsmandanten zugreifen können.

Dieses Diagramm veranschaulicht das gemeinsam genutzte Azure AD B2C-Mandantenmodell:

Diagramm mit drei Anwendungen, die eine Verbindung mit einem einzelnen gemeinsam genutzten Azure AD B2C-Mandanten herstellen.

Vertikal partitionierter Azure AD B2C-Mandant

Die Bereitstellung vertikal partitionierter Azure AD B2C-Mandanten ist eine Strategie zur größtmöglichen Reduzierung der Anzahl benötigter Azure AD B2C-Mandanten. Es handelt sich um einen Mittelweg zwischen den anderen Mandantenmodellen. Vertikale Partitionierung bietet im Bedarfsfall mehr Flexibilität bei der benutzerdefinierten Anpassung für bestimmte Mandanten. Sie verursacht jedoch nicht den betrieblichen Mehraufwand aufgrund der Bereitstellung eines Azure AD B2C-Mandanten für jeden Anwendungsmandanten.

Die Bereitstellungs- und Wartungsanforderungen für dieses Mandantenmodell sind höher als bei einem einzelnen Azure AD B2C-Mandanten, aber geringer als bei einem Azure AD B2C-Mandanten pro Anwendungsmandanten. Sie müssen nach wie vor eine Strategie zur Bereitstellung und Wartung mehrerer Mandanten in Ihrer Umgebung entwerfen und implementieren.

Vertikale Partitionierung ähnelt dem Muster der horizontalen Partitionierung. Um Ihre Azure AD B2C-Mandanten vertikal zu partitionieren, müssen Sie Ihre Anwendungsmandanten in logischen Gruppen organisieren. Diese Kategorisierung von Mandanten wird häufig als Partitionierungsstrategie bezeichnet. Ihre Partitionierungsstrategie sollte auf einem allgemeinen, konstanten Kriterium des Anwendungsmandanten basieren, wie z. B. Region oder Größe, oder auf benutzerdefinierten Anforderungen des Anwendungsmandanten. Wenn Ihr Ziel beispielsweise darin besteht, Anforderungen an Datenresidenz zu erfüllen, empfiehlt es sich möglicherweise, einen Azure AD B2C-Mandanten für jede Region bereitzustellen, in der Anwendungsmandanten gehostet werden. Oder wenn Sie nach Größe gruppieren, können Sie die meisten Identitäten Ihrer Anwendungsmandanten in einem einzelnen Azure AD B2C-Mandanten ansiedeln, Ihre größten Anwendungsmandanten jedoch in ihren eigenen dedizierten Azure AD B2C-Mandanten.

Wichtig

Vermeiden Sie es, Ihre Partitionierungsstrategie auf Kriterien zu stützen, die sich im Laufe der Zeit ändern können, denn Benutzer lassen sich nicht einfach zwischen Azure AD B2C-Mandanten verschieben. Wenn Sie beispielsweise ein SaaS-Angebot mit mehreren SKUs oder Produktebenen erstellen, sollten Sie Ihre Benutzer nicht auf Grundlage der ausgewählten SKU partitionieren, da die SKU sich ändern kann, wenn der Kunde sein Produkt einem Upgrade unterzieht.

Sie sollten in den folgenden Fällen die Bereitstellung Ihrer Azure AD B2C-Mandanten mit einer vertikal partitionierten Strategie in Betracht ziehen:

  • Sie haben Anforderungen an Datenresidenz oder müssen Benutzer nach Region trennen.
  • Sie verfügen über eine große Anzahl von Verbundidentitätsanbietern und können die Startbereichsermittlung nicht verwenden, um einen automatisch für einen Benutzer auszuwählen, mit dem er sich anmelden kann.
  • Ihre Anwendung ist oder kann mehrinstanzenfähig sein und weiß, bei welchem Azure AD B2C-Mandanten sich Ihre Benutzer anmelden müssen.
  • Sie vermuten, dass Ihre größeren Anwendungsmandanten die Grenzwerte für Azure AD B2C erreichen könnten.
  • Sie haben eine langfristige Strategie zum Bereitstellen und Warten einer mittleren bis großen Anzahl von Azure AD B2C-Mandanten.
  • Sie haben eine Strategie für die Aufteilung Ihrer Anwendungsmandanten auf ein oder mehrere Azure-Abonnements, um innerhalb der begrenzten Anzahl von Azure AD B2C-Mandanten zu arbeiten, die in einem Azure-Abonnement bereitgestellt werden können.

Das folgende Diagramm veranschaulicht das vertikal partitionierte Azure AD B2C-Mandantenmodell:

Diagramm mit drei Anwendungen. Zwei sind mit einem gemeinsam genutzten Azure AD B2C-Mandanten verbunden. Die dritte ist mit einem eigenen Azure AD B2C-Mandanten verbunden.

Ein Azure AD B2C-Mandant pro Anwendungsmandanten

Wenn Sie für jeden Anwendungsmandanten einen Azure AD B2C-Mandanten bereitstellen, können Sie für jeden Mandanten zahlreiche Faktoren anpassen. Dieser Ansatz führt jedoch zu erheblich mehr Aufwand. Sie müssen eine Bereitstellungs- und Wartungsstrategie für eine potenziell große Anzahl von Azure AD B2C-Mandanten entwickeln.

Sie müssen außerdem die Dienstgrenzwerte kennen. Azure-Abonnements lassen nur die Bereitstellung einer begrenzten Anzahl von Azure AD B2C-Mandanten zu. Wenn Sie mehr bereitstellen müssen, als der Grenzwert zulässt, müssen Sie einen geeigneten Abonnemententwurf in Betracht ziehen, damit Sie Ihre Azure AD B2C-Mandanten gleichmäßig auf mehrere Abonnements verteilen können. Es gibt noch weitere Microsoft Entra-Grenzwerte, wie z. B. für die Anzahl der Verzeichnisse, die ein einzelner Benutzer erstellen kann, und die Anzahl der Verzeichnisse, denen ein Benutzer angehören kann.

Warnung

Aufgrund der Komplexität dieses Ansatzes wird dringend empfohlen, zuerst die anderen Isolationsmodelle zu berücksichtigen. Diese Option ist hier aus Gründen der Vollständigkeit enthalten, aber für die meisten Anwendungsfälle nicht der richtige Ansatz.

Ein häufiges Missverständnis besteht darin anzunehmen, dass Sie bei Verwendung des Musters Bereitstellungsstempel Identitätsdienste in jeden Stempel einschließen müssen. Dies ist nicht unbedingt der Fall, und Sie können stattdessen häufig ein anderes Isolationsmodell wählen. Wenn Sie dieses Isolationsmodell wählen, sollten Sie sorgfältig vorgehen und eine klare geschäftliche Begründung haben. Denn der Mehraufwand für Bereitstellung und Wartung ist erheblich.

Sie sollten die Bereitstellung eines Azure AD B2C-Mandanten für jeden Anwendungsmandanten nur in folgenden Fällen in Betracht ziehen:

  • Für Anwendungsmandanten gelten strenge Anforderungen an Datenisolation.
  • Sie haben eine langfristige Strategie zum Bereitstellen und Warten einer großen Anzahl von Azure AD B2C-Mandanten.
  • Sie verfügen über eine Strategie zum Aufteilen Ihrer Kunden auf ein oder mehrere Azure-Abonnements, um den Grenzwert für Azure AD B2C-Mandanten pro Abonnement einzuhalten.
  • Ihre Anwendung ist oder kann mehrinstanzenfähig sein und weiß, bei welchem Azure AD B2C-Mandanten sich Ihre Benutzer anmelden müssen.
  • Für jeden Anwendungsmandanten ist eine benutzerdefinierte Konfiguration erforderlich.
  • Ihre Endbenutzer müssen nicht über dasselbe Anmeldekonto auf mehr als einen Anwendungsmandanten zugreifen.

Das folgende Diagramm veranschaulicht die Nutzung eines Azure AD B2C-Mandanten pro Anwendungsmandant:

Diagramm mit drei Anwendungen, die jeweils eine Verbindung mit einem eigenen Azure AD B2C-Mandanten herstellen.

Identitätsverbund

Sie müssen jeden Verbundidentitätsanbieter entweder über einen Benutzerflow oder in einer benutzerdefinierten Richtlinie konfigurieren. Normalerweise wählen Benutzer bei der Anmeldung den für die Authentifizierung gewünschten Identitätsanbieter aus. Wenn Sie ein Isolationsmodell mit gemeinsamen Mandanten verwenden oder eine große Anzahl von Verbundidentitätsanbietern haben, sollten Sie die Startbereichsermittlung verwenden, um bei der Anmeldung automatisch einen Identitätsanbieter auszuwählen.

Sie können mithilfe eines Identitätsverbunds auch mehrere Azure AD B2C-Mandanten verwalten, indem Sie einen Verbund zwischen den Azure AD B2C-Mandanten herstellen. Auf diese Weise kann Ihre Anwendung einem einzelnen Azure AD B2C-Mandanten vertrauen. Die Anwendung muss nicht wissen, dass Ihre Kunden auf mehrere Azure AD B2C-Mandanten aufgeteilt sind. Dieser Ansatz wird am häufigsten beim vertikal partitionierten Isolationsmodell befolgt, wenn Ihre Benutzer nach Region aufgeteilt sind. Wenn Sie diesen Ansatz übernehmen, müssen Sie einige Aspekte berücksichtigen. Eine Übersicht über diesen Ansatz finden Sie unter Globale Identitätslösungen.

Startbereichsermittlung (Home Realm Discovery, HDR)

Bei der Startbereichsermittlung wird automatisch ein Verbundidentitätsanbieter für das Anmeldeereignis eines Benutzers ausgewählt. Wenn Sie den Identitätsanbieter des Benutzers automatisch auswählen lassen, müssen Sie den Benutzer nicht auffordern, einen Anbieter auszuwählen.

Die Startbereichsermittlung ist wichtig, wenn Sie einen gemeinsam genutzten Azure AD B2C-Mandanten verwenden und Ihren Kunden außerdem ermöglichen, einen eigenen Verbundidentitätsanbieter bereitzustellen. Sie sollten einen Entwurf vermeiden, bei dem ein Benutzer in einer Liste von Identitätsanbietern eine Wahl treffen muss. Denn dadurch erhöht sich die Komplexität des Anmeldeprozesses. Außerdem könnte ein Benutzer versehentlich einen falschen Anbieter auswählen, wodurch der Anmeldeversuch fehlschlägt.

Sie können die Startbereichsermittlung auf verschiedene Weisen konfigurieren. Der gängigste Ansatz besteht darin, den Identitätsanbieter anhand des Domänensuffixes der E-Mail-Adresse des Benutzers zu ermitteln. Angenommen, Northwind Traders ist Kunde der mehrinstanzenfähigen Lösung von Fabrikam. Die E-Mail-Adresse user@northwindtraders.com enthält das Domänensuffix northwindtraders.com, das dem Verbundidentitätsanbieter Northwind Traders zugeordnet werden kann.

Weitere Informationen finden Sie unter Startbereichsermittlung. Ein Beispiel für die Umsetzung dieses Ansatzes in Azure AD B2C finden Sie im GitHub-Repository mit Azure AD B2C-Beispielen.

Datenresidenz

Wenn Sie einen Azure AD B2C-Mandanten bereitstellen, wählen Sie zum Zweck der Datenresidenz eine Region aus, in der der Mandant bereitgestellt werden soll. Diese Auswahl ist wichtig, da sie die Region angibt, in der sich Ihre ruhenden Kundendaten befinden. Wenn es für eine Teilmenge Ihrer Kunden Anforderungen an Datenresidenz gibt, erwägen Sie die Strategie mit vertikaler Partitionierung.

Authorization

Für eine sichere Identitätslösung müssen Sie zusätzlich zur Authentifizierung die Autorisierung in Betracht ziehen. Es gibt mehrere Ansätze für die Verwendung der Microsoft Identity Platform, um eine Autorisierungsstrategie für Ihre Anwendung zu erstellen. Das Beispiel AppRoles veranschaulicht, wie Sie die Autorisierung mithilfe von Azure AD B2C-App-Rollen in einer Anwendung implementieren. Außerdem werden alternative Autorisierungsansätze beschrieben.

Es gibt keinen einheitlichen Ansatz für die Autorisierung, und Sie sollten die Erfordernisse Ihrer Anwendung und Kunden berücksichtigen, wenn Sie sich für einen Ansatz entscheiden.

Wartung

Wenn Sie eine mehrinstanzenfähige Bereitstellung von Azure AD B2C planen, müssen Sie die langfristige Wartung Ihrer Azure AD B2C-Ressourcen bedenken. Ein Azure AD B2C-Mandant ist wie der Microsoft Entra-Mandant Ihrer Organisation eine Ressource, die Sie für Erstellungs-, Verwaltungs-, Betriebs- und Sicherungszwecke benötigen. Obwohl die folgende Liste nicht vollständig ist, sollten Sie die Wartung berücksichtigen, die in Bereichen wie den folgenden anfällt:

  • Mandantengovernance. Wer wartet den Azure AD B2C-Mandanten? Welche Rollen mit erhöhten Rechten benötigen diese Administratoren? Wie konfigurieren Sie Richtlinien für bedingten Zugriff und MFA für die Administratoren? Wie überwachen Sie den Azure AD B2C-Mandanten langfristig?
  • User Journey-Konfiguration. Wie stellen Sie Änderungen an Ihrem Azure AD B2C-Mandanten bereit? Wie testen Sie Änderungen an Ihren Benutzerflows oder benutzerdefinierten Richtlinien, bevor Sie sie bereitstellen?
  • Verbundidentitätsanbieter. Müssen Sie im Laufe der Zeit Identitätsanbieter hinzufügen oder entfernen? Wenn Sie jedem Ihrer Kunden erlauben, seinen eigenen Identitätsanbieter einzusetzen, wie verwalten Sie das im großen Stil?
  • App-Registrierungen. Viele Microsoft Entra-App-Registrierungen verwenden für die Authentifizierung einen geheimen Clientschlüssel oder ein Zertifikat. Wie rotieren Sie diese Geheimnisse oder Zertifikate bei Bedarf?
  • Richtlinienschlüssel. Wie rotieren Sie bei Bedarf die Richtlinienschlüssel, wenn Sie benutzerdefinierte Richtlinien verwenden?
  • Benutzeranmeldeinformationen Wie verwalten Sie Benutzer- und Anmeldeinformationen? Was passiert, wenn einer Ihrer Benutzer ausgesperrt wird oder sein Kennwort vergisst und der Administrator oder Kundenservice eingreifen muss?

Denken Sie daran, dass Sie diese Fragen bei jedem Azure AD B2C-Mandanten, den Sie bereitstellen, berücksichtigen müssen. Sie sollten auch berücksichtigen, wie sich Ihre Prozesse ändern, wenn Sie mehrere Azure AD B2C-Mandanten warten müssen. So ist es beispielsweise einfach, benutzerdefinierte Richtlinienänderungen manuell in einem Azure AD B2C-Mandanten bereitzustellen, aber die manuelle Bereitstellung in fünf Mandaten ist zeitaufwändig und riskant.

Bereitstellungen und DevOps

Ein überlegt definierter DevOps-Prozess kann Ihnen helfen, den für die Verwaltung Ihrer Azure AD B2C-Mandanten erforderlichen Aufwand zu minimieren. Sie sollten DevOps-Methoden frühzeitig in Ihrem Entwicklungsprozess implementieren. Idealerweise sollten Sie versuchen, alle oder die meisten Ihrer Wartungsaufgaben zu automatisieren, einschließlich der Bereitstellung von Änderungen an Ihren benutzerdefinierten Richtlinien oder Benutzerflows. Sie sollten auch planen, mehrere Azure AD B2C-Mandanten zu erstellen, um Änderungen schrittweise in untergeordneten Umgebungen zu testen, ehe Sie sie für Ihre Produktionsmandanten bereitstellen. Möglicherweise erfolgen diese Wartungsaktivitäten in Ihren DevOps-Pipelines. Mit der Microsoft Graph-API können Sie Ihre Azure AD B2C-Mandanten programmgesteuert verwalten.

Weitere Informationen zu automatisierten Bereitstellungen und zur Verwaltung von Azure AD B2C finden Sie in den folgenden Ressourcen.

Wichtig

Einige der Endpunkte zum programmgesteuerten Verwalten von Azure AD B2C sind nicht allgemein verfügbar. APIs in der Betaversion von Microsoft Graph können sich jederzeit ändern und unterliegen den Nutzungsbedingungen für Vorabversionen.

Vergleich von Microsoft Entra B2B mit Azure AD B2C

Microsoft Entra B2B Collaboration ist ein Feature von Microsoft Entra External ID, mit dem Sie Gastbenutzer*innen in den Microsoft Entra-Mandanten Ihrer Organisation einladen können, um mit ihnen zusammenzuarbeiten. In der Regel verwenden Sie B2B Collaboration, wenn Sie einem externen Benutzer wie einem Lieferanten Zugriff auf Ressourcen in Ihrem Microsoft Entra-Mandanten gewähren müssen.

Neben der externen Microsoft Entra-ID ist Azure AD B2C ein einzigartiges Produkt, das eine andere Reihe von Features bietet. Azure AD B2C ist für die Nutzung durch die Kunden Ihres Produkts gedacht. Ihr Azure AD B2C-Mandant unterscheidet sich vom Microsoft Entra-Mandanten Ihrer Organisation.

Je nach Ihren Benutzerpersonas und Szenarien müssen Sie möglicherweise Microsoft Entra B2B, Azure AD B2C oder sogar beides gleichzeitig verwenden. Wenn Ihre Anwendung beispielsweise mehrere Benutzertypen authentifizieren muss, z. B. Mitarbeiter in Ihrer Organisation, für einen Lieferanten arbeitende Benutzer sowie Kunden, und zwar alle innerhalb derselben App, können Sie Microsoft Entra B2B und Azure AD B2C zusammen verwenden, um diese Anforderung zu erfüllen.

Weitere Informationen finden Sie unter:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte