Keycloak
Keycloak ist eine OpenSource Lösung zur Benutzer- und Rechteverwaltung. Keycloak wird als eigener Microservice ausgeführt und bietet die Möglichkeit des Single Sign On. Dabei müssen sich Benutzer nur auf einer Webseite (Prox oder Coalbase) einloggen und sind dann automatisch auf der anderen auch eingeloggt.
In diesem Projekt wird Keycloak verwendet, um sicherzustellen, dass nur berechtigte Personen Projekte in Prox bearbeiten können.
Das folgende Diagramm zeigt den Ablauf bei der Anmeldung und dem Bearbeiten eines Projektes. Das Diagramm ist etwas vereinfacht und zeigt nicht jede Kommunikation zwischen den Microservices und Keycloak, da diese unter anderem auch vom verwendeten Authentication Flow abhängig sind.
Zu Beginn klickt der Benutzer auf den Login Button im Menü von Prox. Der Login-Prozess wird nicht vom Frontend selbst durchgeführt, sondern leitet den Benutzer auf die Login-Seite von Keycloak weiter. Dort gibt der Benutzer seine Anmeldedaten ein. Nachdem diese von Keycloak überprüft wurden, werden drei Token erstellt.
Das Identity Token beinhaltet Informationen zum angemeldeten Benutzer wie z. B. Name, Benutzername, E-Mail und die zugehörigen Gruppen. Das Access Token enthält die Berechtigungen des Benutzers. Diese Token haben nur eine begrenzte Gültigkeit von standardmäßig 5 Minuten. Durch das dritte Token, das Refresh Token, können durch das Frontend nach Ablauf der Token neue Identity und Access Token bei Keycloak angefragt werden, ohne das der Benutzer sich erneut anmelden muss.
Nachdem sich der Benutzer mit gültigen Daten eingeloggt hat, wird er von Keycloak wieder zu Prox weitergeleitet und das Frontend speichert die Token im Cache. Zusätzlich wird der Benutzer im Menü als eingeloggt angezeigt.
Nun ist der Benutzer in der Lage, auch Aktionen auszuführen, die nur für bestimmte Gruppen möglich sind. Durch die Informationen im Identity Token (Benutzerrolle), kann das Frontend bestimmen, welche Aktion der Benutzer ausführen darf und zeigt die entsprechenden Buttons an. Zusätzlich werden im Backend (Project-Service) alle Put und Post Request überprüft, um auch dort die Autorisierung zu validieren. Dazu ist es notwendig, dass das Frontend bei jeder Anfrage das Access Token im HTTP Header als bearer token mitschickt. Dadurch kann das Backend die Autorisierung prüfen und die entsprechende Aktion ausführen.
Zur Konfiguration von Keycloak sind einige Schritte durchzuführen. Die ersten drei Schritte sind nur einmalig bei der Einrichtung von Keycloak durchzuführen und wurden im Rahmen des GPs schon erledigt. Diese werden aber der Vollständigkeit halber ebenfalls beschrieben, um eine Begründung für die getroffenen Einstellungen zu geben.
Nach der Anmeldung bei Keycloak, kann der Administrator links oben über den Button 'Add realm' den 'Prox' Realm anlegen. Realms stellen eine Gruppe von Benutzern, Clients und deren zugehörigen Rechten dar. Um Single Sign On zu ermöglichen, müssen Coalbase und Prox den gleichen Realm verwenden.
Anschließend müssen die einzelnen Clients angelegt werden. Dabei handelt es sich um die einzelnen Services, die Keycloak zur Authentifizierung verwenden. Im Fall von Prox sind das die Services 'Web-Client' und 'Project-Service'.
Der Web Client ist dafür zuständig, den Benutzer der Login Seite von Keycloak weiterzuleiten und anschließend die erhaltenen Token zu speichern.
Client-ID:
Identifikation des Clients. Sollte nicht verändert werden, da diese ID auch im Quellcodes der Services hinterlegt ist.
Name:
Optionaler Anzeigename in Keycloak. Kann beliebig verändert werden.
Access Type:
Jeder kann das Frontend verwenden und sollte die Möglichkeit haben, zur Login Seite weitergeleitet zu werden. Die Verwendung eines Client Secrets ist nicht sinnvoll, da der Quellcode des Frontendes für jeden Besucher der Webseite einsehbar ist.
Standard Flow:
Bei der Verwendung dieses Flows kann der Benutzer vom Frontend an Keycloak zum Login weitergeleitet werden. Nach dem Login wird der Benutzer zum Frontend zurückgeleitet. Zusätzlich erhält des Frontend einen Code, mit dem es bei Keycloak die Tokens (Identity, Access, Refresh) anfragen kann. Dieser Code hat eine sehr kurze Gültigkeit.
Implicit Flow:
Der Implicit Flow ist sehr ähnlich zum Standard Flow. Der Unterschied liegt darin, dass nachdem der Benutzer von Keycloak zurück zu Prox weitergeleitet wird, kein zusätzlicher Code verwendet wird, sondern das Frontend die Tokens direkt über die URI erhält. Dies hat den Vorteil, dass eine weitere Anfrage bei Keycloak eingespart werden kann. Während des GPs gab es einige Unklarheiten, ob dieser Flow verwendet werden soll oder nicht. Abschließend ist die Empfehlung aber, darauf zu verzichten, da einige Sicherheitsprobleme bestehen und Keycloak von der Verwendung abrät.
Hier einige Quellen, die die Probleme beschreiben:
Keycloak Doku - Implicit Flow
RFC 6819
OAuth 2.0 for Browser-Based Apps draft-parecki-oauth-browser-based-apps-02
Valid Redirect URIs: Dabei handelt es sich um die URIs, zu denen der Benutzer nach dem Login weitergeleitet werden darf. Bei der Weiterleitung von der Prox Webseite zu Keycloak wird Keycloak eine URI übergeben, auf die nach dem Login weitergeleitet werden soll. Dadurch wird verhindert, dass durch eine Manipulation der URI auf einer anderen Webseite landet und diese in Besitz des Tokens kommen kann.
Web Origins:
Dabei handelt es sich um die Adressen, von denen zur Keycloak Loginseite weitergeleitet werden darf. Diese sollten gesetzt werden, um keinen CORS Fehler zu erhalten.
Bei dem zweiten Client handelt es sich um den Project-Service.
Access Type:
bearer-only bedeutet, dass der Project-Service selbst keine Token anfragen kann, sondern diese bei jedem HTTP Request im Header als bearer-token übergeben bekommen muss. Diese kann er dann aus der Anfrage entnehmen und von Keycloak validieren lassen.
Im nächsten Schritt wird die Rolle Dozent angelegt. Dabei ist es wichtig, den Namen Dozent zu verwenden, da dieser auch im Code verwendet wird. Anschließend sollte die Option Composite Roles aktiviert und mit der Client Rolle view-profile verküpft werden. Die Rolle view-profile ist notwendig, damit im Identity Token Informationen zum Benutzer mitgeschickt werden. Durch die Verknüpfung muss den einzelnen Benutzern nur die Rolle Dozent verliehen werden und diese erhalten automatisch die Berechtigung das eigene Profil abzufragen.
Im letzten Schritt werden die einzelnen Benutzer mit Namen, E-Mail, etc. angelegt. Wichtig ist es, dem Benutzer die Rolle Dozent zuzuweisen.
