-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Kommentierung 1.5.3] Potenzielle Probleme HTTP header & nicht-ASCII-Zeichen #55
Comments
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. |
Guter Hinweis. Das oben kommentierte entstand leider zu einen viel früheren Zeitpunkt & ohne scope der tatsächlichen, kompatiblen Umsetzung. |
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. |
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
Festlegung des globalen charsets für jene header-values entsprechend RFC7230.
Vorteil: Keine Anpassung bestehender Interface-Spezifikation
Nachteil: technisch implizite Parallel-Spezifikation notwendig
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. 👌
The text was updated successfully, but these errors were encountered: