Authentifizierung mittels OAuth2

bwl21

@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.

fschrempf

@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.

simsa

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.

Thomas Kuschan

Endlich, mich freut das OAuth2 Feature sehr. Für mich ist es endlich das Ende von vielen Bastellösungen. Auch wenn die Dokumentation nur auf die Integration von Nextcloud ausgelegt ist, konnte ich dank Standardisierung von OAuth2 ziemlich einfach einen Client programmieren: https://github.com/devdot/churchtools-oauth2-client

Erhofft hatte ich mir trotzdem, dass man mit OAuth auf andere Ressourcen zugreifen kann. Bisher geht es nicht, den User-Token zur Authorisierung der API zu verwenden – das wäre in meinen Augen großartig (natürlich mit entsprechenden Scopes etc.). Ist hier noch mehr geplant?

Aktuell sieht meine Lösung für eigene Integrationen so aus, dass ich dank der neuen OAuth Schnittstelle die CT-User sauber authentifizieren kann und dann wie bisher mit einem API-User die tatsächliche Interaktion mit CT erledige. Wenn ich aber die API mit dem jeweiligen CT-User nutzen möchte (z.B. /api/persons), muss ich weiterhin einem API-User die Admin-Rechte geben, mit denen dieser dann die API-Tokens aller CT-Benutzer organisieren kann. Technisch wäre es viel sauberer, wenn ich ohne einen solchen Admin-API-User an die API-Tokens der CT-User kommen könnte. Oder übersehe ich hier eine Funktion der OAuth Schnittstelle?

davidschilling

@Thomas-Kuschan wie du es beschrieben hast ist es korrekt. Aktuell funktioniert der OAuth Access Token noch nicht für die CT-Api.
Das mit den Scopes ist leider etwas schwierig, weil die CT-Berechtigungen sich nicht so leicht in den Scopes abbilden lassen, zumindest habe ich noch keine gute Idee dafür.

Thomas Kuschan

@davidschilling Vielleicht übersehe ich hier auch etwas, aber mein Gedanke ist ganz einfach: der entsprechende OAuth Scope ermöglicht schlicht die gleichen CT-Berechtigungen wie der Zugriff per API (Token) – also genau mit den CT-Berechtigungen, die dem CT-Benutzer eben freigeschalten sind. Man könnte auch die einzelnen Module jeweils zu einen gesammelten Scope machen

gregorherr

@davidschilling sagte in Authentifizierung mittels OAuth2:

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.

@simsa sagte in Authentifizierung mittels OAuth2:

Daher wünsche ich mir auch für Church Tools ein OpenID Support.

Ich würde mir auch sehr wünschen, dass CT noch SAML und OIDC unterstützt... Das würde vieles einfacher machen & dem Account-Dschungel bei mehreren Diensten ein endgültiges Ende bereiten.

Gibt es eine Hoffnung ob und wann das kommen könnte?

simsa

Als Workaround hab ich mir ein Docker Image erstellt, dass ein OIDC mit Church Tools Social Login ermöglicht.

https://hub.docker.com/r/zendem/sociallogin-to-openidconnect

Die App verbindet sich dann gegen diesen Docker Container mit OIDC, der sich dann wieder zu Church Tools verbindet.

Beispiel Docker Compose

services:
  sociallogintoopenid:
    image: zendem/sociallogin-to-openidconnect:latest
    environment:
      - OAUTH_SOCIAL_LOGIN_CLIENT_ID=secretFromOauthSociaLogin
      - OAUTH_SOCIAL_LOGIN_SECRET=randomString123
      - OAUTH_SOCIAL_LOGIN_REDIRECTURI=https://openid-church.example.org/login/oauth2/code/custom-client
      - OAUTH_SOCIAL_LOGIN_AUTHORIZATION_URI=https://yourchurch.church.tools/oauth/authorize
      - OAUTH_SOCIAL_LOGIN_TOKEN_URI=https://yourchurch.church.tools/oauth/access_token
      - OAUTH_SOCIAL_LOGIN_USER_INFO_URI=https://yourchurch.church.tools/oauth/userinfo
      - OPENID_ISSUER=https://openid-church.example.org
      - OPENID_CLIENT_ID=oidc-client
      - OPENID_CLIENT_SECRET=topSecret123
      - OPENID_REDIRECT_URI=https://yourapp.example.org/oauth2/callback
    ports:
      - "8080:8080"
    restart: unless-stopped

davidschilling

@simsa cool, hast du den Code dazu auch öffentlich?

simsa

@davidschilling aktuell ist der noch nicht öffentlich.

Muss das noch etwas bereinigen. Hab das für unsere Gemeinde intern entwickelt.

Wenn es für Church Tools hilft, dass dadurch schneller OIDC nativ kommt, kann ich das evtl beschleunigen :-).

ckauhaus

@simsa Ja bitte

Der Code muss auch nicht perfekt sein. Wenn er erst einmal auf GitLab/GitHub/... ist, können andere auch mithelfen und PRs einsteuern.

simsa

Hab es hier mal veröffentlicht

https://github.com/canchanchara/sociallogin-to-openidconnect/