Hallo zusammen,

dies ist der dritte und letzte Teil meiner Schulung in Keycloak und damit auch meiner Mitschrift. Hier sind Teil 1 und Teil 2. Wie schon in den anderen Teilen beschrieben, fasse ich hier mit meinen Worten zusammen, was ich an dem Tag der Schulung verstanden habe und damit gebe ich keine Gewähr auf Richtigkeit (gebe mir aber Mühe ;-))

Ein paar Wortdefinitionen

Cookies vs. Token

Cookies sind die ältere Technologie. Token bestehen aus Header, Payload und Signatur im JWT Format (Siehe Teil 2) Hier eine Zusammenfassung von Perplexity (mit "Client" ist hier die Nutzer-App oder ein Browser gemeint): | Eigenschaft | Cookie (Browser) | Token (Client/Browser/Apps) | | :-- | :-- | :-- | | Speicherung | Browser-Cookie | Vom Client frei wählbar (localStorage, Datei, App-Backend) | | automatische Sendung | Ja, nur im Browser | Nein, Client muss aktiv das Token mitsenden | | Nutzbarkeit | Nur im Browser sinnvoll | In jedem Clienttyp nutzbar | | Serverzustand | Stateful (Session auf Server) | Stateless (Infos im Token selbst) | | Sicherheit | HTTPOnly, Secure-Flag etc. | Signatur (JWT/Token kann lokal geprüft werden) |

Identity Broker

Keycloak kann als Identity Broker dienen.

Identity Broker: Hier werden verschiedene Identity Provider zusammengeführt (Ldap, AD, andere Keycloaks,…). Ein Identity Broker vermittelt Authentifizierungen zwischen verschiedenen Providern, sodass der Nutzer sich mit diversen Identitäten anmelden kann.

Keycloak kann in 3 verschiedenen Modi laufen: Lesend, lesend+schreibend, spiegelnd (Live-Abfragen)

Die Schreibrechte von Keycloak zu LDAP sind die Rechte die in LDAP für den jeweiligen User gelten.

In Keycloak können die Passwörter neu erstellt werden, die dann ins LDAP geschrieben werden. Oder das Passwort-Reset wird auf das LDAP weitergeleitet.

Wenn ein Passwort geändert wird, dann wird die Session nicht gelöscht. D.h. kompromittierte Passwörter funktionieren dann noch so lange, wie die Session offen ist. Dies ist ein häufiges Sicherheitsrisiko und Keycloak-Administratoren sollten ggf. Sessions explizit beenden, wenn ein Passwort kompromittiert wurde.

Anbindung von LDAP an Keycloak

LDAP Schnittstelle

Wichtig: Das richtige Realm im Keycloak auswählen. Sonst wundert man sich, dass die User sich nicht einloggen können, obwohl man alles richtig konfiguriert hat. (Lesson Learned ;-))

Im Keycloak auf User Federation klicken und dann auf "Add Ldap providers" klicken:

Für unseren Fall geben wir folgende LDAP Daten ein:

Die Verbindung kann man testen und sieht im Erfolgsfall so aus:

Und wenn wir die LDAP Daten richtig eingeben, können wir uns auch erfolgreich authentifizieren:

Hier unsere Einstellungen:

UI Display Name frei wählbar Vendor Active Directory Connection URL ldaps://dc1.ad.example.test:636 Enable StartTLS aus Use Truststore SPI Always Connection Pooling an Connection Timeout optional Mit “Test Connection funktion überprüfen”

Bind Type simple Bind DN cn=ldap,cn=Users,dc=ad,dc=example,dc=test

Speichern und Action/Sync all users klicken:

Wir finden die User im Keycloak unter Users und im Suchfeld geben wir ein "*" ein.

Nun sind wir in der Lage, uns mit einem LDAP-User bei der Zielapplikation anzumelden.

Mapper

Um die Felder, die in LDAP existieren, sinnvoll in Keycloak zu integrieren, müssen sie gemappt werden. Also fügen wir bei der LDAP Schnittstelle noch ein paar Mapper zu:

Add Mapper:

LDAP Gruppen

Nun wollen wir die LDAP Gruppen importieren

In User Federation/LDAP/Mappers sehen wir jetzt unseren neuen Mapper "ldap_gruppen". Dort klicken wir drauf:

Rechts oben klicken wir auf Action/Sync LDAP groups to Keycloak:

Im Gutfall erscheint dann eine Erfolgsmeldung:

Die Gruppen, die wir in LDAP hinterlegt haben, finden wir jetzt in Keycloak unter Groups:

In der Gruppe "nextcloud-admins" finden wir den User "testadmin". Dieser sollte jetzt Admin-Rechte in Nextcloud haben.

Das Zielsystem muss natürlich wissen, dass es Gruppen aus Keycloak/LDAP empfangen soll. Dazu müssen wir das Client Secret von Keycloak und andere Felder befüllen:

Leider hat das bei uns nicht funktioniert.

Als Ergebnis hätte ich als User "testadmin" die Admin-Settings sehen sollen.

----- Nachmittag ---

Fragen für Tag 3:

Kann man Rollen ins Keycloak importieren? Z.B. von einem IAM-System wie Sailpoint? Könnte man damit Keycloak als (rudimentäres) IAM System verwenden? - Ja, aber Keycloak ist kein vollwärtiges IAM system.

Wenn ich meinen Token aus meinem Browser raus kopiere (oder eine Spionagesoftware das macht), kann sich dann jemand anderes damit mit meinem Account an der Applikation anmelden? - Ja. Wenn mein System kompromitiert ist (z.B. durch ein schädliches Browser Add On) und ich logge mich bei dem einen System ein, dann kann jemand mit meinem Refresh Token auf alle anderen Systeme zugreifen, die am Identity Provider angebunden sind.

Kann ein böses Zielsystem sich mit einem Access-Token an den anderen Zielsystemen des Keycloaks anmelden? - Nein. Der Access Token ist nur je Zielsystem gültig. Sollte das böse Zielsystem (oder wer auch immer)(wie auch immer) an den Refresh Token gelangen (was eher unwahrscheinlich ist), dann käme es auch an die Access-Token für die anderen Systeme.

SAML

Nun wollen wir das Zielsystem Nextcloud über das SAML Protokoll an Keycloak anbinden. Dazu klicken wir in Nextcloud als Admin auf Administration/SSO & SAML Authentication/Use Build-in SAML authentication:

Wir sollten uns die URL für den lokalen Admin kopieren und wegsichern: https://www.example.test/nextcloud/login?direct=1. Das ist sinnvoll, damit wenn wir uns aussperren, wenigstens wieder lokal (also ohne Keycloak) mit dem Admin Account anmelden können:

Wir brauchen die Daten aus Keycloak/Realm Settings/SAML 2.0 Identity Provider Metada:

Wir erstellen einen SAML Client in Keycloak:

Dort auf "keys" klicken und das Zertifikat kopieren:

Und einfügen in Nextcloud in dem versteckten optionalen Feld "Public X.509 certificate of the idP":

Jetzt müssen wir noch ein paar Mapper unter Client Scopes in Keycloak hinzufügen:

In dem Client Scope fügen wir mit "Add Mapper/By Configuration" drei Mapper (uid, mail, fullname) hinzu:

Auch das hat leider nicht geklappt. Es liegt an unserer Enterprise-Edition, bzw. wir haben die falsche Software Lizenz installiert und können die Integration so nicht durchführen.

Das Ergebnis wäre gewesen, dass ich beim Anmelden an Nextcloud die Auswahl erhalte, dass ich meinen SAML-User hätte nehmen können.

Fazit der drei Tage

Ich habe eine Menge über Keycloak gelernt und hier auch dokumentiert. Ich denke es wird mir zumindest beim Verständnis der Prozesse im IAM Umfeld deutlich weiterhelfen. Ggf. werde ich auch die ein oder andere Schnittstelle implementieren. Schade fand ich, dass am dritten Tag nicht alles geklappt hat - So ist das Leben. Aber ich hoffe auch, dass ich das SAML Protokoll eh nicht brauchen werde ;-) Unterm Strich war es trotzdem eine gute Schulung, die mich bereichert hat.

Achim Mertens