Access Token anstatt User+Passwort um Suchenanfragen zu authentifizieren

Derzeit müssen Suchanfragen mit User und Passwort authentifizieren werden, damit diese von haupia 2 verarbeitet werden. Haupia Suche als Beispiel:

curl -k -u haupia-user@localhost.de:secr3t<3 "https://haupia.server:8181/rest/api/v1/prepared_search/SEARCH_PS/execute?query=foo"

Dieser User und Passwort muss im Client(Angular/React/....) bzw. Such Proxy(Node.js/Java,....) vorgehalten werden. Das ist problematisch, da man sich auf einmal mit dem Thema Passwort-Management rumschlagen muss. Passwörter und User sollten nicht  im Client oder Proxy vorgehalten werden, da ein Angreifer damit potentiell Unsinn treiben kann.

Best practice wäre es ein Access Token- oder API-Key-System für die Authentifizierung und Permission Management zu verwenden. Diese kommen in Public REST APIs häufig zum Einsatzt: Commerce Tools, Google Analytics, https://api.nasa.gov/, ...

Folgende Dinge sollten damit machbar sein:

  • Ein technischer Haupia User kann sicheren Access Token/API-Key, mit bestimmten API Rechten, generieren
  • Ein technischer Haupia User kann sicheren Access Token/API-Key invalidieren
  • Mit Access Token/API-Key kann eine Anwendung nur freigegebene API Calls ausführen. Haupia Suche als Beispiel:
    curl -k "hxxps://haupia.server:8181/rest/api/v1/prepared_search/SEARCH_PS/execute?query=foo&token=bsJskXsOZbV3J0shSf3wiFwK26wVxTS3"

Der Vorteil von Access Token/API-Keys ist das man diese ohne Bauchschmerzen in Konfigurationen (yml,properties, json,... ) von Anwendungen speichern kann,

ohne dabei Security Audits zu fürchten bzw. gegen Passwort-Richtlinien zu verstoßen. Im Banken- und Healthsektor werden Passwörter in Konfigurationen als schlechtes Security Design wahrgenommen.

Tags (2)
1 Comment
rednoss
I'm new here

Hallo zusammen,

danke für den Feature-Reqest. Ich habe den Vorschlag unter der internen ID HP-651 aufgenommen. Wann wir die Idee umsetzten werden kann ich allerdings nicht sagen.

Viele Grüße
René