Microsoft bietet mit dem Azure Active Directory (Azure AD) seit geraumer Zeit einen Benutzerverwaltungsdienst für Unternehmen in der Cloud an. Allerdings ist dieser für die Verwaltung von Benutzern einer Website nicht gut geeignet, da eine Self-Service Registrierungsmöglichkeit fehlt. Benutzer werden stattdessen durch einen Administrator verwaltet. Neue Benutzer können sich nicht selbst einen Account anlegen. Braucht man diese Möglichkeit für eine Website, war man bisher auf Drittlösungen oder eine Eigenentwicklung angewiesen. Man konnte z. B. den Thinctecture IdentityServer einsetzen, ein OpenSource-Projekt zur Implementierung von Identitätsdiensten. Seit September 2015 gibt es auch einen Azure-Dienst für diesen Zweck – Azure AD B2C; aktuell noch als Public Preview.

Azure AD B2C bringt im Vergleich zum „klassischen“ Azure AD die Möglichkeit mit, dass sich Benutzer selbst registrieren können. Und somit wird das Ganze für Consumer Web-Anwendungen nutzbar. Der Aufwand für die Entwicklung einer Benutzerverwaltung entfällt.

Azure AD B2C ist als Azure Service hochverfügbar und global erreichbar ausgelegt. Es bietet eine leicht verständliche Benutzeroberfläche zur Benutzerverwaltung und für die Konfiguration der Authentifizierungsaspekte. Der Entwickler, der den Dienst für seine Anwendung nutzen möchte, braucht diesen nur mit etwas Konfiguration und wenigen Zeilen Code in seine Applikation zu integrieren.

Voraussetzung ist wie immer, dass eine Azure Subscription zur Verfügung steht. Wichtig zu wissen ist, dass ein bestehendes Azure AD nicht um die B2C-Option erweitert werden kann. Genauso wenig kann ein einmal erstelltes Azure AD B2C in ein konventionelles Azure AD umgewandelt werden. Die Wahl der B2C-Option steht ausschließlich bei der Anlage des Verzeichnisses zur Verfügung. Es herrscht offensichtlich eine starke Trennung zwischen Unternehmens- und B2C-Verzeichnissen.

Alsdann lässt sich in vier wesentlichen Schritten die Integration des Azure AD B2C in die eigene Anwendung vollziehen:

1. Anlegen des Verzeichnisses als Azure AD B2C
2. Registrieren der Anwendung im Azure AD B2C
3. Festlegen von Policies für Registrierung, Anmeldung, Profilverwaltung und Passwort-Reset
4. Integration in den Code und die Konfiguration der Anwendung

Azure AD B2C Verzeichnis anlegen

Die Benutzeroberfläche für Anlage und Management des Azure AD B2C teilt sich noch auf die beiden Azure-Portale (klassisch und neu) auf. So legt man zunächst im klassischen Azure-Portal ein neues Active Directory-Verzeichnis an und wählt dabei die B2C-Option:

Danach erhält man in der Konfigurationsansicht des neu angelegten Verzeichnisses einen Link zu den B2C-Einstellungen, der ins neue Azure-Portal führt:

Man befindet sich dort nun direkt im neu angelegten Azure AD des B2C-Mandanten, wie man an den Daten des angemeldeten Benutzers oben rechts erkennen kann. Das neue Verzeichnis befindet sich auch in der Liste aller anderen Verzeichnisse, auf die man mit dem angemeldeten Benutzer Zugriff hat. Somit ist es leicht, zwischen allen Verzeichnissen zu wechseln, und das nicht nur zwischen den Unternehmensverzeichnissen.

Anwendung registrieren

Sofern man direkt vom klassischen Azure-Portal gekommen ist, werden die Azure AD B2C Einstellungen direkt geöffnet. Anderenfalls kann man diese Einstellungen über den Link “Azure AD B2C” unter “Durchsuchen” öffnen. Die Registrierung der Anwendung nimmt man im Bereich “Applications” vor:

Schließt die Anwendung eine serverseitige Komponente ein, stellt man “Include web app / web API” auf “Yes” und legt mindestens eine Redirect URI fest. Das ist die URI, an die Azure AD B2C nach erfolgreicher Benutzerauthentifizierung das Benutzer-Token sendet. Azure AD B2C leitet den Browser des Benutzers nach erfolgreicher Authentifizierung zu dieser URI um.

Zur Erhöhung der Sicherheit empfiehlt es sich, einen Key zu generieren, der bei der Nutzung der serverseitigen Komponente mitgegeben werden muss.

Schließt die Anwendung einen nativen Client ein, z. B. eine mobile App, ist “Include native client” auf “Yes” zu stellen.

Nachdem man das Anlegen der Anwendung im Azure AD B2C mit “Create” abgeschlossen hat, findet man in den Details der erstellten Anwendung deren Application Client ID:

Die Application Client ID und den zuvor generierten Key braucht man später im Code bzw. der Konfiguration der eigenen entwickelten App, die Azure AD B2C benutzen soll.

Eine aktuelle Einschränkung des Azure AD B2C erfordert für alle Anwendungsbestandteile dieselbe Application Client ID. Das bedeutet, dass Client- und Serverseite der Anwendung aus Sicht des Azure AD B2C eine Einheit bilden. Es ist also nicht möglich, andere Apps mit derselben Serverseite kommunizieren zu lassen, z. B. 2 Apps teilen sich einen Web Service.

Policies festlegen

Mittels Policies wird definiert, was ein Benutzer tun kann und auf welche Art und Weise. Soll sich ein Benutzer selbst registrieren können, braucht es mindestens eine Sign-up Policy. Für die Anmeldung des Benutzers braucht es mindestens eine Sign-in Policy. Soll der Benutzer sein Profil selbst verwalten können, z. B. für die Änderung der E-Mail-Adresse, braucht es mindestens eine Profile Editing Policy. Das gilt analog für das Zurücksetzen des Benutzerpassworts. Ist ein Policy-Typ nicht angelegt, steht die korrespondierende Funktionalität dem Benutzer nicht zur Verfügung.

Eine Policy kann man sich als Container für einen Satz von Einstellungen vorstellen, der für die korrespondierende Funktionalität gelten soll.

Dazu gehören Identity Providers, z. B. Google oder Facebook. Man kann also seinen Benutzern erlauben, sich mit ihren Social Network Accounts zu registrieren und sich mit diesen anzumelden. Vorteil für den Benutzer ist, dass er sich keine weiteren Zugangsdaten merken muss.

Weiterhin kann man in einer Policy definieren, welche Benutzerattribute bei der Registrierung abgefragt werden sollen oder welche der Benutzer im Rahmen seiner Profilverwaltung bearbeiten kann, z. B. Adressinformationen oder Namen. Die Benutzerinformationen, die an eine Anwendung aus dem Azure AD B2C zurückgegeben werden sollen, so genannte Claims, definiert man ebenfalls innerhalb einer Policy.

Des Weiteren wird die Gültigkeitsdauer von Authentifizierungen, also der Benutzer-Tokens, in einer Policy festgelegt. Oder auch die Ablaufdauer von Benutzer-Sessions. Aus Sicherheitsgründen auch interessant ist die Möglichkeit, Multi-Factor Authentication zu nutzen, d. h. der Benutzer muss sich zusätzlich zu Benutzername und Passwort mit einem Code authentifizieren, der ihm per SMS oder Anruf mitgeteilt wird.

Damit die Web-Formulare, die der Benutzer zu sehen bekommt, dem Look and Feel der Anwendung entsprechen, lassen sich diese ebenfalls innerhalb der Policy definieren. Dabei kann man sogar die URI festlegen, die auf die Custom Page zeigt. Details zum Customizing dieser Web-Formulare kann man in dem Artikel über Azure AD B2C UI Customization nachlesen.

Welche Policy zum Einsatz kommt, bestimmt die Anwendung, die je nach Geschäftslogik bei den jeweiligen Requests an das Azure AD B2C den Namen der gewünschten Policy mitgibt.

Code und Konfiguration der Anwendung

Was bleibt, ist die eigene Anwendung für die Nutzung des Azure AD B2C anzupassen.

Die Kommunikation mit dem Azure AD B2C geschieht mittels gesicherter HTTP Requests. Für serverseitige .NET-Applikationen, wie Web Apps und Web APIs, unterstützt hierbei Microsofts OWIN-Bibliothek, die über NuGet in die eigene Anwendung eingebunden werden kann. Wie das im Detail geht, kann man im Artikel “Build a .NET web app” nachlesen.

Für Single Page Applications (JavaScript) habe ich noch keine entsprechenden Libraries gefunden.

Für Xamarin.Forms Applikationen existiert seit kurzem ein GitHub-Projekt mit einer Beispielanwendung, die sicher einen Blick wert ist.

Die Unterstützung weiterer Plattformen wie natives Android und natives iOS sowie NodeJS gibt es von Microsoft Schnellstartanleitungen.

Zur Automatisierung der Benutzerverwaltung lässt sich die Azure AD Graph API verwenden. Über eine Web Service Schnittstelle lassen sich so Benutzer anlegen, bearbeiten und löschen.

Kosten

Azure AD B2C ist noch im Preview-Status und kostenlos verfügbar. Das Preismodell, welches nach Verlassen des Preview-Status gilt, kann man aber schon nachlesen. Die beiden monatlichen Größen, nach denen abgerechnet werden wird, sind Anzahl der Nutzer, die im Verzeichnis gespeichert werden, sowie die Anzahl an Authentifizierungen oder Token-Aktualisierungen, die im Azure AD B2C durchgeführt werden.

Die ersten 50.000 Benutzer sind kostenlos. Darüber hinaus zahlt man pro Benutzer zwischen 0,00093 und 0,00067 EUR, je nach Menge. Ähnlich sieht es bei den Authentifizierungen aus. Hier sind ebenfalls die ersten 50.000 im Monat frei. Danach kosten sie 0,00236 bis 0,00118 EUR pro Authentifizierung. Multi-Factor Authentication kostet pauschal oben drauf 0,0253 EUR pro Authentifizierung. Für Microsoft Enterprise Agreements können besondere Preise erfragt werden.

Berechnungsbeispiel für 100.000 Benutzer, die sich täglich anmelden:

• (100.000 – 50.000) x 0,00093 EUR = 46,50 EUR für die verwalteten Benutzer
• (100.000 – 50.000) x 0,00236 EUR x 31 Tage = 3.658,- EUR für die Authentifizierungen

Für dieses Szenario ergäben sich also 3.704,50 EUR an monatlichen Kosten.

Fazit

Microsoft Azure AD B2C kostet Geld, erspart jedoch eine Menge Arbeit und macht die Verwaltung von sensiblen Benutzerdaten sicherer, als man es selbst umsetzen könnte. Es ist global und hochverfügbar. Durch die Einbindung von Social Network Identity Providern wird dem Benutzer die Anlage eines weiteren Accounts im Internet erspart. Die Gefahr, die von der Verwendung immer gleicher Passwörter – aus Bequemlichkeit – auf verschiedenen Websites ausgeht, ist dadurch gebannt. Die Benutzerdaten an sich werden nicht in der eigenen Anwendung gespeichert, und so ist die eigene Anwendung kein weiteres Ziel für Angreifer. Diese interessieren sich meist nicht für die Daten der eigenen Anwendung, sondern viel mehr für die Benutzeridentitäten. Wenn die nicht in meiner eigenen Anwendung liegen, kann ich besser schlafen.