Allgemeine Frage zur Umsetzung/Verwendung eines Token

[Arne Drews]

Moin,

Ich habe mal eine allgemeine Frage und stelle die hier im C# Bereich, weil es darauf umgesetzt werden wird.

Wir haben im Unternehmen Zeiterfassungsterminals, die ich stündlich mit unserem Zeiterfassungssystem synchronisiere. Dazu bediene ich mich des API der Zeiterfassung.
Nun haben wir Entwickler in unterschiedliche Bereichen, die dieses API für andere Zwecke auch gut verwenden könnten. Ich tu mich allerdings schwer, die API Zugangsdaten rauszugeben, weil darüber sämtliche Personaldaten eingesehen werden können, was datenschutzrechtlich ziemlich fragwürdig sein dürfte.

Meine Idee ist es nun, eine DLL zu schreiben, die als eine Art Middleware fungiert. Über die DLL möchte ich dann entscheiden, welche API Methoden "harmlos" und dem entsprechend nutzbar sind und denen, die "sensibel" sind und nur mit einem zusätzlichen Token aufgerufen werden können.
Der Hintergrund mit dem Token ist der, dass ich diese DLL dann selbstverständlich auch selber nutzen will und somit eine Art Berechtigung benötige.

Meine Gedanken dazu:

• Berechtigung auf Benutzer-/Gruppenebene
  Hier sehe ich den administrativen Aufwand gegenüber einem Token als zu groß.
• Zwei DLLs, eine für normale API Calls und eine für die sensiblen Daten
  Halte ich nicht für realistisch, weil die DLLs irgendwo liegen, wo auch andere Entwickler Zugriff drauf haben. Hierfür dann einen Token o.ä. zu implementieren, wäre für mich das gleiche, als gleich alles in einer DLL mit Token zu realisieren.
• Einen weiteren API Zugang anlegen.
  Aus meiner Sicht die eigentlich beste Lösung, aber leider sind diese Zugänge nicht ausreichend eingrenzbar, so dass es kaum einen Unterschied macht.

Diese Überlegungen führen mich dazu, dass ich es in einer DLL abbilden möchte und wie gesagt für Methoden mit sensiblen Daten einen Token erforderlich mache.

Wie aber setze ich so einen Token sinnvoll um?
Die Entwickler sind alle nicht blöd und können problemlos eine DLL recompilen und sich ansehen, wie in etwa das umgesetzt ist.

Ich habe bisher vieles über Berechtigungen gemacht, aber würde hier gerne auf einen Token ausweichen.
Daher interessieren mich allgemein mal Tipps, wie ihr das machen würdet, bzw. wie eure Gedanken dazu sind?

Danke und Gruß
Arne

[Ralf Jansen]

Egal wie du dich an deiner "Middleware" authorisierst die wird sich selber wieder an der eigentlichen API authorisieren müssen mit den dafür gegebenen Mitteln. Du sprichst von DLL als etwas das lokal im Zugriff eines Entwicklers liegt. Du wirst kaum eine Chance haben die Zugangsdaten dort vor diesem zu versteckem. Sinnvoll erscheint mir nur ein eigener API Server (ein Gateway zu eigentlichen API mit zusätzlicher Authorisierung) ohne direktem Zugriff der Nutzer auf diesen Server. Typische Gateway Produkte die diesen durchreichen an die eigentliche API vollführen wären z.B. Ocelot oder YARP.

• Berechtigung auf Benutzer-/Gruppenebene
  Hier sehe ich den administrativen Aufwand gegenüber einem Token als zu groß.

Das verstehe ich nicht. Wie du die Credentials transportierst ist hier völlig egal. Bei einem Token würdest die Berechtigungen auch darin kodieren es passiert nur zu einem anderen Zeitpunkt. Ob du Berechtigungen beim Token erstellen berücksichtigst oder erst wenn jemand mit z.b. Username/Password mit Basic Auth an deiner API ankommt macht da keinen Unterschied für micht irgendwo müssen Berechtigungen verwaltet werden und die Fallen bei einer Token basierten Authentifizierung nicht einfach vom Himmel.

[Arne Drews]

Moin Ralf,

Egal wie du dich an deiner "Middleware" authorisierst die wird sich selber wieder an der eigentlichen API authorisieren müssen mit den dafür gegebenen Mitteln.

Das ist klar, die eigentliche API verwende ich selber ja bereits. Die Middleware macht im Grunde nichts anderes, wie die entsprechendne API Calls an die API abzusetzen, nur sollen Methoden mit sensiblen Daten nur authentifiziert möglich sein, deshalb die Middleware. Die API bleibt wie sie ist, an der kann ich ja auch nichts anpassen, ist ja nicht meine

Du sprichst von DLL als etwas das lokal im Zugriff eines Entwicklers liegt. Du wirst kaum eine Chance haben die Zugangsdaten dort vor diesem zu versteckem.

Genau das sehe ich auch so, hatte nur gehofft, dass ich hier evtl. irgendwelche Möglichkeiten übersehe.

Sinnvoll erscheint mir nur ein eigener API Server (ein Gateway zu eigentlichen API mit zusätzlicher Authorisierung) ohne direktem Zugriff der Nutzer auf diesen Server.

Das hatte ich auch schon im Kopf und jüngste interne Informationen machen das sehr wahrscheinlich.

Das verstehe ich nicht. Wie du die Credentials transportierst ist hier völlig egal. Bei einem Token würdest die Berechtigungen auch darin kodieren es passiert nur zu einem anderen Zeitpunkt. Ob du Berechtigungen beim Token erstellen berücksichtigst oder erst wenn jemand mit z.b. Username/Password mit Basic Auth an deiner API ankommt macht da keinen Unterschied für micht irgendwo müssen Berechtigungen verwaltet werden und die Fallen bei einer Token basierten Authentifizierung nicht einfach vom Himmel.

Habe ich vielleicht schlecht erklärt, oder verstehe Deine Anmerkung grad nicht.
Eine Berechtigungsebene per Credentials war als Alternative zum Token gemeint. Beides zusammen macht für mich an dieser Stelle gar keinen Sinn. Die Überlegung war halt, dass ich bestimmte Methoden nur für bestimmte Benutzer aus unserem AD erlaube. Aber hier hat sich gestern noch etwas geändert, denn meine Anwendungen laufen i.d.R. auf einem Windows-System, weil fast immer die Schnittstelle zum ERP angesprochen wird und das ist .NET. Jetzt hat der Kollege aber mitgeteilt, dass er das für Linux benötigt, was mich entweder dazu führt, neben einer DLL auch eine SharedLibrary zu schreiben oder wie Du auch schon sagtest eine eigene API auf HTTPS Basis.


Es bleibt spannend, danke für Deine Gedanken!

[Ralf Jansen]

Eine Berechtigungsebene per Credentials war als Alternative zum Token gemeint.

Token - Zu einem frühen Zeitpunkt werden Credentials gegen ein Token getauscht. Dabei werden die Berechtigungen in das Token geschrieben um dann an jedem Endpunkt den Tokeninhalt zu prüfen -> Eine Berechtigungsprüfung im Endpunkt
BasicAuth - Mit jedem API Call werden die Credentials mitgesendet und gegen die Berechtigungen die irgendwo gespeichert sind im Endpunkt geprüft -> Eine Berechtigungsprüfung im Endpunkt

In beiden Fällen machst du ähnliches nur zu anderen Zeitpunkten. Den Unterschied im administrativen Aufwand denn du ansprachst habe ich nicht verstanden. Es mag ein Unterschied im Aufwand des Implementierens liegen aber dann eher deshalb weil du an bestimmten Dingen die du schon hast andocken kannst oder nicht. Administrativ ist das aber identisch. Mann braucht irgendwo ein User<->Berechtigungen Mapping das administriert werden muß.

[Arne Drews]

Nein, ich verwende den Begriff Token vielleicht nicht, wie er im Grunde gemeint ist. Ich meine damit bspw. einfach einen Hashwert, woraus generiert spielt erstmal keine Rolle.
Nennen wir ihn einfach einen Schlüssel. Einen Token muss ich über die Credentials generieren lassen, da hast Du recht. Das meinte ich aber nicht.