Service Account // System User Token

MichaelG

Hallo,

gibt es so etwas wie einen Systemuser, den man nutzen kann, um sich auf das System zu authentifizieren, für die API, oder muss das immer eine Person sein?

Wie macht ihr das dann?

Für jeden Anwendungsfall einen eigenen User, oder einen super Admin Service Account, der überall den Zugang bringt?

@tunbehaun FYI

Klasse fände ich ja, wenn es verschiedene Usertypes gebe. Eben echte Menschen, und dann noch Service Accounts (an anderer Stelle wurde ja auch schon Firmen und Gäste vorgeschlagen; das geht alles in die gleiche Richtung)

Usertype Serviceaccount braucht keine hinterlegte Email oder Passwort. Sobald dieser usertype Kontakt angelegt wurde, erhält man den Token dafür und berechtigt ihn noch mit dem minimal notwendigsten. So kann es für verschiedene Anwendungsfälle unterschiedliche SAs geben.

aschild

@MichaelG Wir haben verschiedene Serviceaccounts erstellt.
Vor allem

einen Readonly Account für Kalenderexporte auf die Webseite
und dann zwei mit Schreibzugriff
1x. Kalender+Ressourcen zum nachführen von Orten anhand von Ressourcebuchungen
1x Personen und Gruppen für Anpassungen/Kontrolle bei Emails etc.

wulmer

Geht mir genauso. Wir nutzen halt einen eigenen User als "technischen User", z.B. für eine Einbettung von Raumbuchungsdaten auf einer Webseite.

Was aber furchtbar nervt ist, dass wenn jemand diese Seite anschaut (was im Hintergrund per JS mit dem technischen Nutzer auf die Ressourcendaten zugreift) er automatisch als eingeloggt gilt, und zwar als technischer User.

Wenn nun also die Besucher danach irgendwann auf die eigentliche ChurchTools Seite kommen, so sind sie immer schon eingeloggt, und sehen keinen Login Dialog mehr, sondern sind im technischen User angemeldet. Das verstehen die meisten User nicht, dass sie sich eigentlich erst ausloggen müssten.

Ein Token (welches dann auch kein verwirrendes Session-Cookie des technischen Users erfordert) wäre da sehr hilfreich.

daniel-lerch

@MichaelG wir haben einen eigenen Status API-Nutzer zusätzlich zu Mitglied, Gast, usw. in den Stammdaten angelegt. Außerdem habe ich die API-Nutzer in einen privaten Bereich (Department) verschoben, sodass sie nicht auf der Gemeindeliste auftauchen und nur für Admins sichtbar sind.

daniel-lerch

@wulmer sagte in Service Account // System User Token:

Ein Token (welches dann auch kein verwirrendes Session-Cookie des technischen Users erfordert) wäre da sehr hilfreich.

Was du suchst, ist vermutlich das Login Token. Das ist zeitlich unbegrenzt gültig und ermöglicht die Authentifizierung über den Authorization Header ohne Cookies.

️ Ich würde dir jedoch dringend davon abraten, Login Tokens im JavaScript einzubinden und damit öffentlich ins Internet zu stellen. Auch die aktuelle Lösung, die du beschreibst, klingt gefährlich. Wenn euer Systemnutzer aus irgendeinem Grund z.B. einer Gruppenmitgliedschaft zu viele Berechtigungen erhält, sind schnell sehr viel mehr Daten öffentlich einsehbar, als du möchtest.

Aufwändiger aber deutlich sicherer wäre ein Backend, dass ausgewählte Informationen eurer Website über eine eigens dafür konzipierte API zur Verfügung stellt. Ich bin jetzt kein PHP Experte, aber mit den Libraries die es gibt, sollte das in unter 50 Zeilen Code umsetzbar sein.