[Kommentierung 1.5.3] Potenzielle Probleme HTTP header & nicht-ASCII-Zeichen

[stophane]

Mit der sich noch im Aufbau befindlichen hersteller-unabhängigen Komponenten-Interoperabilität zwischen CM und und FD sind umfassende Spezifikationserweiterungen/-konkretisierungen notwendig.

So wird in KIM 1.5.3 u.a. vorgesehen, dass ServiceInformation durch ein CM vom Account Manager abrufbar werden.

Beschreibung des Problembilds am Beispiel der passwordPolicy:

Aufgrund der historischen Entwicklung und damit verbundenen legacy-Betrachtung der bereits bestehenden KIM-Abbildungen, ist es u.a. notwendig, dass über die ServiceInformationen die konkreten Passwort-Richtlinien des jeweiligen KIM-FD Account Managers bereitgestellt werden, sodass ein herstellerfremdes CM diese entsprechend beachten bzw. dem Nutzer anzeigen kann.

Im Kontext dieser Richtlinien und weiterer Abhängigkeiten werden entsprechend Passwörter (auch iniPassword & OTP) bspw. gemäß AccountManager.yaml in HTTP Header-Elementen übertragen:

https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L89
https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L202
https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L571
...

---

Problem:
Ein charset dieser Werte ist nicht näher, verbindlich spezifiziert, sodass beliebige Zeichen gesetzt werden könnten - bspw. ungefilterter user-input bei Passwort.

Verweis auf RFC´s

Gemäß RFC7230 3.2 und ff. können und sollten nur ASCII chars in HTTP header values verwendet werden [USASCII].
Anderfalls müsste auf MIME-Encoding zurückgegriffen werden, was i.d.R. nicht standardmäßig, verbreitet, weder in HTTP client- noch serverseitig unterstützt wird.

Potenzielle Auswirkungen:
Werden bpsw. in den Passwörter non-ASCII chars, wie Umlaute verwendet, können client- und oder servseitige Fehlerzustände auftreten.

Hinweis:
Dies ist u.a. ein Grund warum HTTP Basic authentication stets base64 kodiert übertragen wird.

Vorschläge möglicher Anpassungen

1. Festlegung des globalen charsets für jene header-values entsprechend RFC7230.
   Vorteil: Keine Anpassung bestehender Interface-Spezifikation
   Nachteil: technisch implizite Parallel-Spezifikation notwendig

2. Base64-Kodierung sämtlicher, proprietärer, jedoch nicht näher spezifizierter HTTP header values analog (vgl. RFC7617)
   Vorteil: es treten zukünftig keine Probleme in diesem Kontext auf - technisch sauberste Lösung
   Nachteil: Änderung grundlegender Bestandteile der Interface-Spezifikation -> potenzielle IOP-Probleme -> ggf. Versionierung notwendig
   Hinweis: Da aktuell in KIM 1.5 keine produktive, hersteller-übergreifende Nutzung CM <-> Fachdienst existiert, ist diese Änderung ggf. noch moderiert möglich.

Ergänzender Hinweis HTTP Basic-Auth

Es muss beim Parsen der credentials (username:passwort) beachtet werden, dass bspw. auch ":" Teil des Passwortes sein kann. 👌

[dhufnagel]

Leider wurde sich dazu entschieden den Vorschlag 2 unmoderiert in KIM 1.5.3 einzubringen. Wie soll hier die Interoperabilität sichergestellt werden? MUSS ein Kim 1.5.3 CM dann nicht sowohl die alte als auch die neue Variante unterstützen? Ein synchronisierter Rollout von KIM 1.5.3 über alle Hersteller klingt unwahrscheinlich.

[stophane]

Guter Hinweis.
Ohne den aktuellen Zustand der Spezifikation/dieses Repos validiert zu haben, ist die Anwendung des o.g. eigentlich nur in versionierter Abbildung der interfaces möglich (bspw. /v2 -> /v3), sodass die "alten" clients weiterhin funktionieren (/v2), die neuen clients gegen neuere Version der interfaces (/v3) base64 nutzen.

Das oben kommentierte entstand leider zu einen viel früheren Zeitpunkt & ohne scope der tatsächlichen, kompatiblen Umsetzung.

[dhufnagel]

Eine Versionierung ist vorgesehen. Dennoch muss ein CM beide Versionen unterstützen, solange bis alle FD auf KiM 1.5.3 umgestellt sind. Das erhöht die Komplexität erheblich, da zusätzlich quasi alle Schnittstellen mit einer neuen Authentifizierung versehen wurden. Damit muss jeder Service doppelt vorgehalten werden.