Authentifizierung mittels OAuth2
-
@jmrauen Magst du das mit der WLAN-Zugriffsteuerung mal unter Tipps&Tricks ein wenig skizzieren?
-
@jmrauen Leider kann ich auf unserem Shared Hosting kein node.js installieren, deshalb habe ich an OAuth2 gedacht. Ansonsten könnte ich mir die Nutzung des LDAP Wrappers gut vorstellen.
Muss der LDAP Wrapper zwingend auf dem gleichen Server wie ChurchTools installiert sein? Oder gäbe es die Möglichkeit, dass ich den LDAP Wrapper separat auf unserem Synology NAS (node.js installiert) ausführe?
-
Der Wrapper benötigt DB-Zugriff. Wenn Du das auf dem Webserver freischalten kannst dann sollte es auch auf der Synology laufen.
-
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?
-
@chriszuercher hier findest du die Doku zur Authentifizierung: https://hilfe.church.tools/wiki/0/API Authentifizierung
-
@davidschilling danke
-
@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
