Globales Azure Active Directory B2C-Identitätsframework
Azure Active Directory B2C ist eine CIAM-Lösung (Customer Identity Access Management), die Millionen von Benutzern und Milliarden von Authentifizierungen pro Tag unterstützt. Es sorgt für die Skalierung und Sicherheit der Authentifizierungsplattform sowie die Überwachung und automatische Behandlung von Bedrohungen wie Denial-of-Service-, Kennwort-Spray- oder Brute-Force-Angriffen.
Azure Active Directory B2C (Azure AD B2C) ist ein von Microsoft Entra ID getrennter Dienst. Er basiert auf der gleichen Technologie wie Microsoft Entra ID, dient aber einem anderen Zweck. Er ermöglicht Unternehmen, kundenorientierte Anwendungen zu erstellen, und ermöglicht dann die Self-Service-Registrierung bei Anwendungen.
Azure AD B2C ist ein global verteilter Dienst, der aus mehreren Komponenten besteht:
Verzeichnis
Beim Erstellen einer Azure AD B2C-Lösung müssen Sie einen Speicherort zum Hosten des Diensts angeben. Dieser Speicherort bezieht sich nur auf die Region, in der die Benutzerprofildaten gespeichert werden, während der Rest des Diensts, der Ihre Anmeldung verarbeitet, global ausgeführt wird.
In der Regel stellen Sie einen Azure AD B2C-Mandanten in der Region bereit, die Ihrer Benutzerbasis am nächsten ist. Dies erleichtert die Einhaltung der Datenresidenzgesetze, da das Benutzerprofil nur in der ausgewählten Region repliziert wird. Dies bietet auch die beste Leistung bei der Anmeldung, da Netzwerklatenzen für den Verzeichnisspeicher optimiert werden.
Wenn Ihr Azure AD B2C-Verzeichnis Benutzer weltweit bedienen muss, stellt die regionale Struktur eine Herausforderung dar. Sie müssen bestimmen, an welchem Speicherort der Azure AD B2C-Mandant erstellt werden soll. Benutzer außerhalb der ausgewählten Region sind möglicherweise nicht konform mit den Datenresidenzanforderungen und können auch eine höhere Latenz beim Überprüfen ihrer Anmeldeinformationen oder beim Lesen ihrer Benutzerprofildaten erfahren.
Betrachten Sie beispielsweise eine Anwendung, die Benutzer in Australien und Nordamerika unterstützt, und für die das Azure AD B2C-Verzeichnis in der Region „Nordamerika“ erstellt wird. Benutzer, die sich von Australien aus anmelden, müssen unter Umständen mit längeren Bearbeitungszeiten rechnen, bis ihre Authentifizierung abgeschlossen ist.
Um die Anforderungen an die Datenresidenz besser zu erfüllen und Leistungsprobleme zu minimieren, müssen Sie mehrere Azure AD B2C-Mandanten bereitstellen. Indem in jeder Region, in der Ihr Unternehmen tätig ist, ein Mandant platziert wird, werden die Vorgänge im Verzeichnis für die Latenz optimiert. Dadurch verursacht die Lösung jedoch anderen Aufwand zum Konfigurieren, Verwalten und Schützen dieser vertraulichen Mandantenressourcen in jeder Region. Dieser Mehraufwand umfasst:
Mandantenverwaltung
Isolierung von Mandanten, aus der eine Endbenutzererfahrung resultiert, die nicht den Eindruck von Globalität vermittelt.
Abrechnung
CI/CD-Prozesse zum Verwalten von Richtlinien/App-Registrierungen/Schlüsseln
In diesem Dokument werden Architekturen mit Azure AD B2C vorgeschlagen, die optimale Lösungen für Kunden sind, die Dienste für Benutzer auf der ganzen Welt anbieten. Die Lösung erfüllt folgende Anforderungen:
Benutzer können unabhängig davon, wo auf der Welt sie auf Anwendungen zugreifen, denselben Satz von Anmeldeinformationen verwalten.
Konsistente Leistung und Latenz, unabhängig davon, wo sich Benutzer authentifizieren.
Erleichtern Sie Kunden, für ihre Entwicklerteams Prozesse, Frameworks oder SDKs mit minimaler Konfiguration bereitzustellen.
Benutzerprofile können verwaltet werden, während Benutzer um die Welt reisen. Dies schafft einen Mehrwert in den Analysen, die von Benutzerinteraktionen innerhalb eines beliebigen Diensts generiert werden.
Kundenbenutzerdaten werden in regionalen Datenspeichern gespeichert.
Im Folgenden sind zwei Ansätze aufgeführt, die bei der Implementierung einer Identitätsplattform mit Azure AD B2C-Mandanten für ein global agierendes Geschäftsmodell berücksichtigt werden sollten.
Der erste Ansatz verwendet geografische Regionen als Grenze, und Anwendungen werden speziell für die Region konfiguriert.
Der zweite Ansatz weist eine globale Grenze für die Anwendungen auf und verwendet einen zusätzlichen Azure AD B2C-Mandanten, um die Interaktion zwischen regionalen Mandanten zu orchestrieren.
Regionale Mandantenorchestrierung
In diesem Modell werden Anwendungen entweder pro Region gehostet, oder verfügen über regionale Konfigurationen, um eine Verbindung mit einem regionalen Mandanten herzustellen. Anwendungen senden den Benutzer direkt an einen regionsspezifischen Mandanten. Die mandantenübergreifende Kommunikation wird verwendet, um mandantenübergreifende Authentifizierungen durchzuführen, oder Profilupdates, wenn der Benutzer möglicherweise in eine andere Region gereist ist.
Trichtermandantenorchestrierung
In diesem Modell übergibt ein Azure AD B2C-Mandant Trichterbenutzer an regionale Azure AD B2C-Mandanten. Der Trichtermandant fungiert als Umleitungsorchestrator zu anderen Azure AD B2C-Mandanten. Dies wird von einer global verteilten Komponente des Azure AD B2C-Diensts verarbeitet, sodass die Leistung nicht beeinträchtigt wird. Diese Umleitung wird mithilfe von OpenId Connect-Identitätsanbieterverbunden ausgeführt.
Die mandantenübergreifende Kommunikation wird verwendet, um mandantenübergreifende Authentifizierungen durchzuführen oder Profilupdates mandantenübergreifend durchzuführen. Der Trichtermandant stellt Anwendungen einen einzelnen Endpunkt für die Kommunikation bereit.
Die Architektur, nach der Sie die Lösung modellieren möchten, erfordert Entscheidungen, die auf den Kompromissen zwischen den beiden beschriebenen Modellen basieren. Mit dem Trichtermodell können Sie beispielsweise eine einzelne Instanz von Anwendungen verwalten. Im folgenden Abschnitt werden die Funktionen, Auswahlkriterien und Leistung beschrieben, die die Entwurfsauswahl beeinflussen können.
Funktionen und Überlegungen
In der folgenden Tabelle werden die Funktionen beschrieben, die mithilfe eines regions- bzw. trichterbasierten Designs bereitgestellt werden:
| Funktion | Regionsbasiert | Trichterbasiert |
|---|---|---|
| Unterstützt Registrieren und Anmelden mit lokalen Konten. |
|
|
| Unterstützt Registrieren und Anmelden mit Verbundkonten. |
|
|
| Unterstützt die Authentifizierung lokaler Konten für Benutzer, die sich von außerhalb ihrer registrierten Region anmelden. |
|
|
| Unterstützt die Authentifizierung von Verbundkonten für Benutzer, die sich von außerhalb ihrer registrierten Region anmelden, durch das mandantenübergreifende API-basierte Lookup. |
|
|
| Verhindert die Registrierung aus mehreren verschiedenen Regionen. |
|
|
| Anwendungen in jeder Region verfügen über einen Satz von Endpunkten, mit denen eine Verbindung hergestellt werden kann |
|
|
| Alle Anwendungen stellen unabhängig davon, in welcher Region sie gehostet werden, eine Verbindung mit einer einzelnen Gruppe von Endpunkten her. |
|
|
| Unterstützt differenzierte Richtlinien für bedingten Zugriff. |
|
|
| Kostenoptimiert. |
|
Mit Blick auf die Funktionen müssen Sie Folgendes berücksichtigen:
Bei der Verwendung des regionsbasierten Ansatzes steht die Überlegung im Vordergrund, dass der Ansatz erfordert, dass Anwendungen, die mehrere Regionen umfassen, über entsprechende Konfigurationen für jeden regionalen Azure AD B2C-Mandanten verfügen müssen.
Bei Verwendung des trichterbasierten Ansatzes
Kosten für doppelte Token
Einführung einer zusätzlichen HTTP-Umleitung
Benutzerdefinierte Domänen sind für viele Mandanten erforderlich.
Bedingter Zugriff wird auf Mandantenebene, nicht Anwendungsebene angewendet.
Einmaliges Abmelden über mehrere IdPs kann mit Herausforderungen verbunden sein.
Welchen Ansatz Sie wählen, hängt von der Anzahl der Anwendungen ab, die Sie hosten, und den spezifischen Anforderungen für den Zugriff auf die Anwendungen.
Leistung
Der Leistungsvorteil der Verwendung mehrerer Mandanten in der regions- oder trichterbasierten Konfiguration ist eine Verbesserung gegenüber der Verwendung eines einzelnen Azure AD B2C-Mandanten für global tätige Unternehmen.
Bei Verwendung des trichterbasierten Ansatzes befindet sich der Trichtermandant in einer bestimmten Region und steht Benutzern weltweit zur Verfügung. Da beim Betrieb des Trichtermandanten eine globale Komponente des Azure AD B2C-Diensts verwendet wird, bleibt die Leistung konstant, unabhängig davon, von wo aus sich Benutzer anmelden.
Wie im obigen Diagramm dargestellt, verwendet der Azure AD B2C-Mandant beim trichterbasierten Ansatz nur das Richtlinienmodul, um die Umleitung zu regionalen Azure AD B2C-Mandanten durchzuführen. Die Azure AD B2C-Richtlinienmodul-Komponente ist global verteilt. Daher ist der Trichter aus der Leistungsperspektive unabhängig davon, wo der Azure AD B2C-Trichtermandant bereitgestellt wird, nicht eingeschränkt. Aufgrund der zusätzlichen Umleitung zwischen Trichter und regionalen Mandanten im trichterbasierten Ansatz tritt ein Leistungsverlust auf.
Beim regionalen Ansatz bleibt die Leistung für alle Benutzer, die sich anmelden, konstant, da jeder Benutzer zu seiner am nächsten gelegenen lokalen Azure AD B2C-Instanz weitergeleitet wird.
Die regionalen Mandanten richten Verzeichnisaufrufe an den Verzeichnisspeicher, bei dem es sich sowohl in der trichterbasierten als auch in der regionalen Architektur um die einzige regionalisierte Komponente handelt.
Eine zusätzliche Latenz tritt nur auf, wenn der Benutzer eine Authentifizierung in einer anderen Region durchgeführt hat als der, wo er sich registriert hat. Dies liegt daran, dass Aufrufe regionsübergreifend erfolgen, um den Verzeichnisspeicher zu erreichen, in dem sich das Profil befindet, um die Authentifizierung abzuschließen.
Nächste Schritte
Proof of Concept der regionsbasieren Konfiguration globaler Azure AD B2C-Identitäten
Proof of Concept der trichterbasieren Konfiguration globaler Azure AD B2C-Identitäten
Erstellen einer globalen Identitätslösung mit dem trichterbasierten Ansatz
Erstellen einer globalen Identitätslösung mit dem regionsbasierten Ansatz