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. Ik Koppeltaal 2.0 wordt in deze stap de user agent wel geauthenticeerd. Dit gebeurt door middel van een Identity Provider die binnen het domein beschikbaar is.
Overwegingen
Autorisatie en SSO
De Identity Provisioning is onderdeel van de koppeltaal launch. In de launch is het noodzakelijk de user agent (browserwebbrowser) te identificeren in het launch proces. Zie ook TOP-KT-007 - Koppeltaal Launch. Het uitgangspunt is dat de gebruiker zich in het domein (nogmaals) moet identificeren om van de module die gestart wordt gebruik te maken. Om dit te doen dient in het domein een Identity Provider beschikbaar te zijn. Hoewel Koppeltaal niet bepaald welke Identity Provider dit moet zijn en hoe deze exact moet werken, geeft Koppeltaal 2.0 wel aan dát er een Identity Provider moet zijn. Door de Identity Provisioning ter hoogte van de autorisatie service te beleggen wordt deze taak voor zowel de portalapplicatieleverancier als de moduleapplicatieleverancier geabstraheerd. Indien de IdP de SSO methode goed implementeert blijven de cookies op de user agent actief en hoedt de gebruiker niet nogmaals in te loggen.
Het diagram beneden ligt het probleem toe, in een launch scenario zijn alle systemen geautoriseerd en geautoriseerd, m.u.v. de user agent (webbrowser). Om deze te authenticeren is de autorisatiestap noodzakelijk. Zie voor meer uitleg Architectuurbesluit (KA-84) .
Aansluiting bij standaarden en raamwerken
Hoewel de 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.
Afhankelijk van de inhoud
De vraag of de identificatie door middel van een IdP noodzakelijk is, is afhankelijk van de vraag of de module persoonsgegevens en/of medische gegevens verwerkt. Toont de module een video of toont deze informatie zonder gegevens op te slaan of verwerken, verwerkt deze geen persoonsgegevens of medische gegevens. In dergelijk geval is er geen noodzaak voor een extra authenticatie van de gebruiker. Niet in alle gevallen is er dus een noodzaak voor een IdP. Koppeltaal doet wel de observatie dat er een noodzaak is binnen de domeinen zoals deze bekend zijn.
IdP en SSO standaarden
Koppeltaal kiest primair voor de OpenID Connect standaard (OIDC) om met de Identity Provider te communiceren. Hoewel SAML tevens een gangbare standaard is, gaat de voorkeur primair uit naar OIDC. De gedachte hierachter is dat OIDC moderner is, en in implementatie en configuratie gemakkelijker dan SAML.
...
IdP per user type
In het architectuurbesluit Architectuurbesluit (KA-84) is tevens opgenomen dat de configuratie van de IdentityProvider op de combinatie domein - applicatieinstantie - user type plaatsvindt. 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.
Toepassing, restricties en eisen
Configuratie in het domein
Op de volgende drie kenmerken wordt de configuratie van de Identity Provisioning vastgesteld:
Het domein
De applicatie-instantie
Het gebruikerstype (Patient/Practitioner)
Op dit niveau wordt vastgesteld:
Of een IdP vereist is
Zo ja,
welk type (vooralsnog enkel OIDC);
welk veld het identifier attribuut bevat;
voor welk type FHIR resource deze IdP is, en op welke identifier deze gemapped is.
de kenmerken van de Identity Provider (URL, public key/JWKS URL etc.).
Het is de verantwoordelijkheid van het domeinbeheer deze configuratie mogelijk te maken, de authrosiatieservice maakt van deze configuratie gebruik om de SMART on FHIR app launch uit te voeren.
Integratie in het domein
De IdP speelt een rol in de autoriseren van de gebruiker in de SMART on FHIR app launch, daar wordt in de authenticatie (/authenticate) stap de beslissing tot authenticatie met het IdP genomen. Daarnaast staat het natuurlijk verschillende applicaties in het domein te adviseren gebruik te maken van dezelfde Identity Provisioning, aangezien dit het Single Sign On (SSO) effect in het domein sterker maakt. Het volgende onderdeel zet deze stappen uiteen.
Uitvoer van de Identity Provisioning stappen
De stappen van de OIDC flow worden in de specificaties in detail besproken, samenvattend komen ze op de volgende neer:
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 vervolgt de SMART on FHIR app launch flow met als geïdentificeerde gebruiker de FHIR resource uit de vorige stap.
Gebruikte standaarden
OpenID Connect OIDCConnect OIDC
Voorbeelden
...