Authentifizierung mittels OAuth2
-
@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"?
-
@narnitz Hallo. Gibt es hier Neuzeit? Unsere Pastor team will Churchtools benutzen aber wir haben schon Azure/Teams/Outlook und ich kann es nicht empfahlen so lang wir zwei user Konfigurationen unterhalten müssten.
-
@jason-johnson Your request sounds like using an external Authentication Service (in this case Azure AD?) to authenticate Users when logging into ChurchTools.
I don't know if this is a thing which ChurchTools plans to support.
What this thread is about is the feature request where external applications can use ChurchTools as an Authentication Provider.
F.e. a user can authenticate himself on a Nextcloud instance using his ChurchTools login (which is already available via CT-LDAP)
But I think your setup wouldn't be that big of a problem: In my church group leaders manage the ChurchTools users in their group and manage onboarding etc.
Only a few small things are done by the ChurchTools admin.
Maybe that would also be a model which could work for you.@jason-johnson
Deine Anfrage klingt nach der Verwendung eines externen Authentifizierungsdienstes (in diesem Fall Azure AD?) zur Authentifizierung von Benutzern bei der Anmeldung bei ChurchTools.Ich weiß nicht, ob ChurchTools plant, diese Funktion zu unterstützen.
Worum es in diesem Thread geht, ist die Anfrage nach einer Funktion, bei der externe Anwendungen ChurchTools als Authentifizierungsanbieter nutzen können.
D. h. ein Benutzer kann sich auf einer Nextcloud-Instanz mit seinem ChurchTools-Login authentifizieren (welches bereits über CT-LDAP verfügbar ist).
Ich denke aber, dass Ihr Setup kein so großes Problem darstellen würde: In meiner Gemeinde verwalten die Gruppenleiter die ChurchTools-Benutzer in ihrer Gruppe und kümmern sich um das Onboarding usw.
Nur ein paar kleine Dinge werden vom ChurchTools-Administrator erledigt.
Vielleicht wäre das auch ein Modell, das für Sie funktionieren könnte. -
@narnitz kurze Frage: Wieso ist die Antwort in englisch verfasst?
Ist die offizielle Forensprache jetzt englisch, damit auch Gemeinden aus anderen Ländern mehr Nutzen/ Informationen aus dem Forum ziehen können? -
@Andrej @jason-johnson scheint englisch-sprachig zu sein.
Deshalb habe ich auf Englisch geantwortet, da Übersetzungsprogramme immer Ihre Grenzen haben.Ich füge noch eine Deutsche Variante hinzu.
-
@narnitz alles klar, danke für die schnelle Rückmeldung. Das war mir so gar nicht aufgefallen
-
@narnitz wird ChurchTools als OIDC Provider auch non-confidential clients also native Apps, Single-Page-Application, usw. ohne Client Secret erlauben?
-
@daniel-lerch
Die genauen implementierungsdetails sind aktuell noch nicht ganz klar, aber ich würde mal sagen vermutlich schon.
Ziel ist eine Standard gemäße Implementierung. -
@narnitz
In der Vorstellung für 2024 kam die Info, dass es bis zum 6. Monat 2024 für alle Nutzer da sein wird.
Wenn solche Details noch nicht geklärt sind, habe ich das Gefühl, dass das Feature noch sehr am Anfang steht und potentiell nicht bis zum Juni da ist.Wir warten sehnlichst darauf und bauen extra keine alternative Lösung drum herum.
Gibt es da einen neuen Stand, ob Juni noch gehalten werden kann, oder es doch noch deutlich länger dauert?
-
@simsa
Sorry, hätte ich genauer formulieren sollen:
Ich bin im App-Team, deshalb ist mir der aktuellste Stand im Backend leider nicht klar. -
-
Eine modernere Authentifizierungsschnittstelle wie OAuth2 wäre in unserer Gemeinde auch sehr gewünscht. Ja, wir haben den LDAP-Wrapper im Einsatz, aber der hat seine Grenzen.
-
Wir warten auch sehnsüchtig auf einen modernen Authentifizierungsmechanismus. Eine Info zum Status in der Roadmap wäre sehr hilfreich für die Planung unserer eigenen IT-Projekte.
-
@bmh habt ihr Vorstellungen wie ihr das nutzen wollt? Etwa so:
- Als Leiter oder Mitarbeiter der Kinderkirche möchte ich nur mit einem einzigen Username/Passwort arbeiten müssen.
- Als Leitungsteam der Kinderkirche möchte wir Unterlagen in einem Gruppenordner gemeinsam bearbeiten, um sie den Mitarbeitern der jeweiligen Kinderkirchgruppen in einem eigenen Ordner zur Verfügung zu stellen.
- Als Mitarbeiter in der Kinderkirche X möchte ich die Unterlagen/Vidoes etc. für meine Gruppe (und nur diese) sehen können bzw. automatisch auf meinen Laptop/Tablet synchronisiert bekommen um sie im Kindergottesdienst griffbereit zu haben.
- Als Admin möchte ich die Personen in ChurchTools berechtigen, auf die Unterlagen der Kinderkirchgruppen entsprechend ihrer Rolle zuzugreifen, um den Überblick über die Berechtigungen zu behalten.
-
@bwl21 Wir möchten gerne ChurchTools als zentralen Identity Provider (IDP) zur Authorisierung von User-Logins etablieren. Ich würde auch nichtmals bei der historischen Kombination Username/Passwort bleiben wollen, sondern würde mir phishing-sichere Verfahren mit z.B. FIDO2 als zweiten Faktor oder gar Passkeys als Option wünschen.
Zur Zeit sehe ich bei uns folgende Use Cases:
- Die User überblicken die Service-Landschaft schon jetzt nur schwer und verstehen meist nicht, dass sie diverse User-Konten haben. Daher brauchen wir dringend SSO (single sign on).
- SSO für den Internetauftritt (z.B. Wordpress)
- SSO für Nextcloud - hier wäre eine Übergabe der Gruppenzugehörigkeit sehr hilfreich
- SSO für die Hausautomatisation (z.B. Grafana und Node-RED)
- SSO für diverse weitere interne Services
- SSO für kritische Zugänge wie z.B. VPN-Einwahl ins Gemeinde-Netz sollten MFA (multi factor authentication) erzwingen
Deine genannten Use Cases (2-4) gehen ja in die Richtung, dass die auch Autorisierung über ChurchTools-Rollen erfolgt um z.B. in einer Nextcloud bestimmte Ordner als Mitarbeiter der Gruppe "Kinderkirche-1" sehen und ggfs. sogar bearbeiten zu dürfen. Das wäre natürlich eine Arbeitserleichterung im Bezug auf das Rechte-Management über verschiedene Services hinweg, aber im ersten Schritt nicht unser Kernanliegen.
Wenn ihr allerdings ChurchTools nicht als IDP seht, könnte ich mir auch vorstellen einen eigenen zentralen IDP für unsere Gemeinde aufzubauen (MS Entra ID oder lokales Active Directory oder ein lokal gehosteter OpenSource-Service). Hierzu wäre dann aber notwendig, dass ChurchTools eine Möglichkeit schafft die Authentifizierung an eben diesen externen Dienst auszulagern und nicht mehr die Passwörter selbst verwaltet. Hier würde ich allerdings weiterhin innerhalb von ChurchTools auf das interne Rollen-Management von ChurchTools zurückgreifen wollen.
Egal wer nachher die Identitäten hält und bestätigt: Es darf pro Mitarbeiter nur noch ein einzelnes User-Konto geben. Und ich würde mir von ChurchTools Informationen darüber wünschen, was ihr in dieser Hinsicht zu implementieren gedenkt.
-
Wir haben in etwa den gleichen Anwendungsfall wie schon mehrfach hier beschrieben - CT entweder als IdP oder einen anderen IdP wie Keycloak selbst betreiben welcher dann von CT benutzt wird. Der Thread hier ist mitlerweile schon sehr alt.
Woran liegt es denn? Ich bin mir sehr sicher, dass man genug know-how in der Runde hat um eventuelle Probleme oder Bedenklichkeiten aus dem weg zu räumen.
Seid gesegnet
-
@bmh sagte in Authentifizierung mittels OAuth2:
SSO für Nextcloud - hier wäre eine Übergabe der Gruppenzugehörigkeit sehr hilfreich
Deine genannten Use Cases (2-4) gehen ja in die Richtung, dass die auch Autorisierung über ChurchTools-Rollen erfolgt um z.B. in einer Nextcloud bestimmte Ordner als Mitarbeiter der Gruppe "Kinderkirche-1" sehen und ggfs. sogar bearbeiten zu dürfen. Das wäre natürlich eine Arbeitserleichterung im Bezug auf das Rechte-Management über verschiedene Services hinweg, aber im ersten Schritt nicht unser Kernanliegen.
Der zweite Punkt löst genau den ersten Punkt - wäre sehr hifreich - ist aber nicht euer Kernanliegen? ist das nicht ein Widerspruch.
-
@bwl21 @bmh Es werden hier wieder ein paar Sachen miteinander vermischt. In erster Linie Authentifizierung und Autorisierung.
In diesem Thread ging es urspünglich eigentlich nur um die Authentifizierung (d. h. die Anmeldung) bei externen Dienste über CT. Das ist heute schon möglich, indem man LDAP nutzt und/oder Keycloak + ChurchTools Storage Provider.
Nur ist mit solchen Lösungen z. B. kein SSO (Single Sign On). SSO heißt nicht nur, dass man die selben Zugangsdaten für alle Dienste verwendet, sondern auch, dass man sich auch nur einmal bei CT einloggt und alle anderen Dienste sich automatisch anmelden solange die CT-Session im Browser noch gültig ist. Der Setup mit CT + Keycloak und OAuth (läuft aktuell bei uns) reduziert die nötigen Sessions zumindest auf zwei (CT + Keycloak). Wenn CT selbst als IdP agieren könnte wäre wirklich alles über eine Session möglich und das wäre sicher die bestes Lösung.
Das Thema mit den Berechtigungen (Autorisierung) ist separat zu betrachten. Ja, OAuth erlaubt auch das Übergeben von Gruppenzugehörigkeiten, etc. an den Service Provider, damit dieser diese weiterverarbeiten kann. Das hat aber auch den Nachteil, dass diese nur bei der Anmeldung übergeben werden und dann vom entsprechenden Dienst separat verarbeitet werden.
Deshalb ist es z. B. bei Nextcloud auch sinnvoll OAuth und LDAP zu kombinieren um das beste aus beiden Welten zu vereinen.
-
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
