-
Notifications
You must be signed in to change notification settings - Fork 2
Keycloak
Im Folgenden werden die für den Web Client spezifischen Einstellungen für Keycloak erläutert. Eine allgemeine Erläuterung befindet sich unter Keycloak.
Für die Integration von Keycloak in den Web Client wird Keycloak-Angular verwendet. Diese Bibliothek stellt einige Funktionen bereit, um Keycloak einfach in Angular verwenden zu können. Dazu zählen Methoden um auf die Login Seite weiterzuleiten und um Informationen über den Benutzer abzufragen, wie z. B. den Benutzernamen oder die zugehörigen Rollen.
Rollen werden verwendet, um bestimmte Funktionen (Buttons) auf der Webseite anzuzeigen. So sehen z. B. nur Benutzer, die die Rolle Dozent haben, den Button zum Bearbeiten von Projekten. Bei allen Funktionen wird immer abgefragt, ob der aktuediese lle Benutzer die für Funktion erforderliche Rolle besitzt. Sollte kein Benutzer angemeldet sein, hat dieser auch keine Rolle.
In enviroment.ts wird die Verbindung zu Keycloak eingestellt. Dazu sind die URL, der Realm und die ClientID anzugegeben, welche zuvor in Keycloak definiert wurden. (Erklärung der Konfiguration unter Keycloak Web Client)
const keycloakConfig: KeycloakConfig = {
url: 'https://login.coalbase.io/auth',
realm: 'prox',
clientId: 'prox-web-client'
};
Die Klasse AppAuthGuard überprüft bei jedem zugewiesenen Seitenaufruf, ob der Benutzer die für diese Seite hinterlegte Rolle besitzt. Ansonsten wird dieser zur Login-Seite von Keycloak weitergeleitet.
In app-routing.module.ts werden die einzelnen Routen auf Komponenten gemappt. Diese Definition kann um zwei Zeilen erweitert werden. Mit canActivate wird AppAuthGuard zur Überprüfung der Route definiert und in data stehen die Rollen, die für diese Route benötigt werden. Im folgenden Beispiel könnte also nur Dozenten auf Projekte zugreifen.
path: 'projects',
component: ProjectListComponent,
canActivate: [AppAuthGuard],
data: { roles: ['Dozent'] }
Nach aktuellen Stand ist es so, dass keine Routen direkt gesichert sind. Vielmehr wird nur eingeloggten Benutzern die Möglichkeit gegeben, z. B. Projekte anzulegen, zu bearbeiten oder zu löschen, indem die Buttons nur mit entsprechender Rolle angezeigt werden. Dies übernehmen die jeweiligen Komponenten und fragen beim KeyCloakUser die benötigte Rolle an.
Der Bearer Interceptor ist dafür zuständig, dass Access Token in jeden ausgehenden HTTP Header einzufügen.
Dafür gibts es von keycloak-angular zwar eine Implementierung. Diese hat aber das Problem, dass der Nutzer immer zum Login weitergeleitet wird, wenn kein Token vorhanden ist. Das ist auch der Fall, wenn der Benutzer gerade erst die Startseite aufruft. Die einzige Möglichkeit dies zu verhindern ist es, bestimmte Routen expliziet in der keycloak init auszuschließen. Dadurch ergibt sich eine redundante Konfiguration. In app-routing werden alle Routen angegeben, die gesichert werden sollen und in keycloak-init alle Routen die nicht gesichert sind.
Ein weiteres Problem der Standardimplementierung bestand darin, dass nur Routen stelbst ausgeschlossen werden konnten. In unserem Projekt ist es aber der Fall, dass ein get für alle Benutzer möglich ist und nur ein put/post die Rolle des Dozenten erfordert.
Wir haben uns deshalb für eine eigene Implementierung des Interceptors entschieden, der ein Token einsetzt, sollte eines vorhanden sein. Ansonsten wird die Anfrage ohne Token abgeschickt. Vor allem bei get Anfragen ist ein Access Token nie notwendig.
Die Klasse KeyCloakUser bündelt die für das Frontend wichtigsten Benutzerinformationen (Name, ID, UserName) und Methoden (login, logout, hasRole) an einer Stelle und kann von allen Komponenten injected werden.