canchanchara / keycloak-churchtools-storage-provider Goto Github PK

Wenn ein Storage Provider in Keycloak die Schnittstelle UserQueryProvider implementiert, kann man als Admin in der Liste der Nutzer suchen. Im produktiven Einsatz weiß ich nicht, warum man das tun sollte, weil eine Suche in ChurchTools sehr viel praktischer ist, aber zum Testen, wäre es sehr praktisch, weil man auf einen Blick sieht, ob die ChurchTools Anbindung funktioniert. Auch fehlerhaft gesetzte Berechtigungen des Accounts in ServerCredentials ließen sich so einfacher debuggen.

Dieses Feature ist zur reinen Funktion nicht nötig, könnte aber den Login spürbar schneller machen. Bisher wird für jeden API Call zuerst über den Login Endpunkt eine Session erzeugt. Stattdessen könnte man aber auch direkt ein zeitlich unbegrenzt gültiges Login Token in der Konfiguration setzen und sich den Login komplett sparen. Siehe Dokumentation zur API Authentifizierung.

@canchanchara falls du das nicht selbst implementieren möchtest, kannst du das gerne sagen oder ein help wanted Label hinzufügen. Dann stelle ich in den nächsten Tagen einen Pull Request dazu.

Steps to reproduce

1. Keycloak ChurchTools Storage Provider einrichten und Anwendung verbinden
2. Bei Anwendung im Inkognito Tab anmelden, in Keycloak E-Mail und Passwort eingeben und danach Claims anschauen
3. Alle Inkognito Tabs schließen, um die Sitzung zu beenden
4. In ChurchTools den Benutzernamen ändern (Name sollte genauso funktionieren)
5. Erneut bei der Anwendung im Inkognito Tab anmelden

Actual behavior

Die Claims zeigen den Stand von Schritt 2 an.

Expected behavior

Keycloak sollte den aktualisierten Benutzernamen herausgeben.

Workarounds

Caching in den Federation-Einstellungen deaktivieren.

Remarks

Grundsätzlich macht das Caching an dieser Stelle Sinn, weil nur ein Round-Trip zu ChurchTools für die Überprüfung des Passworts benötigt wird. Vielleicht wäre es aber möglich, die Daten parallel mit einer weiteren API Anfrage zu überprüfen. Sonst würde ich in der README Nutzer empfehlen, den Cache zu deaktivieren oder die Gültigkeit auf einen Tag zu begrenzen, damit veraltete Informationen nicht ewig kursieren können.

I'm trying to set up the KC storage provider with our cloud-hosted CT, but I'm getting:

ERROR [de.canchanchara.keycloak.storage.ChurchToolsApi] (executor-thread-3) javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Which apparently means that Java fails to validate the SSL certificate chain for the server. I tried to setup the SPI truststore for KC and everything looks ok, but the error persists.

1. Any ideas how to debug?
2. Are you (@daniel-lerch, @canchanchara) running this against a local CT instance using HTTP or a remote one using HTTPS?

Thanks!

Eine der zentralen Limitierungen von ChurchTools LDAP Wrappern wie milux/ctldap ist, dass keine Zwei-Faktor-Authentifizierung unterstützt wird. Durch ein Keycloak Plugin könnte es möglich sein, diesen zusätzlichen Schritt zu unterstützen.

Keycloak ist nicht ganz einfach zu installieren. Schon das richtige Docker Image auszuwählen erfordert einige Recherche und dann gibt es sehr viele Konfigurationsmöglichkeiten.

Im Rahmen dieses Plugins würde ich jetzt ungern alle Optionen des offiziellen Keycloak Images erklären, aber vielleicht die offizielle Dokumentation verlinken, eine Anleitung zum Setup verlinken und eine docker-compose.yml Datei für ein konkretes Setup mit Datenbank und Reverse-Proxy zur Verfügung stellen.

@fschrempf wäre das für dich ausreichend, um Keycloak in akzeptabler Zeit zum Laufen zu bekommen?

Keycloak ermöglicht eine bidirektionale Synchronisation mit externen User Storages. Im Fall von ChurchTools soll diese jedoch ausschließlich lesend erfolgen und auch keine Informationen im Cache von Keycloak verändert werden können. Wahrscheinlich lassen sich Modifikationen wie Vorname ändern auch durch eine entsprechende Konfiguration von Keycloak verhindern. Ich finde es allerdings sauberer, das direkt im Code umzusetzen, sodass man bei der Konfiguration nichts mehr falsch machen kann.

@canchanchara ich habe dazu bereits etwas in einem Fork implementiert, würde den Code noch mit deinen Änderungen von heute Morgen zusammenführen und dann einen Pull Request erstellen.

OpenID Connect unterstützt die Angabe einer URL zum Profilbild (Spezifikation). ChurchTools bietet in der API /api/persons/{ID} eine imageUrl an, die eine öffentliche URL zum Profilbild des Nutzers enthält. Diese URL könnte vom ChurchTools Provider einfach weitergereicht werden.

Mit keycloak-churchtools-storage-provider gibt der user info Endpunkt aktuell nur drei Claims zurück:

{
  "sub": "f:37c73a75-123a-4c79-8402-d0510febb5a8",
  "email_verified": false,
  "preferred_username": "admin"
}

OpenID Connect sieht jedoch noch viele weitere Claims vor: Dokumentation.

Zum Vergleich der user info Endpunkt wenn man LDAP Federation mit fschrempf/ctldap benutzt und ein paar Mapper korrekt konfiguriert hat:

{
  "sub": "0875d65b-c05c-454d-b286-0d15ab374fd4",
  "email_verified": false,
  "name": "Max Mustermann",
  "preferred_username": "admin",
  "given_name": "Max",
  "family_name": "Mustermann",
  "email": "[email protected]"
}

Ich denke zumindest die Claims wie bei der LDAP Federation sollten unterstützt werden, damit andere Apps damit korrekt arbeiten.

Die Installation dieses Storage Providers könnte man Nutzern deutlich vereinfachen, indem man über GitHub Releases kompilierte JAR-Archive zur Verfügung stellen würde. Da es sich aktuell noch um einen Prototypen handelt, könnte der Download entsprechend als Preview Release kenntlich gemacht werden.

This ChurchTools Storage Provider was developed for Keycloak 22 which has not been supported for 6 months. Instead we should support the latest and only supported version Keycloak 24.