Ich wollte mich endlich mit einem der Themen beschäftigen, die bereits seit langem auf meiner Weiterbildungsliste stehen: Single Sign On und OAuth

Ich habe mich bereits vor einigen Wochen an dieses Thema erinnert: Für die Arbeit musste ich einen Client an einem Rest-Service das erste Mal über OAuth authentifizieren. Die Gegenseite (Betreiber des Service) erwähnten gesprächshalber, dass ihre Infrastruktur für die Authentifizierung Keycloak einsetzt. Ich hatte bisher - was die Infrastruktur angeht - vor allem Informationen zu Hydra gefunden - allerdings war das schon vom Durchlesen her irgendwie so kompliziert, dass es sich wie Arbeit anfühlte und das war sicher ein Grund dafür, dass es so lange dauerte, bis ich mich jetzt endlich dazu durchrang, praktiche Erfahrungen zu sammeln.

Aber vorher benötigte ich eine Anwendung, die per Single Sign On funktionierte, damit ich nicht auf der grünen Wiese beginnen musste - dann wäre bei nicht funktionieren wieder nicht klar gewesen, ob es am Client oder der Konfiguration des OAuth-Servers liegt. Ich wollte möglichst viele Fehlerquellen ausschließen.

Zum Glück fand ich ein sehr umfassendes Beispielprojekt auf der Basis von Javalin - derselben Technologie, auf der ich auch bereits meinen Testdatengenerator aufbaute.

Mit diesem Projekt begann ich zunächst einige Experimente- wie etwa mich mittels meines GitHub-Accounts zu authentifizieren. Das funktionierte hervorragend und ohne, dass ich an dem Projekt irgendetwas ändern musste.

Damit konnte ich nun beginnen, meinen eigenen Authentifizierungs-Server aufzusetzen. Ich folgte der Anleitung und war bald darauf mit einem Keycloak-Server belohnt, an dem ich mich per OpenID (mit einigen kleinen Änderungen) aus der Web-Applikation heraus authentifizieren konnte.

Allerdings reichte mir das als Erfolg noch nicht - in der ursprünglichen Web-Applikation wird einfach nach erfolgreichem Login dem Nutzer fest eine Rolle zugeordnet, die im Quelltext fest hinterlegt ist - Ich wollte aber, dass die Rolle dynamisch zugeteilt wird - je nachdem, wie der Nutzer auf dem Keycloak-Server administriert ist. Diese Informationen sollten eigentlich in den Token enthalten sein, die im Zuge des Authentifizierungsprozesses zwischen Client und Server ausgetauscht werden. Bei mir fehlten diese aber.

Das war der Punkt, der ein wenig mehr Forschungsaufwand nach sich zog: Ich habe einige Zeit und etliche Ressourcen im Internet benötigt, bis ich auf das magische Schlüsselwort stieß: Mapper!

Ich möchte hier noch kurz erklären, was ich mir präzise wünschte: Ich wollte im Client auf folgende Informationen zugreifen können:

Realm Roles

Rollen, die am Realm - also für die gesamte Anwendung definiert werden

Roles

Rollen, die entweder dem Nutzer direkt zugeordnet werden, oder die er implizit über seine Gruppenzugehörigkeit erbt

Groups

Informationen über seine Gruppenzugehörigkeit

Attributes

Man kann beliebige Informationen zu jedem User als Schlüssel-Wert-Paare hinterlegen. Diese Informationen wollte ich im Client haben um damit arbeiten zu können.

Keine dieser Informationen wird von Keycloak automatisch übertragen - man muss für jede einen Mapper anlegen. Mapper werden in der Administrationsoberfläche von Keycloak über die Clients (Anwednungen) konfiguriert - an jedem Client existiert dafür ein eigener Tab.

Für Attribute wird create Type User Attribute benutzt - Dabei ist wichtig, dass ein Mapper pro Attribut benötigt wird!

Für Realm Roles wird create User Realm Role benutzt. Hier genügt ein Mapper - unter dem angegebenen Schlüssel wird eine Liste aller Realm Roles übertragen.

Für Roles wird create User Client Role benutzt - hier gilt das schon für Realm Roles Gesagte: Die Werte werden als Liste übertragen, daher ist auch hier nur ein Mapper notwendig - egal wie viele Roles definiert sind.

Für Groups wird create Group Membership benutzt - Auch hier wird unabhängig von der Anzahk der Gruppenzugehörigkeiten nur ein Mapper benötigt - auch die Gruppen werden als Liste im Token übertragen.

Im Client kann man nun auf die jeweils definierten Elemente im Token zugreifen und so zum Beispiel die Rollen für die weitere Benutzung in Javalin auslesen.

Abschließend sei noch angemerkt, dass es sehr einfach ist, die Authentifizierung zentral im Keycloak-Server auf Zwei-Faktor-Authentifizierung umzustellen - man kann sogar das System so aufsetzen, dass ein zweiter Faktor mandatorisch ist. Dazu existieren verschiedene Möglichkeiten, die man als zweiten Faktor benutzen kann - am einfachsten (für mich) aufzusetzen war eine One-Time-Passwort-Lösung mit zum Beispiel dem Google Authenticator. Es existiert ebenfalls die Möglichkeit, hierfür FIDO oder U2F zu nutzen - die praktische Erprobung steht bei mir allerdings noch aus...

Artikel, die hierher verlinken