Authentifizierung mittels OAuth2
-
@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.
-
Es gibt jetzt ein OAuth Provider
https://blog.church.tools/blog/v3-116-registrieren-oauth-provider-camt-053-und-paypal/
Auf einer Testinstallation hat es bei mir schon funktioniert
Hier gibts die Anleitung von Church Tools
-
@simsa Das sind gute Nachrichten! Vielen Dank an die Entwickler für das lang ersehnte Feature!
Leider bleibt es noch ein bisschen hinter meinen Erwartungen zurück. Die Konfiguration eines Clients stellt entsprechende Endpoint-URLs zur Verfügung. Im Beispiel werden diese für Nextcloud mit der Erweiterung "Sociallogin" verwendet. Das funktioniert prinzipiell.
Viele andere Dienste erwarten jedoch, dass der Provider eine "well-known" URL gemäß OIDC Spezifikation bereitstellt unter der dann die Metadaten (Endpoints, Attribute, etc.) abgerufen werden können und erlauben es nicht direkt die Enpoint-URLs anzugeben. Wir nutzen aktuell folgende Dienste, die somit nicht funktionieren und deshalb momentan weiterhin über Keycloak (mit dem CT User Provider) bedient werden müssen.
- Nextcloud mit oidc-login Erweiterung, die es erlaubt LDAP und OAuth bequem zu kombinieren
- OwnCloud Infinite Scale (oCIS)
Daher wäre mein Wunsch diese Möglichkeit in Zukunft vorzusehen um damit auch die breite Masse an Diensten, die es so gibt an CT anbinden zu können. Danke!
-
@fschrempf Was ist der Grund für euch OAuth und LDAP zu kombinieren?
-
@wolfgang-merkel sagte in Authentifizierung mittels OAuth2:
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 du sprichst mir auf der Seele. Als ich mitbekommen habe dass CT jetzt eine Identity Provider Funktion mitbringt hatte ich genau die Gedanken du gut formuliert hast - außer das Gendersterchen
Liebe CT Team, CT als Auth Client in bestehende CIAM Systeme zu hängen ist der Weg. -
@davidschilling Das hat den Grund, dass man damit immer eine aktuelle Datenquelle für User und Gruppen hat (via LDAP) und gleichzeitig den Komfort von Single-Sign-On (man muss sich nur einmal einloggen und bleibt dann in allen Diensten angemeldet solange die Session aktiv ist).
Würde man nur LDAP nutzen, hätte man kein SSO. Würde man nur OAuth nutzen, werden immer nur beim Login die Gruppenzugehörigkeiten des jeweiligen Users synchronisiert. Wenn es viele User gibt, die sich nur selten anmelden, dann hat man im entsprechenden Dienst ständig inkonsistente Daten. In ChurchTools wurden z. B. User-Profildaten und Gruppenzugehörigkeiten geändert, aber das kommt im Dienst erst an, wenn sich alle User die von den Änderungen betroffen sind einmal neu angemeldet haben. Für die Praxis ist diese Variante m. E. komplett untauglich.
-
@fschrempf sagte in Authentifizierung mittels OAuth2:
Würde ... Für die Praxis ist diese Variante m. E. komplett untauglich.
Das kann man so sehen, muss es aber nicht. Es geht darum dass der Benutzer im Drittsystem in die Rechte eintritt, die in CT dokumentiert sind. Das ist gegebn.
Wen ich wissen will,in welchen Gruppen er ist, schaue ich in CT nach. Es ist ja nicht so dass er im Drittsystem CT-Gruppen hat, die eer in CT nicht mehr hat.
Darum CT ist das Leitsystem.
-
@bwl21 Ja, vielleicht sehe ich das kritischer als es wirklich ist. Wenn man den Timeout der Nextcloud-Session nicht zu groß wählt, so dass Nextcloud in regelmäßigen Abständen wieder einen OAuth-Request ausführt und aktuelle Daten bekommt, dann würde es wahrscheinlich sogar einigermaßen gut funktionieren. Danke für den Hinweis, ich werde mir das mal durch den Kopf gehen lassen.
Das ist aber ein ganz anderes Thema. Wie gesagt akzeptieren viele Dienste nur einen Meta-Endpoint (well-known), bzw. selbst wenn direkt die OAuth-Endpoint-URLs angegeben werden können, macht ein Meta-Endpoint die Konfiguration deutlich einfacher.
-
Mein Eindruck ist auch, dass allgemein mehr Anwendungen auf OIDC setzen als pures OAuth. Daher wünsche ich mir auch für Church Tools ein OpenID Support.
Die Social Login App von Nextcloud funktioniert grundsätzlich. Allerdings habe ich Bedenken bzgl. des langfristigen Supports. Das Plugin wird nicht direkt von Nextcloud gewartet. Die OIDC App allerdings schon.
Dh. es könnte sein, dass das Social Plugin von dem externen Entwickler eingestellt wird und man dann schwierigkeiten bekommen kann, Nextcloud zu aktualisieren bzw. die User auf ein anderes Plugin zu migrieren.
