[Kommentierung 1.5.3] KOM-LE-A_2187-05 - Authentifizierung des KOM-LE-Teilnehmers über AUT-Zertifikat am AccountManager

[CLAM01]

Kann der Satz "Zur Pflege der Basisdaten des Verzeichnisdienstes und..." kann m.E. endlich raus, da wir keine Basisdaten mehr pflegen.

[dhufnagel]

Wie sieht es hierbei mit der Rückwärtskompatibilität aus? Kann ein CM mi 1.5 sich auch an einem Fachdienst mit 1.5.3 authentifizieren, wenn nur nbf gesetzt ist?

[CLAM01]

Ein CM das nur nbf hat, sollte dann nicht mehr gehen. Der Fachdienst 1.5.3 kennt dann nbf nicht mehr.

[stophane]

Hallo,

diese Änderung darf aus IOP-Gründen nicht erfolgen.
Allgemein bildet diese Änderung die herkömmliche Nutzung von period-validity JWT-Parametern ab, welche jedoch keinen sinnvollen Mehrwert in der aktuellen KIM-Abbildung + im Verhältnis zum IOP-Problem bietet.

Die bisherige Nutzung von nur "nbf" hat sogar den Vorteil, dass der KIM Fachdienst-Account-Manager, zentral verwaltet entscheiden kann, wie lang ein Token aus seiner Sicht gültig ist.

(!) Denn anders als im herkömmlichen Fall (Server stellt JWT aus), ist es in KIM der Client bzw. das KIM Clientmodul, welches das JWT erzeugt. Folglich würde so der Client selbst über die zeitliche Gültigkeit des Tokens entscheiden ("security" - nerver trust the client).

Um zu verhindern, dass Token "beliebig" lange Gültigkeiten "entwickeln" müsste der Account Manager trotzdem entsprechende Prüfung abbilden -> sodass der bisherige Ansatz bestehen bleiben kann und auch aus Sicht einer Clientmodul-Entwicklung eindeutiger ist. So ist klar erkennbar, dass das Clientmodul die zeitliche Gültigkeit nicht "selbst" festlegt.

Viele Grüße

[gem-cp]

Den Teil mit "Pflege der Basisdaten" werden wir entfernen.
Zu nbf: Wir brauchen Abwärtskompatibilität. Daher werden wir für den Fachdienst fordern, dass er das Alte Token und das neue Token unterstützen muss.

[dhufnagel]

Ich würde dringend den Vorschlag von Herrn Stucke unterstützen. Es ist unüblich und sicherheitstechnische bedenklich, wenn der Client die Gültigkeitsdauer vorgibt.

[CLAM01]

Das sollte dann aber auch irgendwo in der Spezifikation festgehalten werden als Nebensatz / ergänzende Info unter der Afo.

[CLAM01]

Die Gültigkeitsdauer ist doch auf 6 Stunden begrenzt laut Afo oder?

Damit dieser Faden nicht gekapert wird, würde ich empfehlen, einen eigenen Faden zu eröffnen.
Aber auch ich gebe Herrn Stucke recht, es ist besser wenn der FD entscheidet wie lange der JWT gültig ist.
Das nbf gibt dabei nur an, ab wann der JWT gültig ist.

[gem-cp]

OK. Danke für das Feedback. Wir werden die Änderung am Token zurücknehmen. Das Token bleibt so wie bisher in 1.5.2.

[Amarteau]

Wird die Gültigkeit des Tokens trotzdem allgemein über die Spezifikation definiert werden?
Oder anders gefragt, woher weiß das Clientmodul ob ein vorhandener JWT noch gültig ist oder ein neuer JWT erzeugt werden muss?

[stophane]

Wird die Gültigkeit des Tokens trotzdem allgemein über die Spezifikation definiert werden? Oder anders gefragt, woher weiß das Clientmodul ob ein vorhandener JWT noch gültig ist oder ein neuer JWT erzeugt werden muss?

Implizit übertragen auf JWT, sagt gemSpec_FD_KOMLE dazu folgendes aus:

Somit muss eine authentifizierte Session im Kontext des Tokens min. 5 min gültig sein.

In jedem anderen Fall erhält das Clientmodul in diesem Kontext als response auf eine request den Statuscode 401 zurück, was wiederrum, bei Auftreten nach erfolgreicher Authentifizierung, i.d.R. das Überschreiten dieser Zeitspanne impliziert. Es können auch andere Ursachen/Abhängigkeiten zu dieser response führen, wobei dies unerheblich ist, da der Server den Client ablehnt und dieser jederzeit mit erneuerten Authentifizierungsinformationen requests wiederholen kann.

[Amarteau]

Ja, aber die 5 Minuten sind ja nur der empfohlene Standardwert laut Tab_Konfig_Parameter. Ein Fachdienst könnte den Wert ja auch auf 2 Minuten konfigurieren.
Aus IOP Sicht würde ich es begrüßen, wenn es eine allgemeine Festlegung gibt oder man den Wert analog der Passwortpolicy vom Fachdienst abfragen kann.

[gem-cp]

Wir können die Gültigkeitsdauer des Tokens über ServiceInformation.yaml abfragbar machen. Gibt es Gegenstimmen?

[stophane]

Ja, aber die 5 Minuten sind ja nur der empfohlene Standardwert laut Tab_Konfig_Parameter. Ein Fachdienst könnte den Wert ja auch auf 2 Minuten konfigurieren. Aus IOP Sicht würde ich es begrüßen, wenn es eine allgemeine Festlegung gibt oder man den Wert analog der Passwortpolicy vom Fachdienst abfragen kann.

Der Abruf eines Parameters "SessionExpirationPeriod" (o.ä.) aus ServiceInformation wäre ein geeigneter Ansatz. So hätte der Client des Account-Managers einen Anhaltspunkt über die zeitliche Gültigkeit seines Tokens.

@Amarteau Könnten Sie dies als feature request PR vorschlagen?! (-:

[Amarteau]

Ja, kann ich machen.

[Amarteau]

#54

[gem-cp]

Danke, werden wir übernehmen; minimum wird auf 300 geändert.