Cloud-Lösung für Churchtools-Nutzer

jziegeler

@joachim-gadacz ich versteh die Frage nicht, Churchtools ist bereits ein Cloud-Service

Andy

@jziegeler wurde bereits schon mal vergleichbar gestellt... https://forum.church.tools/topic/9590/unsere-gemeindedaten-dsgvo-konform-in-einer-cloud-speichern?_=1689370386713

... und nicht auf die Antwort reagiert.

sctech

@joachim-gadacz ich denke, du meinst eine Dokumentenablage, wie z.B. Nextcloud?

narnitz

@sctech
Disclaimer: Ich schreibe jetzt als Gemeindeglied meiner Gemeinde und nicht als ChurchTools Mitarbeiter.

Wir in unserer Gemeinde nutzen eine Hetzner Storage Share (https://www.hetzner.com/de/storage/storage-share). Das ist eine gemanagte Nextcloud Instanz die bei Hetzner auf Deutschen Servern DSGVO Konform läuft. 1TB kosten uns da 5,11 Euro im Monat und falls irgendwann in der Zukunft das OAuth Feature in ChurchTools "landet" (genaueres kann ich da leider noch nicht sagen) kann man bei Nextcloud sogar einen "Login mit ChurchTools" Button einbinden, wo sich dann die CT-Nutzer in Nextcloud einloggen können.
Eine Abbildung der Gruppenstruktur geht (soviel ich weiß) auch über diesen Wege in Nextcloud.

Eine Anbindung einer eigenen Domain ist bei Hetzner an der Stelle sogar auch machbar (z.B. "https://cloud.feg-musterhausen.de")

milux

@narnitz Es ist doch schon lange Zeit möglich, mit dem ctldap-Wrapper genau das zu realisieren?
Über das LDAP-Plugin von NextCloud werden dabei ausgewählte Benutzer und Gruppen auf NextCloud gespiegelt.
Wenn man NextCloud selbst administriert oder einen kooperativen Customer Support hat, lässt sich sowas also jederzeit ohne OAuth Feature realisieren. Wenn man ctldap nicht selbst einrichten kann/will, bietet es die ChurchTools Innovations GmbH ja auch für einen kleinen Aufpreis zentral gehostet an.

narnitz

@milux Das ist mir alles klar Ich arbeite ja bei CT.

Jedoch wollte ich mich bisher mit LDAP nicht rumschlagen und auch der Aufpreis oder den Administrationsaufwand war es uns bisher noch nicht wert.

milux

@narnitz Da warst du jetzt schneller, habe den Beitrag oben gerade noch angepasst.
Ich finde LDAP auch nicht so toll, aber es ist eben scheinbar nach wie vor das Beste, was es gibt. Mit OAuth kannst du keine Gruppen nebst Zuordnungen aus CT in NextCloud benutzen...

narnitz

@milux Naja, über OAuth nicht, aber über OpenID Connect schon. Dort hat man die Möglichkeit Gruppen, in denen ein Benutzer ist, einfach mitzugeben. Die werden dann von dem Nextcloud Social Login automatisch in Nextcloud angelegt.

milux

@narnitz Und wie werden diese Gruppen "mitgegeben" bzw. was genau wird da "mitgegeben"?
Natürlich kannst du mit OIDC irgendwelche zusätzlichen benutzerdefinierten Claims mitgeben, aber hast du auf dem Schirm, dass du sowohl einen eindeutigen, unveränderlichen Identifier für die Gruppe brauchst, als auch den Namen der Gruppe selbst?

Den Identifier (UID), falls jemand auf die (natürlich völlig abwegige ) Idee kommt, z.B. den Namen der Gruppe zu ändern.
Den Namen der Gruppe, weil die User sich sonst nicht mehr auskennen.

Und da fangen AFAIK die Probleme an.
Hab mir kurz die README hier angesehen: https://github.com/zorn-v/nextcloud-social-login/blob/master/README.md
Also vielleicht verstehe ich das ja falsch, aber das hört sich für mich so an, als müssten die jeweiligen Gruppen i.A. vorab in NC erstellt werden, aus genau dem Grund, den ich oben erklärt habe...

narnitz

@milux
Letztendlich, wie in den Docs gefordert:

{"roles": [{gid: id_der_godi_technik_gruppe, displayName: "Gottesdienst Technik"}, ...]}

Als ich es letztes Jahr mal ausprobiert hatte mit einem Generic OIDC Provider, hat das Plugin die nicht existierenden Gruppen automatisch erstellt (Ist eine Config Option).
Das mit dem Umbenennen habe ich nicht getestet.
Aber genau kann ich dir das nicht mehr sagen, das es schon ne weile her ist.

Jedoch unterstützt das Social Login Plugin auch Custom Provider, heißt hier einen CT-Provider zu schreiben, der checkt ob Gruppen umbenannt wurden ist (schätze ich jetzt mal) eher trivial.

milux

@narnitz OK, so sollte es gehen, den Teil hatte ich nicht gesehen. Sieht aber ähnlich anfällig und bastelig aus wie LDAP.
Wenn die gids stabil bleiben, sollte Umbenennung kein Problem sein. Wird dann halt erledigt, wenn das erste Mal ein neuer Name als displayName auftaucht.
Aber der Ansatz hat so oder so vergleichbare Probleme wie das LDAP-Gedöns, z.B. hat das LDAP-Plugin Housekeeping für verwaiste User-Konten, auch wenn man für das Löschen der eigentlichen Daten dann noch mit occ Hand anlegen muss.
Ich wüsste aber nicht, wie man das mittels OIDC überhaupt realisieren sollte, da hier ja kein Kanal existiert, der NC darüber informiert, das Nutzer gelöscht wurden.

Und was den Custom Provider angeht:
Ja gut, wenn man schon wieder eigene Software baut, warum dann nicht gleich ein CT-Plugin für NC, was direkt auf die CT-API zugreift und das alles "richtig" macht.

Aber was ich an OIDC-Unterstützung durch CT wirklich super fände:
Das könnte man super für diverse andere Sachen verwenden, bei denen es wirklich nur um Authentisierung/Authentifizierung geht, z.B. CMS-Systeme und andere IT-Services der Gemeinde. Das wäre schon nice.