Authentifizierung mittels OAuth2
-
@davidschilling das mit der API-Authentifizierung ist natürlich super. Ein Verfahren wie OAuth2 hätte aber schon noch weitere Vorteile.
Zum Beispiel bei der Communi App gibt es einen Login mit Churchtools-Account. Im Kleingedruckten steht dort, dass mein Passwort erst zum Communi-Server und dann zu euch geschickt wird. Das ist für den User etwas verunsichernd.
Dies ließe sich evtl. schon verbessern, ohne OAuth kompett implementieren zu müssen. Man müsste nur der Login-Seite als Parameter eine Redirect-URL mitgeben können, die nach erfolgreichem Login aufgerufen wird. Das würde dann schon reichen, um einen Login in Apps zu ermöglichen.
Ein weitere Vorteil wäre, dass dann Passwort-Manager direkt das richtige Passwort vorschlagen. -
@frank wir finden oauth auch ne gute Sache. Ist eher ne Prioritätsfrage. Aber könnte sein dass sich da in nächster Zeit etwas tut.
-
@davidschilling cool! Dann +1 von mir
-
Um das Thema nochmal aufzugreifen: Ich bin der Meinung, dass mindestens eines der beiden folgenden Szenarien in Zukunft von ChurchTools unterstützt werden sollte.
-
ChurchTools fungiert als Verzeichnisdienst (via LDAP) und als Identity Provider (IdP, z. B. via SAML/OIDC) für andere Service Provider (SP), die dann ChurchTools für Single-Sign-On (SSO) nutzen können.
-
ChurchTools erlaubt es selbst als SP an einem externen Verzeichnisdienst und IdP (z. B. Keycloak) betrieben zu werden. D. h. Benutzerprofile, Gruppen, etc. werden mit einem externen LDAP-Server synchronisiert und die Authentifizierung erfolgt via SAML/OIDC.
Dadurch wäre es möglich weitere Dienste mit Hilfe von weit verbreiteten und state-of-the-art Protokollen anzubinden, ohne irgendwelche Workarounds, spezielle Wrapper, etc. einsetzen zu müssen. Um das Beispiel von Communi (s. o.) zu bemühen: Wenn Communi z. B. SSO via OIDC unterstützen würde, könnte man dann das auch dafür nutzen.
Die oben verlinkte API Authentifizierung hat ja mit dem Thema dieses Threads eigentlich überhaupt nichts zu tun, oder? Da geht es ja nur darum, wie ich API-Zugriffe auf ChurchTools authentifiziere. Das hilft ja nicht dabei zentrale Logins, bzw. zentrale Benutzerprofile für externe Dienste wie ein CMS, Nextcloud, etc. zu nutzen.
-
-
Noch was: Wie funktioniert das eigentlich beim Gemeindemanagement Projekt der Evangelischen Landeskirche Württemberg? Da wird man zum Login auf den IdP der Landeskirche weitergeleitet und das scheint über OIDC zu funktionieren. Heißt das ChurchTools kann bereits mit einem externen IdP via OIDC/OAuth2 verwendet werden?
-
@fschrempf 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.
Wir sind auch gerade dabei OAuth 2 für CT zu implementieren. Sodass CT als OAuth 2 Provider genutzt werden kann.
-
@davidschilling Danke für die Infos, das klingt super! Aktuell nutzen wir Keycloak als Identity Provider und binden Dienste via Single-Sign-On über SAML oder OAuth2 an. Es wäre klasse wenn wir in Zukunft stattdessen ChurchTools als IdP nutzen könnten. Ich denke OAuth2/OIDC würde uns zunächst ausreichen. SAML wäre aus meiner Sicht aktuell nicht unbedingt notwendig.
-
@chriszuercher sagte in Authentifizierung mittels OAuth2:
Ich kapere mal den alten Thread. Gab es hier irgendwelche neue Entwicklungen bezüglich OAuth? Wir möchte unser CMS an Churchtool anbinden (um die events zu laden). Und da wäre ja ein OAuth Token der übliche Weg. Oder ein Authenticaiton Endpoint im API. Wie ist das aktuell in der App gelöst?
Was für ein CMS habt ihr? Wir haben das über die API mit Contao gemacht. Das ist ein Job, läuft einmal pro Stunde und synchronisiert CT-Events mit Contao Events
-
@davidschilling sagte in Authentifizierung mittels OAuth2:
Wir sind auch gerade dabei OAuth 2 für CT zu implementieren. Sodass CT als OAuth 2 Provider genutzt werden kann.
Ich will nicht drängeln, aber gibt es eine ganz grobe Schätzung wann man mit dem Feature rechnen kann? Das würde uns bei der Planung sehr helfen.
Hintergrund ist, dass wir auf ChurchTools umsteigen möchten und mit unserem bisherigen Auth-Provider (Keycloak) SSO via OAuth2 bzw. SAML möglich ist und ich die Nutzer bei einem Umstieg auf CT ungern mit einem "Rückschritt" konfrontieren möchte wo sie sich dann bei jedem Dienst separat (wenn auch dank LDAP mit den selben Zugangsdaten) anmelden müssten.
-
@fschrempf welche Dienste habt ihr denn auf diese Weise angekoppelt?
-
@bwl21 Derzeit nur Nextcloud und DokuWiki.
-
@fschrempf ich hätte es gerne für nextcloud, contao und osticket ...
aber die leute müssen sich ja trotzdem bei diesen Diensten anmelden, oder?
-
@bwl21 Weiß nicht genau was du meinst. Single-Sign-On (via OAuth2/OIDC oder SAML) funktioniert so, dass die Dienste ("Service Provider") statt der eigenen Anmeldung zum "Identity Provider" (also ChurchTools) umleiten, man sich dort anmeldet und dann zum Dienst zurück geleitet wird. Wenn im Browser eine aktive ChurchTools-Session besteht wird diese beim Anmelden bei den Diensten weiterverwendet solange sie gültig ist. Der Nutzer muss sich also innerhalb des selben Browsers/Geräts nicht mehr anmelden solange kein Logout stattgefunden hat oder die Session abgelaufen ist.
-
@fschrempf ok, das ist dann anders als mit LDAP, da muss man sich bei jedem Dienst einzeln anmelden, wenn auch mit gleichem Username/Passwort
-
@davidschilling sagte in Authentifizierung mittels OAuth2:
@fschrempf 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.
Wir sind auch gerade dabei OAuth 2 für CT zu implementieren. Sodass CT als OAuth 2 Provider genutzt werden kann.
Gibt es zur Unterstützung von OAuth in Church Tools Neuigkeiten?
-
Wir hatten das selbe Problem, dass wir in externen Services Benutzeraccounts von ChurchTools wiederverwenden wollten. Vor ein paar Jahren haben wir dazu einen OIDC Identity Provider basierend auf Ory Hydra mit einem eigenen UI und ChurchTools als Backend gebaut. Über eine Konfigurations-Datei kann das Mapping von CT Gruppe zu Gruppen im ID Token festgelegt werden. Zur Validierung Passwörter wird direkt auf die DB zugegriffen, was in Zukunft leider nicht mehr funktionieren wird, wenn es CT nur noch in der Cloud gibt. Bzw. es muss so angepasst werden, dass Passworte über die Schnittstelle validiert werden.
Aus unserer Sicht wäre es sehr begrüssenswert, wenn CT als IDP fungieren könnte, da darin bereits alle Benutzer gespeichert sind.
Gibt es dazu Pläne? -
Die Funktionalität, CT als OAuth Provider zu Nutzen, ist geplant. Jedoch kann ich leider noch keine Auskunft geben, wann das ganze umgesetzt wird.
-
@narnitz aber wir warten sehensüchtig ...
-
@bwl21 Ich gebe das intern nochmal weiter, kann aber nichts versprechen.
App-Entwickler bei ChurchTools
-
@davidschilling durch den bevorstehenden Umzug von ChurchTools vom Selfhosten in die Cloud haben wir auch größeres Interesse ChurchTools per OAuth2 oder SAML an einen bestehenden IdP anzubinden.
Soll man sich da bei Interesse an einer bestimmten Stelle melden oder wie meintest du "wenn es dafür von anderen noch Bedarf gibt kann man darüber aber sicher nachdenken"?
