Links
Screencast
Vorbemerkungen
Dieser erste Teil der Serie kümmert sich um ein paar theoretische Grundlagen und die Einrichtung. In kommenden Teilen werde ich immer detaillierter in die Konfiguration und Nutzung des Produktes einsteigen.
Was ist Azure AD B2C (AAD B2C)?
Zunächst einmal ist ein AAD B2C nichts anderes als ein Tenant in Azure, den man zu einer bestehenden Subscription hinzufügen kann. Auch ist zu erwähnen, dass man durchaus mehrere AAD B2C in einer Subscription anlegen kann.
Der Frage nach dem Was kann man sich wahrscheinlich am einfachsten über die Frage nach dem Warum nähern.
Anhand des Namensteils “B2C” (business to customer) kann man bereits ableiten, dass das Produkt vor allem für Firmenkunden interessant ist. Das Problem ist nun, dass Firmen (wenn sie Azure nutzen) einen sogenannten Tenant besitzen. Das ist sozusagen das Root-Element in Azure an dem letztlich alle anderen Dinge (Subscriptions, User, Ressourcen usw.) hängen. Für alle Intranet-Produkte kann man nun das vorhandene AAD nutzen, um Dinge, wie Authentifizierung durchzuführen.
Probleme entstehen allerdings, wenn man Ressourcen mit einbeziehen möchte, die nichts im eigenen Tenant zu suchen haben. In 90% der Fälle reden wir übrigens im Kontext von AAD bei “Ressourcen” von Benutzern. Will man also z.B. eine Website so absichern, dass auch Personen Zugriff erhalten, die keine Mitarbeiter sind, steht man plötzlich vor 2 Möglichkeiten:
- Wir nehmen diese Personen in das eigene AAD auf.
- Wir schaffen eine vom eigenen AAD getrennte Möglichkeit der Verwaltung von Identitäten.
Variante 1 ist eher als Hack denn als Lösung zu interpretieren. Jeder halbwegs vernünftige Admin wird sich die Haare ausreißen, wenn wir ihm mit der Idee kommen, potentiell Millionen von Benutzern in das AAD der Firma aufzunehmen.
AAD B2C ist nun das Produkt für Variante 2. Anstatt, dass wir anfangen, mit gesundem Halbwissen eine eigene Authentifizierungs-Plattform aufzubauen, nutzen wir diesen Dienst von Azure.
B2C Tenant einrichten
Um ein AAD B2C einzurichten, benötigt man im ersten Schritt eine gültige Azure Subscription und darin wiederum entsprechende Rechte. Ich gehe im Folgenden davon aus, dass dies alles vorhanden ist. Ich werde die folgenden Erklärungen immer anhand des Azure Portals erklären.
Man sollte sich vorsorglich schon einmal eine Ressource group anlegen. Für den ersten Schritt spielt diese noch keine Rolle. Was wir hier tun, ist die Erzeugung eines neuen speziellen Azure-Tenants. Dieser Tenant kann natürlich nicht in einer Ressource Group eines anderen Tenants liegen. Die spätere Zuordnung des neuen Tenants zu unserer Subscriptions braucht aber diese Ressource Group.
Es reicht also, im Portal auf “Create a resource” zu klicken und dann das Product “Azure Active Directory B2C” (sucht nach “B2C”) hinzuzufügen.
Der Einrichtungs-Assistens startet mit folgender Auswahl:
Zunächst gilt es, die erste Option “Create a new Azure AD B2C Tenant” zu wählen. Sobald man das anklickt, erscheint ein Blade für die Angabe von Tenant-Name, Domain-Präfix und Region:
Hier gilt es vor allem bei der Angabe der Region aufzupassen. Die Auswahl bestimmt, in welchem Rechenzentrum der neue Tenant angelegt wird und damit auch, wo spätere Benutzer-Informationen abgelegt werden. Als deutsches Unternehmen würde ich beispielsweise erst einmal “Germany” auswählen, egal, woher die eigentlichen Logins etc. später erfolgen.
Ich habe in Abb. 2 grün den sogenannten Domain Name des Tenants markiert. Alle späteren Referenzen auf das B2C benötigen diesen Namen und interessieren sich nicht für den Organization name.
Nach einem Klick auf “Create” beginnt Azure zu arbeiten und nach ca. 1-2 Minuten steht der neue Tenant bereit.
Tenant-Anmeldung im Portal ausprobieren
Die Einrichtung ist noch nicht abgeschlossen. Trotzdem ist der Tenant bereits vorhanden und wir können uns an ihm anmelden. Damit man das nachvollziehen kann, sollte man das Portal-Browserfenster übrigens einmal aktualisieren, weil der neue Tenant sonst nicht auswählbar ist. Nach einem beherzten “F5” im Browser kann ich nun die Tenant-Auswahl öffnen und in den neuen Tenant wechseln:
Im Screenshot ist zu sehen, dass ich aktuell in meinem Tenant “DEVDEER” angemeldet bin, in dem ich das AAD angelegt habe. Durch Klick auf “codingfreaks” wechsle ich nun in den neuen Tenant. Nach einiger Ummelderei sieht man dann oben rechts, ob alles geklappt hat:
Hier ist es nun interessant, sich das B2C einmal auch anzusehen. Klickt man im Hauptmenu auf “All services” und sucht dann nach “B2C”, kann man in die Verwaltung des AAD B2C wechseln. An dieser Stelle empfiehlt es sich, den Favoriten-Stern anzuklicken, um zukünftig B2C direkt im Hauptmenu zu haben.
Das Blade für das B2C kann übrigens nach der Einrichtung des Tenants noch einige Minuten (im schlimmsten Fall auch Stunden :-() vor sich hin überlegen, bevor man es einsehen kann. In jedem Fall sollte irgendwann ein Screen wie der Folgende erscheinen:
Diese Warnung ist im aktuellen Statium korrekt, weil wir den zweiten Schritt aus Abb. 1 noch nicht durchgeführt haben. Mit anderen Worten haben wir zwar nun einen B2C-Tenant, dieser kann jedoch aktuell noch gar nichts tun, weil ihm die Verbindung zu einer Subscription fehlt.
Hier haben wir einen wichtigen Unterschied zwischen AAD und AAD B2C. Jedes Unternehmen mit einem AAD-Tenant kann diesem beliebig viele Subscriptions zuordnen. Der AAD-Tenant ist aber auch ohne Subscriptions voll funktional.
Ein B2C-Tenant auf der anderen Seite ist eine abrechenbare Ressource und muss daher mit einer bestehenden Subscription verbunden werden. Diese wiederum muss logischerweise in einem Tenant liegen (kann nur ein AAD-Tenant sein).
Das zeigt schön, dass ein AAD B2C nicht einfach ein neues AAD ist.
Einrichtung abschließen
Zunächst gilt es nun, zurück in den AAD-Tenant zu wechseln, in dem wir den B2C-Tenant angelegt haben. Dazu muss ich in meinem Fall die Tenant-Auswahl öffnen und “DEVDEER” aus Abb. 3 auswählen.
Jetzt kommt der gewöhnungsbedürftige Teil. Man wählt erneut “Create a resource” und sucht wieder nach “Azure Active Directory B2C”. Wenn die Auswahl aus Abb. 1 wieder erscheint, wählt man nun aber “Link an existing Azure AD B2C Tenant to my Azure subscription”.
Nach einem Klick auf “Create” und ca. 30 Sekunden Wartezeit kann man nun in die zuvor ausgewählte Ressource Group wechseln:
Klickt man diese Ressource an, gelangt man zur Ansicht der Verknüpfung in dieser Subscription und NICHT zu dem Tenant selbst! Hier können wir uns aber bereits wichtige Informationen holen:
Ich habe mal markiert, dass man im Overview noch einmal den Domain name und die ID des B2C-Tenants in Erfahrung bringen kann und dass sich hier die Löschfunktion befindet.
Über “Properties” kann man auch noch weitere Details über den Tenant in Erfahrung bringen.
Das Löschen der Registrierung an dieser Stelle würde übrigens nur dazu führen, dass man die Verknüpfung zwischen der Subscription und dem B2C-Tenant entfernt, nicht aber den Tenant selbst. Das ist so eine Sache für sich und ich werde es daher in einem der kommenden Teile behandeln.
Tenant testen
Wechselt man nun wieder in den B2C-Tenant und dort in den Menupunkt “Azure AD B2C”, sollte die Warnung aus Abb. 6 nicht mehr auftauchen.
Interessant ist, dass man auch in diesem Tenant den Menupunkt “Azure Active Directory” hat. Sieht man sich in diesem Menu im Blade “Properties” die Directory ID an, stellt man fest, dass dieses AAD nichts anderes ist, als unser neues AAD B2C. Manche Funktionen sind nun verwirrenderweise doppelt vorhanden. Zur besseren Veranschaulichung habe ich mal die Menus der beiden Blades “Azure Active Directory” (links) und “Azure AD B2C” (rechts) nebeneinander gestellt:
Users und App registrations/Applications zeigen im Falle eines AAD-B2C-Tenants im Prinzip auf das Gleiche. Wir werden das im weiteren Verlauf dieser Serie noch tieger behandeln.
Fazit und Ausblick
Dieser erste Teil hat nun erfolgreich ein AAD B2C eingerichtet und es mit einer bestehenden Subscription meines Unternehmens verbunden. Wir sind jetzt bereit für den nächsten Schritt. Wir müssen die Grundeinstellungen des B2C verstehen und vornehmen.