© Nadya C/Shutterstock.com
APIs durch Azure-Dienste absichern - Teil 2

Web-APIs mit Azure AD absichern


Das waren noch Zeiten, als die meisten Firmen Windows-Monokulturen waren und praktisch jeder Computer im Unternehmen Teil einer Microsoft Active Directory Domain war – doch diese Zeiten sind längst vorbei. Dieser Artikel zeigt, wie neuen Sicherheitsanforderungen mit Hilfe von Azure Active Directory begegnet werden kann.

Früher hatten alle Benutzer Benutzernamen und Passwörter, von Multi-Faktor-Authentifizierung war noch keine Rede. In dieser Zeit war es denkbar einfach, einen in .NET entwickelten Service, den man im lokalen Netzwerk anbieten wollte, abzusichern. Die Basis für dessen Betrieb war fast immer der Internet Information Server (IIS) und dort gab es eine „magische“ Einstellung namens Windows Authentication. Man deaktivierte einfach anonymen Zugriff und erzwang Windows-Authentifizierung – und schon konnte man sich drauf verlassen, dass nur noch Personen auf den Service zugreifen konnten, die ein aktives Benutzerkonto in der Microsoft Active Directory Domain (AD) hatten, zu der auch der IIS gehörte.

In heutigen Unternehmen findet man dagegen Clients mit den verschiedensten Betriebssystemen. Auf Servern wird selbst in .NET-orientierten Unternehmen mittlerweile häufig Linux betrieben. Bring Your Own Device (BYOD) ist keine Seltenheit mehr. Mitarbeiterinnen und Mitarbeiter wollen über das Internet auf Anwendungen und Dienste zugreifen. Der Arbeitsalltag ist geprägt von den unterschiedlichsten Anwendungsplattformen, von Windows-Apps über Mobile-Apps bis hin zu Webanwendungen. Die gute alte AD und die damit verbundenen Sicherheitsprotokolle wie Kerberos oder NTLM haben in solchen Umgebungen ausgedient, es muss etwas Neues her. IIS mit Windows Authentication gehört damit ebenfalls der Vergangenheit an.

Neue Anforderungen brauchen neue Protokolle

Es wäre nicht Microsoft, hätte die Antwort nicht mit der Azure-Cloud zu tun. Azure Active Directory (AAD) trat an die Stelle von AD. Jeder Azure-Kunde hat eine AAD, jedes Unternehmen, das Office 365 (aka Microsoft 365) einsetzt, hat zwangsläufig eine AAD. Daher kann man heute davon ausgehen, dass Wissen über AAD in vielen Organisationen einsetzbar ist. Die Sicherheitsprotokolle, die AAD beherrscht, sind für die heutige, zum Internet offene und heterogene IT-Welt geeignet. Allen voran sind in Bezug auf Web-APIs OAuth 2 und OpenID Connect (kurz OIDC) zu nennen. Wer aus der oben beschriebenen früheren Welt von AD, IIS und Windows Authenti-cation kommt, der schreckt wahrscheinlich nach einem Blick in die Beschreibungen von AAD und OIDC zurück. Die Funktionen sind unüberschaubar vielfältig, die Dokumentation ist erschreckend umfangreich und selbst für einfache Anforderungen muss man sich erst fundiertes Grundlagenwissen über aktuelle Sicherheitsmechanismen im Internet aneignen. Wie einfach und produktiv war es im Vergleich dazu mit IIS und Windows Authentication? Dieser Artikel soll den Schrecken vor AAD und OIDC zur Absicherung von Web-APIs nehmen.

OAuth 2 und OpenID Connect

OAuth 2 und OpenID Connect sind zwei aufeinander aufbauende, wichtige Protokolle für moderne Web-APIs. Sie sind komplex, weshalb dringend davon abzuraten ist, sie auf Client- oder Serverseite selbst zu implementieren. Die gute Nachricht ist, dass man als Web-API-Entwicklerin oder -Entwickler nur einen Bruchteil der Protokolle beherrschen muss. Man muss mit den JWT-Tokens, die man bekommt, umgehen können und kommt ansonsten mit Überblickswissen durch.

Die eigentliche „Schwerarbeit“ haben die Clientanwendungen zu erledigen. Ihnen steht eine Vielzahl an sogenannten Flows zur Verfügung, über die sie zu unterschiedlichen Tokentypen kommen. Ich empfehle, auch am Client nach einer zur gewählten Clienttechnologie passenden und mit AAD kompatiblen Authentifizierungsbibliothek zu suchen. Im Fall von .NET-Clients bietet sich die Microsoft Authentication Library (MSAL) [1] an. Selbst mit Unterstützung einer Bibliothek braucht man als Entwicklerin oder Entwickler fundiertes Wissen über die Funktionsweise von OAuth 2 und OpenID Connect. Wenn Sie daher sowohl für APIs als auch für Clientanwendungen verantwortlich sind und OAuth 2 bzw. OpenID Connect für Sie Neuland ist, empfehle ich, etwas Zeit in die Recherche zu investieren, um sich das notwendige Basiswissen über diese Protokolle anzueignen. Dadurch wird Ihnen auch der Umgang mit AAD bedeutend leichter fallen.

In diesem Artikel liegt der Fokus auf der Absicherung von Web-APIs. Die Clientseite wird nur am Rande betrachtet.

Application Registration

Der erste Schritt, um ein Web-API über AAD abzusichern, ist die Anwendungsregistrierung (Application Registration). Dieser Schritt kann über das Azure Portal oder über die diversen Skriptmöglichkeiten von Azure (Azure CLI oder Azure PowerShell) erfolgen. In diesem Artikel werde ich den Weg über das Portal zeigen, bei jedem Schritt jedoch auch die zugehörigen Skriptfunktionen erwähnen.

Abbildung 1 zeigt die Anwendungsregistrierung im Azure Portal. Das gezeigte Formular ist unter Azure Active Directory | App registrations zu finden. Im Azure CLI würde man dafür az ad app create verwenden, in PowerShell New-AzureADApplication. Schon bei diesem Schritt stehen Azure-Neulinge vor einer Hürde: Sie müssen zwischen einer Single-Tenant- und einer Multi-Tenant-Option wählen. Single-Tenant ist die richtige Wahl, wenn man ein Web-API entwickelt, das nur in der eigenen Firma genutzt wird. Das wäre das Pendant zur guten alten IIS Windows Authentication.

Der ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang