Die Microsoft Identity Platform 2.0 erlaubt das Erstellen von Anwendungen, bei denen sich Nutzer mit ihrer Microsoft-Identität oder Social-Media-Konten anmelden. Die Autorisierung funktioniert dabei für Microsoft-APIs wie Microsoft Graph sowie eigene APIs gleichermaßen.
Die Identity Platform hilft Entwicklerinnen und Entwicklern, beim Erstellen von Anwendungen auf einfache Weise eine Ebene der Benutzeranmeldung zu implementieren. Sie erlaubt Anwendungen sogar das Anfordern von Token zum Aufrufen von APIs. Konkret besteht die Microsoft Identity Platform aus mehreren Komponenten. Dazu gehört in erster Linie ein standardkonformer OAuth-2.0- und OpenID-Connect-Authentifizierungsdienst, der die Authentifizierung mehrerer Identitätstypen ermöglicht, darunter …
- via Azure AD bereitgestellte Organisationskonten
- persönliche Microsoft-Konten (Skype, Xbox und Outlook.com)
- Social Media- oder lokale Konten (Im Zusammenhang mit der Verwendung von Azure AD B2C).
Ebenfalls zur Identity Platform gehören eine Reihe von Open-Source-Bibliotheken wie die Microsoft Authentication Libraries (MSAL) und viele andere standardkonforme Bibliotheken. Ferner gehört ein Verwaltungsportal für Anwendungen zur Identity Platform, hier lassen sich also Anwendungen komfortabel registrieren und konfigurieren.
Eine API zur Anwendungskonfiguration fällt ebenfalls ins Leistungsspektrum. Sie erlaubt eine programmatische Konfiguration von Anwendungen wahlweise über die Microsoft Graph-API oder PowerShell. So lassen sich z. B. auch DevOps-Workflows gut automatisieren. Schließlich erhalten Developer kompletten Zugriff auf die technische Dokumentation mit Quickstarts, Tutorials, Schrittanleitungen und Codebeispielen.
Protokolle und Bibliotheken
Die Microsoft Identity Platform unterstützt alle wichtigen Industriestandardprotokolle wie OAuth 2.0 und OpenID Connect. Mit dem Vorgängerlösung (Azure AD v1.0) konnten Entwickler nur MS-Organisationskonten durch Anfordern von Token mithilfe der Azure AD Authentication Library (ADAL) via Azure-Portal, der Azure AD Anwendungsregistrierung/-konfiguration oder der Microsoft Graph API für die programmgesteuerte Anwendungskonfiguration authentifizieren.
Mit der neueren einheitlichen Microsoft-Identitätsplattform (v2.0) müssen Sie nur einmal Code schreiben, um jede Art von Microsoft-Identität authentifizieren zu können. Microsoft empfiehlt jedoch das Verwenden der Authentifizierungsbibliothek (MSAL) mit den Identitätsplattform-Endpunkten, denn die MSAL ist einfach bedienbar und liefert Ihren Endbenutzern schnell die gewünschte Single-Sign-On (SSO)-Erfahrung. Das Zusammenspiel von Azure AD für Entwickler (v. 1.0) und Microsoft Identity Platform illustriert nebenstehenden Abbildung von Microsoft:
De beschriebenen Architekturen verwenden allesamt branchenübliche Protokolle wie OAuth 2.0 und OpenID Connect. Letztlich authentifizieren Anwendungen die Identitäten mit Hilfe der Verwendung der Authentifizierungsbibliotheken für die Microsoft Identity Platform und rufen ggf. vom Azure AD Token für den Zugriff auf geschützte APIs ab.
Microsoft illustriert in seiner Dokumentation zu Azure AD Identity Platform anhand einer gut gemachten Grafik die heute üblichen App-Szenarien mit ihren jeweiligen Identitätskomponenten. Das Hauptaugenmerk dürfte dabei in den meisten Fällen auf Single-Page-Webanwendungen (SPA), Web-Apps und Web-APIs liegen. In Gänze unterstützt die Microsoft Identity Platform Authentifizierung für Single-Page-Apps, Web-Apps, Web-APIs, Mobile Apps, Native Apps, Daemon-Apps, und Server-seitige Apps.
Token lassen sich also von verschiedenen Arten von Anwendungen oder auch von Apps auf Geräten abrufen, die keinen Browser haben, etwa bei IoT-Geräten. Somit bestehen die meisten Authentifizierungsszenarien aus zwei Vorgangsarten, nämlich dem Abrufen von Sicherheitstoken für eine geschützte Web-API, wie die von Microsoft entwickelte und unterstützte Microsoft Authentication Library (MSAL), sowie das Schützen einer Web-API oder einer Web-App durch Überprüfung des Sicherheitstokens.
Bei den weitaus meisten Authentifizierungsszenarien werden Token im Namen angemeldeter Benutzer abgerufen. Es gibt aber auch Szenarien mit Daemon-Apps, die Token für sich selbst (nicht im Auftrag eines Benutzers) abrufen. Für eine grobe Klassifizierung lassen sich also Single-Page-Webanwendungen, öffentliche Clientanwendungen und vertrauliche Clientanwendungen unterscheiden. Zu Letzteren zählen wie die Abbildung oben illustriert Web-Apps, die eine Web-API aufrufen, Web-APIs, die eine Web-API aufrufen und Daemon-Apps.
Autorisierung versus Autorisierung
Bevor Sie loslegen, sollten Sie sich die Grundlagen von Autorisierung (oft AuthZ genannt) und Authentifizierung (AuthN) im Web-Umfeld in Erinnerung rufen. Mit Autorisierung legen Sie Berechtigungen fest, die zum Auswerten des Zugriffs auf Ressourcen oder Funktionen verwendet werden. Derweil wird die Authentifizierung genutzt, um zu bestätigen, dass eine Entität (beispielsweise ein Benutzer oder ein Dienst) tatsächlich die Entität ist, für die sie sich ausgibt.
Für die Developer vereinfacht die Microsoft Identity Platform die Autorisierung und Authentifizierung, weil sie die erforderlichen Funktionen quasi via „Identity-as-a-Service“ nutzen können. Für „moderne Anwendungen“ kommen dabei nur Kombinationen aus HTTP-basierenden Protokollen und Verfahren wie OpenID Connect, OAuth oder SAMl in Frage. Die Microsoft Identity Platform unterstützt drei Kombinationen:
- 1. OAuth und OpenID Connect: Die Plattform nutzt OAuth für die Autorisierung und OpenID Connect (OIDC) für die Authentifizierung, wobei OIDC im Prinzip auf OAuth aufsetzt, beide Verfahren also einen durchaus ähnlichen Flow haben. Im Prinzip könnten Sie sogar mit nur einer Anforderung gleichzeitig einen Benutzer authentifizieren (via OpenID Connect), als auch den Zugriff auf eine geschützte Ressource autorisieren (via OAuth 2.0), die sich im Besitz des Benutzers befindet.
- 2. OAuth und SAML: Die Plattform nutzt OAuth 2.0 für die Autorisierung und SAML für die Authentifizierung. Man spricht dann von SAML Bearer Assertion Flow.
- 3. OpenID Connect und SAML: Die Plattform verwendet gleichermaßen OpenID Connect und SAML zum Authentifizieren eines Benutzers und zum Aktivieren von SSO. Die SAML-Authentifizierung wird häufig mit Identitätsanbietern wie Active-Directory-Verbunddienste (AD FS) im Verbund mit Azure AD verwendet, während OpenID Connect häufig für Apps verwendet wird, die sich ausschließlich in der Cloud befinden, z. B. mobile Apps, Websites und Web-APIs.
Für die Praxis ist es hilfreich, wenn Sie den Unterschied im Flow/Handshake zwischen SAML und OIDC sowie den Unterschied zwischen einer XML-basierenden SAML Assertion und einem JSON-Webtoken kennen – und wenn Sie eine Idee davon haben, was man unter einem Claim (Anspruch) versteht. Allerdings sprengt eine weitere Ausführung den Rahmen des Beitrags und ist für das folgende Einführungsbeispiel auch nicht zwingend. Weitere Erläuterungen zu SAML, ODIC oder JWT finden Sie aber beim Security-Insider.
Einführungsbeispiel Web APP
Erstellen Sie nun im Azure Portal eine einfache WebApp (Azure App Service) mit einer Runtime Ihrer Wahl, z. B. .Net/ASP, PHP, Node.JS, Java oder Python. Wie das funktioniert, haben wir schon einige Male erläutert. Um Ihre Web App mit einer Authentifizierungsebene navigieren Sie „in“ ihre WebApp-Ressource und klicken links im Abschnitt „Einstellungen“ auf „Authentifizierung“ und dort auf die Schaltfläche „Identitätsanbieter hinzufügen“. Wählen Sie dann im Tab „Grundlagen“ in der Liste bei „Identitätsanbieter“ einen Passenden aus.
Zur Wahl stehen „Microsoft“, „Apple“, „Facebook“, „GitHub“, „Google“, „Twitter“ und „OpenIP Connect“. Wählen Sie z. B. „Microsoft“. Wählen Sie dann bei „App-Registrierungstyp“ den Eintrag „Neue App-Registrierung erstellen. Bei „Unterstützte Kontotypen“ nehmen wie nur der Einfachheit halber „Aktueller Mandant – einzelner Mandant“, d. h. der Endnutzer Ihrer App müssten über ein Konto in Ihrem eigenen Azure-AD-Verzeichnis verfügen.
Für einen öffentliche Client-App ist das natürlich ein wenig wahrscheinliches Szenario. Hier würden Sie vermutlich eher „Beliebiges Azure AD-Verzeichnis und persönliche Microsoft-Konten“ nutzen. Bei „Zugriff einschränken“ lassen Sie es beim Default-Eintrag „Authentifizierung erforderlich“. Da wir es hier es bei einer Azure Web App mit einem Microsoft Paas-Dienst zu tun haben, können und müssen Sie beim „Umleiten zu“ nichts eingeben, d. h. der Default-Eintrag „Microsoft“ bleibt ausgegraut.
Klicken Sie dann auf „Weiter: Berechtigungen“. Hier geht es zunächst darum, welchen Berechtigungen ein Benutzer Ihrer App bei der ersten Anmeldung zustimmen muss. Wir belassen es bei der Microsoft-Empfehlung „User.Read“ für „Sign in and read user profile“. Weitere Einzelheiten zur Graph-API in den Microsoft-Docs.
Klicken Sie dann auf „Hinzufügen“. Sie haben nun eine Identität für Ihre Web App im Azure AD erzeugt. Dies können Sie an verschiedenen Stellen verifizieren. Im Blade „Authentifizierung“ Ihrer Web App selbst wurde jetzt ein Identitätsanbieter mit dem Namen „Microsoft“ hinzugefügt. Außerdem sehen Sie hier die „Client-ID“ Ihrer App-Registrierung.
Darüber hinaus können Sie im Azure-Portal nach „App-Registrierungen“ suchen. Wechseln Sie hier um Tab „Anwendungen mit Besitzer“. Alternativ können Sie auch in Azure-AD-Blade auf „App-Registrierungen“ klicken.
Folgen Sie nun dem Link zu Ihrer neuen App-Registrierung, landen Sie auf der Startseite der Microsoft Identity Platform. Im oberen Teil der Übersichtseite finden Sie dann auch die „Anwendungs-ID (Client)“, die „Object ID“, die „Verzeichnis-ID“ und vor allem die „Clientanmeldeinformationen“. Hier ist zu erkennen, dass automatisch „1 Geheimnis“ erzeugt wurde.
Dieses Geheimnis sehen Sie auch, wenn Sie im Hauptmenü auf „Zertifikate & Geheimnisse“ klicken. Hier zeigt der Tab „Geheime Clientschlüssel“, dass ein neues Geheimnis mit Geheimnis-ID und Wert angelegt wurde. Das Geheimnis ist letztlich die geheime Zeichenfolge (Anwendungspassword), welche Ihre Anwendung verwendet, wenn sie ein Token als Identitätsnachweis vom Azure AD abruft.