Beschrijving

De koppeltaal launch bereft de transitie van een portal applicatie naar een module van een user agent, dat laatste is meestal webbrowser. Binnen koppeltaal zijn de applicatie geauthenticeerd en geautoriseerd door middel van SMART on FHIR backend services. De SMART on FHIR app launch kent een authenticatiestap waar de user agent geauthenticeerd moet worden. In koppeltaal 1.x werd er in deze stap niets ondernomen. In Koppeltaal 2.0 wordt in deze stap de user agent wel geauthenticeerd. Dit gebeurt door middel van een Identity Provider (IdP) die binnen het domein beschikbaar is.

...

In het architectuurbesluit Architectuurbesluit (KA-84) is tevens opgenomen dat de configuratie van de IdentityProvider op de combinatie domein, applicatie-instantie en user type plaatsvindt, vooralsnog zijn dat Patient en Practitioner. Het moet dus mogelijk zijn om per user type een andere IdP in een domein toe te wijzen. Dit is noodzakelijk omdat het vaak voorkomt dat medewerkers in een domein een andere IdP gebruiken dan de cliënten. Op zich zou dit opgelost kunnen worden door een vorm van federatie ter hoogte van de IdP, echter, de autorisatie service heeft inzicht in de FHIR resources betrokken in de launch, en kan zo met meer informatie de beslissing nemen bij welke IdP de gebruiker zich moet aanmelden.

AuditEvent logging

Zoals alle interacties van de gebruiker met koppeltaal 2.0 moet ook de authenticatiepoging gelogd worden als AuditEvent, ongeacht van de uitkomst van de poging. De authorisatie service moet een AuditEvent aanmaken van het type 110114, User Authentication. De outcome is de plaats om aan te geven of het succesvol is gebleken of niet. Zie ook TOP-KT-011 - Logging en tracing voor het specifieke AuditEvent.

Toepassing, restricties en eisen

...

• De autorisatie service ontvangt een authenticatieverzoek in de SMART on FHIR app launch flow met als launch parameter het HTI token, pakt het token uit en zoekt de configuratie op.

• De autorisatie service service bereidt een authenticatieverzoek voor met daarin de gewenste verzoekparameters op basis van de configuratie en de referentie van de gebruiker in het HTI token.

• De autorisatie service stuurt het verzoek naar de IdP door middel van een redirect (302).

• IdP verifieert de user agent en de gebruiker.

• IdP verkrijgt toestemming/autorisatie van de gebruiker.

• IdP stuurt de user agent terug naar de autorisatie service met een code door middel van een redirect (302).

• De autorisatie service vraagt een antwoord met behulp van de code op het token endpoint van de IdP.

• De autorisatie service ontvangt een antwoord met een ID-token.

• De autorisatie service valideert het ID-token en haalt de juiste attribuut van de gebruiker op, op basis van de configuratie.

• De autorisatie service haalt de juiste FHIR resource op, en valideert of de gebruiker bestaat, actief is en overeenkomt met de referentie van de gebruiker in het HTI token.

• De autorisatie service maakt een AuditEvent aan van het type 110114 en sub_type 110122. Zie ook TOP-KT-011 - Logging en tracing voor het specifieke AuditEvent.

• De autorisatie service vervolgt de SMART on FHIR app launch flow met als geïdentificeerde gebruiker de FHIR resource uit de vorige stap.

...