Authentifizierung mittels OAuth2
-
@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 -
@wolfgang-merkel weißt du, ob, wenn EntraID genutzt wird, jeder User mit Login in CT, eine M365 Lizenz benötigt?
-
Wenn CT als Leitsystem verstanden wird, in der alle Personenbezogenen Daten gepflegt werden, liegt es nahe das auch zur Authentifizierung zu verwenden. Sonst musst du die Personendaten synchronisieren, das ist auch nicht sooo einfach
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...
Das Argument ist schwierig, weil es für fast alle Funktionen von CT sicher irgendeinen gibt, der das "professionell abliefert" . Am Ende hast du x Systeme die irgendwas "professionell abliefern" und keine Integration mehr.
