Karsten Sitterberg Selbstständig

Mit einer dedizierten Anwendung wie Keycloak lassen sich die Verantwortlichkeiten für Authentifizierung und Autorisierung in einer verteilten Anwendungslandschaft sicher und robust implementieren.

Sicherheit ist ein wichtiges Thema. Aber die Umsetzung auch im Kontext clientseitiger Webanwendungen muss nicht schwierig sein. Das zeigt das praktisches Beispiel einer Angular-2.0-Frontend-Anwendung, die auf ein Spring Boot Backend zugreift. Die Absicherung erfolgt mittels OAuth 2.0 und OpenID Connect. Als OpenID-Connect-Provider kommt Keycloak in Version 2.3 zum Einsatz.

Es gibt vier typische Anforderungen zur Absicherung von Anwendungen: Erstens müssen Nutzer identifiziert werden (Authentifizierung), zweitens dürfen Aktionen nur durch berechtigte Nutzer ausgeführt werden (Autorisierung). Deswegen sollten drittens Nutzern lediglich Aktionen zur Auswahl angezeigt werden, die sie auch ausführen können. Und viertens sollen Nutzer nur die Daten abrufen können, für die sie eine Berechtigung besitzen. Bei Webseiten, die durch serverseitiges Rendering ihre Benutzungsoberfläche erhalten und bei denen der gesamte auszuführende Code zur Request-Zeit zur Verfügung steht, sind alle Anforderungen im gleichen Kontext realisiert: Die Anwendung ist gleichzeitig für Darstellung, Steuerung und Absicherung zuständig und kann damit alle Entscheidungen an einer Stelle treffen. Eine Anmeldung kann direkt an der Anwendung erfolgen und der Zustand z. B. durch eine HTTP Session auf Basis eines Cookies gehalten werden.

AngularJS vs. Angular 2.0

Angular 2.0 ist ein SPA-Framework, das zwar als Nachfolger von AngularJS gedacht ist, jedoch als komplette Neuentwicklung ausgeführt wurde. Lediglich einige Konzepte, wie etwa das der Komponenten, gingen in das neue Framework über. Das Anpassen der Anwendung an bestimmte Benutzerrechte hat sich in Angular 2.0 unter anderem in Hinblick auf das Routing verbessert. Möchte man einen Routingvorgang aufgrund bestimmter Nutzerberechtigungen abbrechen und den Benutzer gegebenenfalls auf ein Log-in-Formular umleiten, bietet AngularJS dafür lediglich umständliche, zumindest aber wenig explizite Lösungsansätze. Ein Ansatz besteht darin, ein Angular-Routing-Event abzufangen und anschließend im Event Handler zu überprüfen, ob der Benutzer angemeldet ist und über die erforderlichen Rechte verfügt. Eine zweite Möglichkeit nutzt die routerbasierte Resolve-Logik. Ein solcher Resolve dient eigentlich zum Beschaffen von Remotedaten, daher wirkt sich dieser Ansatz negativ auf Wartbarkeit und Verständlichkeit der Software aus.

Angular 2.0 sieht ein eigenes, explizites Konzept vor, das es erlaubt, Benutzer mit unzureichenden Berechtigungen abzufangen. Die notwendige Logik heißt Route Guard und bietet ein sauberes, ausdrucksstarkes API, das Lesbarkeit und Wartbarkeit des Codes deutlich erhöht. Im Grundsatz lässt sich das in diesem Artikel vorgestellte Autorisierungs- und Authentifizierungskonzept nicht nur mit Angular 2.0 verwenden, sondern bietet sich für andere Single-Page-Apps an.

Bei JavaScript-Clients sind diese Verantwortlichkeiten nun geteilt: In der Frontend-Anwendung müssen Entscheidungen über die Darstellung getroffen werden. Dazu müssen Informationen über den Benutzer (Authentifizierung) und die Rechte (Autorisierung) des Nutzers dort zur Verfügung stehen. Werden umgekehrt auf dem Backend Services aufgerufen, benötigen diese ebenfalls Informationen, um festzustellen, ob der Aufruf erlaubt ist. Ist die Systemlandschaft umfangreicher, gibt es nicht nur ein einzelnes Backend, sondern mehrere, die durch das Frontend angesprochen werden können. Das gilt vor allem in einer Microservices-basierten Architektur. Eine Anmeldung bei jedem einzelnen System ist damit nicht mehr praktikabel. Da es auch zu kaskadierenden Aufrufen der Services kommen kann, folgt die Anforderung, dass die Authentifizierung separat implementiert und auch delegierbar sein sollte.

Token-basierte Verfahren erlauben es, diese Anforderungen abzubilden und werden schon lange erfolgreich eingesetzt. Das Prinzip ist folgendes: Statt die Zugangsdaten des Nutzers stets aufs Neue anzugeben, wird ein Token vorgelegt. Von der Vorstellung her ist das Token vergleichbar mit einem Zimmerschlüssel: Die Ausgabestelle (Portier) ist getrennt von den zu nutzenden Räumen. Ebenfalls ist der Token delegierbar: Wer den Schlüssel besitzt, kann den Raum betreten und den Schlüssel auch an die Reinigungskraft weitergeben.

Mit OpenID Connect existiert ein modernes Token-basiertes Verfahren, das sich gut im Kontext von Webanwendungen einsetzen lässt. Dabei erfolgt die Anmeldung an einem Dienst – im Enterprise-Umfeld an einem eigenen zentralisierten –, dem alle beteiligten Parteien vertrauen. Ob es sich dabei um einen Social Log-in wie Google, GitHub, Facebook oder um einen eigenen Identity Provider (IdP) handelt, spielt dabei keine Rolle. Viele IdP unterstützen auch Federation, sodass der Log-in über mehrere IdP erfolgen kann. Dank Standardisierung ist das konkrete Produkt austauschbar. Für das Beispiel in diesem Artikel wird der Java-basierte Keycloak-Server verwendet.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 3.17 - "Kotlin"

Alle Infos zum Heft
579765751Angular 2.0 Security mit 0Auth 2.0 und OpenID Connect
X
- Gib Deinen Standort ein -
- or -