Authentifizierung mittels OAuth2

SvenE

@wolfgang-merkel sagte in Authentifizierung mittels OAuth2:

In diesem Thread geht vieles durcheinander, deshalb versuche ich mal ein paar Grundsätze darzulegen, um dann meine Empfehlung/Wünsche an den CT Product-Owner zu formulieren...

CIAM steht für "Customer Identity & Access Management". CIAM ist also ein organisationsweites System, mit dem jegliche Benutzerkonten und Zugangsdaten und Berechtigungen für jegliche Applikationen einer Organisation verwaltet werden können. Damit verbunden sind dann auch Themen wie "SSO - Single Sign On" (einmalige Anmeldung gilt für alle angebundenen und berechtigten Applikationen), ("MFA - Multi Factor Authentication" - erhöhte Sicherheit zur Vermeidung von Identitäts-Diebstahl), oder eben auch die organisationsweite DSGVO konforme Erfassung von Benutzerdaten, samt Einwilligungserklärung etc.
CIAM Tools stellen für anzuschliessende Anwendungen wie z.B. Church-Tools standardisierte Authentifizierungsdienste zur Verfügung (authentication service provider). Die gängigen Standards dafür sind u.a. "OpenID Connect", "SAML" oder eben "OAuth2" (mit dem dieser Thread ja gestartet ist). Church-Tools wäre in einem solchen Szenario also der "authentication client", der die Authentifikations-Anfragen dann z.B. per OAuth2 an den Identity Provider (das organisationsweite CIAM-Tool) weiterleitet.

In diesem Thread wird vielmehr aber diskutiert, dass Church Tools die Funktion des Identity Providers (also dem CIAM-Tool) übernehmen sollte. Eine Solche CIAM Funktionalität zu implementieren, die allen Sicherheitsanforderungen genügt, ist ganz sicher komplex und entspricht nicht der fachlichen Domäne von Church-Tools. Es gibt bereits eine Vielzahl professioneller CIAM Tools, sowohl kommerziell (z.B. das in diesem Thread immer wieder zitierte Microsoft AD (Acrive Directory) oder noch umfassender dem Microsoft ENTRA External ID oder ...) als auch OpenSource Produkte wie dem im Thread schon benannten Keycloak (siehe keycloak.org). Es bleibt also jeder Organisation überlassen, welche CIAM-Software am besten zur bestehenden Infrastruktur passt...
Aus meiner Sicht, macht es keinen Sinn, dass Church-Tools die Funktion eines Identity Providers (CIAM) implementiert, weil andere das Thema schon sehr professionell abliefern...

Mein Wunsch an den ChurchTools Product Owner

Stattdessen ist die sicherlich einfacher zu implementierende und standardisierte Authentifikations-Schnittstelle zur Anbindung an ein bestehendes Identity Access Managements seit langem überfällig. Das würde eben die Integration eines Authentifizierungsdienstes, auf der Grundlage von wahlweise OAuth2 oder SAML oder OpenID-Connect bedeuten - also genau das, was im Titel dieses Threads steht "Authentifizierung mittels OAuth2".

Ich würde mich sehr freuen, wenn es seitens CT hier Fortschritte oder zumindest konkrete Aussagen für eine Roadmap gäbe, da es gerade in Gemeinden zunehmend schwieriger wird, dezentrale Benutzerkonten zu managen und dies den ehrenamtlichen Mitarbeiter*innen (oftmals IT-Laien) zuzumuten...

Besten Dank schon mal im Namen der Kirche Lindenwiese (Überlingen)
Wolfgang Merkel

@wolfgang-merkel du sprichst mir auf der Seele. Als ich mitbekommen habe dass CT jetzt eine Identity Provider Funktion mitbringt hatte ich genau die Gedanken du gut formuliert hast - außer das Gendersterchen
Liebe CT Team, CT als Auth Client in bestehende CIAM Systeme zu hängen ist der Weg.

fschrempf

@davidschilling Das hat den Grund, dass man damit immer eine aktuelle Datenquelle für User und Gruppen hat (via LDAP) und gleichzeitig den Komfort von Single-Sign-On (man muss sich nur einmal einloggen und bleibt dann in allen Diensten angemeldet solange die Session aktiv ist).

Würde man nur LDAP nutzen, hätte man kein SSO. Würde man nur OAuth nutzen, werden immer nur beim Login die Gruppenzugehörigkeiten des jeweiligen Users synchronisiert. Wenn es viele User gibt, die sich nur selten anmelden, dann hat man im entsprechenden Dienst ständig inkonsistente Daten. In ChurchTools wurden z. B. User-Profildaten und Gruppenzugehörigkeiten geändert, aber das kommt im Dienst erst an, wenn sich alle User die von den Änderungen betroffen sind einmal neu angemeldet haben. Für die Praxis ist diese Variante m. E. komplett untauglich.

bwl21

@fschrempf sagte in Authentifizierung mittels OAuth2:

Würde ... Für die Praxis ist diese Variante m. E. komplett untauglich.

Das kann man so sehen, muss es aber nicht. Es geht darum dass der Benutzer im Drittsystem in die Rechte eintritt, die in CT dokumentiert sind. Das ist gegebn.

Wen ich wissen will,in welchen Gruppen er ist, schaue ich in CT nach. Es ist ja nicht so dass er im Drittsystem CT-Gruppen hat, die eer in CT nicht mehr hat.

Darum CT ist das Leitsystem.

fschrempf

@bwl21 Ja, vielleicht sehe ich das kritischer als es wirklich ist. Wenn man den Timeout der Nextcloud-Session nicht zu groß wählt, so dass Nextcloud in regelmäßigen Abständen wieder einen OAuth-Request ausführt und aktuelle Daten bekommt, dann würde es wahrscheinlich sogar einigermaßen gut funktionieren. Danke für den Hinweis, ich werde mir das mal durch den Kopf gehen lassen.

Das ist aber ein ganz anderes Thema. Wie gesagt akzeptieren viele Dienste nur einen Meta-Endpoint (well-known), bzw. selbst wenn direkt die OAuth-Endpoint-URLs angegeben werden können, macht ein Meta-Endpoint die Konfiguration deutlich einfacher.

simsa

Mein Eindruck ist auch, dass allgemein mehr Anwendungen auf OIDC setzen als pures OAuth. Daher wünsche ich mir auch für Church Tools ein OpenID Support.

Die Social Login App von Nextcloud funktioniert grundsätzlich. Allerdings habe ich Bedenken bzgl. des langfristigen Supports. Das Plugin wird nicht direkt von Nextcloud gewartet. Die OIDC App allerdings schon.

Dh. es könnte sein, dass das Social Plugin von dem externen Entwickler eingestellt wird und man dann schwierigkeiten bekommen kann, Nextcloud zu aktualisieren bzw. die User auf ein anderes Plugin zu migrieren.

Thomas Kuschan

Endlich, mich freut das OAuth2 Feature sehr. Für mich ist es endlich das Ende von vielen Bastellösungen. Auch wenn die Dokumentation nur auf die Integration von Nextcloud ausgelegt ist, konnte ich dank Standardisierung von OAuth2 ziemlich einfach einen Client programmieren: https://github.com/devdot/churchtools-oauth2-client

Erhofft hatte ich mir trotzdem, dass man mit OAuth auf andere Ressourcen zugreifen kann. Bisher geht es nicht, den User-Token zur Authorisierung der API zu verwenden – das wäre in meinen Augen großartig (natürlich mit entsprechenden Scopes etc.). Ist hier noch mehr geplant?

Aktuell sieht meine Lösung für eigene Integrationen so aus, dass ich dank der neuen OAuth Schnittstelle die CT-User sauber authentifizieren kann und dann wie bisher mit einem API-User die tatsächliche Interaktion mit CT erledige. Wenn ich aber die API mit dem jeweiligen CT-User nutzen möchte (z.B. /api/persons), muss ich weiterhin einem API-User die Admin-Rechte geben, mit denen dieser dann die API-Tokens aller CT-Benutzer organisieren kann. Technisch wäre es viel sauberer, wenn ich ohne einen solchen Admin-API-User an die API-Tokens der CT-User kommen könnte. Oder übersehe ich hier eine Funktion der OAuth Schnittstelle?

davidschilling

@Thomas-Kuschan wie du es beschrieben hast ist es korrekt. Aktuell funktioniert der OAuth Access Token noch nicht für die CT-Api.
Das mit den Scopes ist leider etwas schwierig, weil die CT-Berechtigungen sich nicht so leicht in den Scopes abbilden lassen, zumindest habe ich noch keine gute Idee dafür.

Thomas Kuschan

@davidschilling Vielleicht übersehe ich hier auch etwas, aber mein Gedanke ist ganz einfach: der entsprechende OAuth Scope ermöglicht schlicht die gleichen CT-Berechtigungen wie der Zugriff per API (Token) – also genau mit den CT-Berechtigungen, die dem CT-Benutzer eben freigeschalten sind. Man könnte auch die einzelnen Module jeweils zu einen gesammelten Scope machen

gregorherr

@davidschilling sagte in Authentifizierung mittels OAuth2:

Bei der Landeskirche Würrtemberg funktioniert das über SAML. Die Anbindung ist bisher spezifisch für die Landeskirche, wenn es dafür von anderen noch Bedarf gibt kann man darüber aber sicher nachdenken.

@simsa sagte in Authentifizierung mittels OAuth2:

Daher wünsche ich mir auch für Church Tools ein OpenID Support.

Ich würde mir auch sehr wünschen, dass CT noch SAML und OIDC unterstützt... Das würde vieles einfacher machen & dem Account-Dschungel bei mehreren Diensten ein endgültiges Ende bereiten.

Gibt es eine Hoffnung ob und wann das kommen könnte?

simsa

Als Workaround hab ich mir ein Docker Image erstellt, dass ein OIDC mit Church Tools Social Login ermöglicht.

https://hub.docker.com/r/zendem/sociallogin-to-openidconnect

Die App verbindet sich dann gegen diesen Docker Container mit OIDC, der sich dann wieder zu Church Tools verbindet.

Beispiel Docker Compose

services:
  sociallogintoopenid:
    image: zendem/sociallogin-to-openidconnect:latest
    environment:
      - OAUTH_SOCIAL_LOGIN_CLIENT_ID=secretFromOauthSociaLogin
      - OAUTH_SOCIAL_LOGIN_SECRET=randomString123
      - OAUTH_SOCIAL_LOGIN_REDIRECTURI=https://openid-church.example.org/login/oauth2/code/custom-client
      - OAUTH_SOCIAL_LOGIN_AUTHORIZATION_URI=https://yourchurch.church.tools/oauth/authorize
      - OAUTH_SOCIAL_LOGIN_TOKEN_URI=https://yourchurch.church.tools/oauth/access_token
      - OAUTH_SOCIAL_LOGIN_USER_INFO_URI=https://yourchurch.church.tools/oauth/userinfo
      - OPENID_ISSUER=https://openid-church.example.org
      - OPENID_CLIENT_ID=oidc-client
      - OPENID_CLIENT_SECRET=topSecret123
      - OPENID_REDIRECT_URI=https://yourapp.example.org/oauth2/callback
    ports:
      - "8080:8080"
    restart: unless-stopped

davidschilling

@simsa cool, hast du den Code dazu auch öffentlich?

simsa

@davidschilling aktuell ist der noch nicht öffentlich.

Muss das noch etwas bereinigen. Hab das für unsere Gemeinde intern entwickelt.

Wenn es für Church Tools hilft, dass dadurch schneller OIDC nativ kommt, kann ich das evtl beschleunigen :-).

ckauhaus

@simsa Ja bitte

Der Code muss auch nicht perfekt sein. Wenn er erst einmal auf GitLab/GitHub/... ist, können andere auch mithelfen und PRs einsteuern.

simsa

Hab es hier mal veröffentlicht

https://github.com/canchanchara/sociallogin-to-openidconnect/