| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
|
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.
...
Aansluiting bij standaarden en raamwerken
Hoewel de Om in lijn te blijven met de eIDAS-verordening, Wet Digitale Overheid (WDO) ten tijde van de ontwikkeling van de Koppeltaal 2.0 standaard nog geen vorm heeft gekregen, sluit de notie van een IdP, de noodzaak om de gebruiker te identificeren aan bij de gedachte achter de WDO. De WDO zien we dan ook als eerste raamwerk om bij aan te sluiten als het gaat over welk middel geschikt is, en normering die gaat gelden voor toegang tot online diensten - zoals de applicaties binnen een Koppeltaal domein - kijken we nu al hoe we in de toekomst aan kunnen sluiten op IdP diensten die beschikken over erkende middelen op eIDAS niveau ‘hoog’. In zo’n toekomstig scenario moet het mogelijk worden om via Federated Identity Management (FIM) als Koppeltaal IdP te vertrouwen op zo’n erkend IdP. Om dit toekomstige scenario mogelijk te maken is de bewuste keuze gemaakt om de IdP te baseren op Open Id Connect (OIDC).
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
...