...

De Identity Provisioning is onderdeel van de koppeltaal launch. In de launch is het noodzakelijk de user agent (browser) 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.

Aansluiting bij standaarden en raamwerken

...

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.

Configuratie in het domein

Toepassing, restricties en eisen

Configuratie in het domein

Op de volgende drie kenmerken wordt de configuratie van de Identity Provisioning vastgesteld:

1. Het domein
2. De applicatie-instantie 
3. Het gebruikerstype (Patient/Practitioner)

Op dit niveau wordt vastgesteld:

1. Of een IdP vereist is
2. Zo ja,
   1. welk type (vooralsnog enkel OIDC)
   2. welk veld  het identifier attribuut bevat
   3. voor welk type FHIR resource deze IdP is, en op welke identifier deze gemapped is.
   4. de kenmerken van de Identity Provider (URL, public key/JWKS URL etc.)

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,
• 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 OIDC

Voorbeelden

{}