Azure Web Apps mit einer Authentifizierungs-Ebene ausstatten
Die Microsoft Identity Platform 2.0 richtet sich an Entwickler und hilft beim Erstellen von Anwendungen, bei denen sich Nutzer mit ihren eigenen Microsoft-Identitäten oder Social-Media-Konten anmelden. In diesem Zusammenhang können Entwickler nicht nur den Zugriff auf Microsoft-APIs wie Microsoft Graph, sondern auch auf ihre eigenen APIs mit einer Autorisierung verknüpfen. Besonders einfach funktioniert das für den Einstieg mit den Azure App Services.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Die Identity Platform hilft dir als Entwickler, beim Erstellen von Anwendungen auf einfache Weise eine Ebene der Benutzeranmeldung zu implementieren. Sie erlaubt Anwendungen auch das Anfordern von Token zum Aufrufen von APIs wie z. B. Microsoft Graph oder APIs, die du als Entwickler erstellt hast. 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 dir 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, d. h. du kannst hier komfortabel Anwendungen registrieren und konfigurieren. Außerdem gib es eine Anwendungskonfigurations-API. Sie erlaubt eine programmatische Konfiguration deiner Anwendungen wahlweise über die Microsoft Graph-API oder PowerShell. So lassen sich z. B. auch DevOps-Workflows gut automatisieren. Schließlich erhältst du als Entwickler 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 der Vorgängerlösung (Azure AD v1.0-Plattform) konnten Entwickler nur MS Organisationskonten (Azure AD) durch Anfordern von Token vom einem Azure AD v1.0-Endpunkt 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) musst du 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:
Die 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, wobei das Hauptaugenmerk in den meisten Fällen bei Single-Page-Webanwendungen (SPA), Web-Apps und Web-APIs liegen dürfte. In Gänze unterstützt die Identity Plattform Microsoft Identity Platform Authentifizierung für Single-Page-Apps, Web-Apps, Web-APIs, Mobile Apps, Native Apps, Daemon-Apps, und Serverseitige Apps.
Token können also von verschiedenen Arten von Anwendungen oder auch von Apps auf Geräten abgerufen werden, 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 https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview Microsoft Authentication Library (MSAL) und das Schützen einer Web-API oder einer Web-App durch Überprüfung des Sicherheitstokens.
Bei den meisten Authentifizierungsszenarien werden Token im Namen angemeldeter Benutzer abgerufen. Es gibt aber auch Szenarien mit Daemon-Apps, die Anwendungen 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 du loslegst, solltest du dir die Grundlagen von Autorisierung (oft AuthZ genannt) und Authentifizierung (AuthN) im Web-Umfeld in Erinnerung rufen. Mit Autorisierung legst du Berechtigungen fest, die zum Auswerten des Zugriffs auf Ressourcen oder Funktionen verwendet werden, während die Authentifizierung genutzt wird, 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 dich als Anwendungsentwickler vereinfacht die Microsoft Identity Platform die Autorisierung und Authentifizierung, weil du die erforderlichen Funktionen quasi via „Identity-as-a-Service“ nutzen kannst. 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:
- 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 kannst du 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.
- OAuth und SAML: Die Plattform nutzt OAuth 2.0 für die Autorisierung und SAML für die Authentifizierung. Man spricht dann von SAML Baererassertionsflow.
- 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 du den Unterschied im Flow/Handshake zwischen SAML und OIDC kennst, sowie den Unterschied zwischen einer XML-basierenden SAML Assertion und einem JSON-Webtoken und wenn du eine Idee davon hast, was man unter einem Claim (Anspruch) versteht. Allerdings sprengt eine weitere Ausführung des Rahmen des Beitrags und ist für das folgende Einführungsbeispiel auch nicht zwingend.
Einführungsbeispiels Web APP
Erstelle 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 deine Web App mit einer Authentifizierungsebene azszustatten, navigiere „in“ deine WebApp-Ressource und klicke links im Abschnitt „Einstellungen“ auf „Authentifizierung“ und dort auf die Schaltfläche „Identitätsanbieter hinzufügen“. Wähle 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ähle z. B. „Microsoft“. Wählst dann bei „App-Registrierungstyp“ den Eintrag „Neue App-Registrierung erstellen. Bei „Unterstützte Kontotypen“ nehmen wir der Einfachheit halber „Aktueller Mandant – einzelner Mandant“, d. h. der Endnutzer deiner App müsste über ein Konto in deinem eigenen Azure-AD-Verzeichnis verfügen. Für eine öffentliche Client-App ist das natürlich ein wenig wahrscheinliches Szenario. Hier würdest du vermutlich eher „Beliebiges Azure AD-Verzeichnis und persönliche Microsoft-Konten“ nutzen. Bei „Zugriff einschränken“ lasse es beim Default-Eintrag „Authentifizierung erforderlich“.
Da wir es hier es bei einer Azure Web App mit einem Microsoft Paas-Dienst zu tun haben, kannst und musst du beim „Umleiten zu“ nichts eingeben, d. h. der Default-Eintrag „Microsoft“ bleibt ausgegraut.
Klicke dann auf „Weiter:Berechtigungen“. Hier geht es zunächst darum, welchen Berechtigungen ein Benutzer deiner 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 findest du https://docs.microsoft.com/en-us/graph/use-the-api hier.
Klicke dann auf „Hinzufügen“. Du hast nun eine Identität für deine Web App im Azure AD erzeugt. Dies kannst du an verschiedenen Stellen verifizieren. Im Blade „Authentifizierung“ deiner Web App selbst wurde jetzt ein Identitätsanbieter mit dem Namen „Microsoft“ hinzugefügt. Außerdem siehst du hier die „Client-ID“ deiner App-Registrierung.
Darüber hinaus kannst du im Azure-Portal nach „App-Registrierungen“ suchen. Wechsel hier zum Tab „Anwendungen mit Besitzer“.
Alternativ kannst du auch in Azure-AD-Blade auf „App-Registrierungen“ klicken:
Folgst du nun dem Link zu deiner neuen App-Registrierung, landest du auf der Startseite der Microsoft Identity Platform:
Im oben Teil der Übersichtseite findest du 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 siehst du auch, wenn du im Hauptmenü auf „Zertifikate & Geheimnisse“ klickst. 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 deine Anwendung verwendet, wenn sie ein Token als Identitätsnachweis vom Azure AD abruft.
Teste nun deine Anwendung, indem du im Browser die URL deiner Web-App eingibst, im Beispiel: https://didemoapp.azurewebsites.net. Du solltest nun aufgefordert werden, dich mit einem Benutzer aus dem Azure AD zu authentifizieren. Zu Erinnerung: als Identitätsquelle hatten wir nur das eigene Azure AD Verzeichnis erlaubt:
Als Resultat erscheint nach einem Klick auf „Weiter“ die Einwilligung zu den „Angeforderten Berechtigungen“. Deine App benötigt Berechtigungen, dein grundlegendes Profil anzuzeigen und den Zugriff auf Daten beizubehalten, für die du Zugriff erteilt hast, d. h. durch das Akzeptieren der Berechtigungen erlaubt der Nutzer dieser App, deine Daten gemäß den Vertragsbedingungen und den Datenschutzbestimmungen zu verwenden.
Als vorläufiges Fazit lässt sich nämlich festhalten, dass Azure AD in der Voreinstellung „jedem Benutzer“ erlaubt, solche Einwilligungen (User Consent) im Auftrag des Unternehmens zu erteilen.
Du kannst das Verhalten aber ändern, indem du im Azure AD zu „Unternehmensanwendungen“ wechselst und dort auf „Einwilligungen und Berechtigungen“ klickst und eine restriktivere Einstellung vornehmen.
Dies soll zur Einführung genügen. Im nächsten Teil werden wir uns intensiver mit der Azure Identity Platform beschäftigen.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie