Technische oplossingsrichting (KA-84)
- Marcel Schrauwen
Technische oplossingsrichting wordt kort en bondig uitgelegd wat er technisch nodig is om de wens te kunnen realiseren. Dit kan via tekst, plaatjes. Daarnaast wordt toegelicht welke (internationale) standaarden gekozen worden voor toepassing binnen de oplossing.
Uitwerking(en) technische oplossingsrichting
De onderstaande technische oplossingsrichting is gemaakt tijdens de visiegroep bijeenkomst van woensdag 5 april 2023.
Inleiding
De kern van het rapport van UL betreffende de HTI en koppeltaal launch valt samen te vatten met het volgende diagram.
In het diagram is zichtbaar dat de user agent (webbrowser) van de client in het launchproces niet goed is geauthenticeerd.
Oplossingsrichting
Om dit probleem op te lossen is het voorstel om gebruik te maken van de authenticatiestap in SMART in FHIR app launch procedure. Deze stap is reeds aanwezig en wordt in het voorstel gebruikt om de user agent (webbrowser) te autoriseren. Dit gebeurt in het algemeen door het gebruik van een browser sessie (cookie) in combinatie met een OIDC flow waar een state parameter wordt bijgehouden. Door de browsersessie en de state te correleren wordt het onmogelijk de user agent (browser) te impersoneren.
In het diagram hieronder worden de voorgestelde stappen in groen weergegeven.
De besluiten en de visie
De besluiten en visiepunten worden hieronder uiteengezet. Deze komen voort uit het overleg d.d. woensdag 5 april 2023 en zijn een weergaven van de consensus die in de meeting is bereikt tussen de deelnemers uit verschillende invalshoeken en rollen binnen koppeltaal.
De gekozen richting is de juiste richting
De aanpak om de authenticatiestap toe te voegen en gebruik te maken van Identity Provisioning is de juiste oplossingsrichting.
Er is en blijft behoefte aan de Use Case anoniem gebruik
Hoewel duidelijk is dat authenticatie van de gebruiker een logische en duidelijke toevoeging is aan koppeltaal 2.0 voor geauthenticeerde gebruikers, blijft er een Use Case anoniem gebruik bestaan.
Locus of control: domein configuratie
Op de vraag waar de configuratie van a) of er sprake moet zijn van authenticatie en zo ja b) welke IdP configuratie hier bij hoort is het antwoord.
Configuratie vindt plaats in de domein configuratie van de applicatie op de combinatie van:
Domein
Applicatie in het domein
Gebruikerstype / FHIR resource type: Patient / Caregiver / 3rdPerson
In de configuratie wordt vastgelegd:
De details van de IdP (url, secrets etc)
De mapping van de identiteit van de IdP en de FHIR resource identifer.
Portal applicaties als IdP
De suggestie om portal applicaties als IdP in te zetten is besproken, de de consensus hierover is:
Probeer domeinen richting de IdP als component in het domein te bewegen en deze richting in deze context af te raden.
Indien er wordt gekozen een applicatie als IdP in te zetten is het advies dit te doen met dezelfde standaarden die voor IdPs gelden (OIDC) en dit niet als speciaal geval te beschouwen..
Visie: maak gebruik van abstracties en federatie
Afkomstig van security adviseur (externe partij) en bevestigd door de visiegroep is de visie dat het abstraheren van de Identity Provisioning in de architectuur een goed uitgangspunt is. Door de abstractie van identity provisioning vanuit het oogpunt van bijvoorbeeld module applicaties door SMART on FHIR app launch wordt het mogelijk een flexibele, configureerbare en schaalbare architectuur te bouwen waar de complexiteit ‘uit het zicht’ van de portal en module applicaties komt te liggen. Logisch nadeel is dan wel dat deze complexiteit als gevolg hiervan bij de implementatie van de Autorisatie Service komt te liggen.
Visie: met de WDO in de hand vormt authenticatie voor Koppeltaal 2.0 juist een USP.
In plaats als het issue van authenticatie te zien als bedreiging voor Koppeltaal 2.0, of in ieder geval de bedreiging van de missie de standaard en implementatie eenvoudig te houden, kan met de WDO in de hand Koppeltaal 2.0 juist de correcte oplossing bieden voor de eisen van de WDO.
Goede vraag: wat is nu nog de relevantie van HTI?
Nu is besloten dat het locus of control bij de authorisatieservice te beleggen, in hoeverre is de enkele HTI flow nog nodig of zelfs wenselijk? Het antwoord hierop is drieledig. 1) de HTI flow voltrekt zich nu via het introspection endpoint, dit punt kan gebruikt worden om het gebruik van HTI toe te staan of niet, 2) indien een module geen gebruik wil of kan (DIGID) gebruik maken van de authorisatieservice en een eigen methode implementeerd is HTI van toepassing, en 3) HTI bevat de launch context, en is daarom relevant voor de SMART on FHIR app launch flow.