1. Sømløst uthopp - Helsenorge som OpenID Connect provider
Brukerhistorie som støttes
Det er flere situasjoner der det ønskes "sømløs" integrasjon for innbygger mellom et eksternt system/applikasjon og Helsenorge. Helsenorge sikkerhetstjeneste har derfor et OpenID Connect endepunkt der Helsenorge gir det eksterne systemet informasjon om innbygger som allerede er innlogget på Helsenorge. Tjenesten støtter følgende Usecase:
En innbygger som allerede er innlogget på Helsenorge kan gå over fra Helsenorge til eksternt system ved å velge en funksjon på Helsenorge som involverer det eksterne systemet (“uthopp”).
Når uthopp skjer fra Helsenorge, åpnes ett nettleservindu der det gjøres et HTTP GET-kall til en forhåndsdefinert URL. Denne URL’en peker da til et avtalt endepunkt i det eksterne systemet. Når eksternt system mottar en slik request, starter det OIDC-flyten mot Helsenorge sikkerhetstjeneste.
Når dette endepunktet kalles fra Helsenorge skal det eksterne systemet alltid kalle Helsenorge OpenID Connect provider for å reautentisere den innbygger på Helsenorge som nå gjør “uthoppet”. Eventuell eksisterende sesjon for innbygger i det eksterne systemet, fra samme nettleser, skal automatisk avsluttes, før reautentisering foretas. Se detaljer UNDER.
Formålet med at det alltid kreves reautentisering ved uthopp, er for å håndtere eventuelt bytte av representasjonsforhold for innlogget innbygger på Helsenorge mellom “uthopp”.
Se ytterligere informasjon om krav til håndtering av representasjon i eksterne systemer som integreres med Helsenorge HER.
Gjennom OpenID Connect flyten gir Helsenorge sikkerhetstjeneste det eksterne systemet alltid informasjon (via IdToken) om både hvem innlogget innbygger er samt hvem som er representert innbygger (pasienten). Dersom dette ikke er samme person oppgis det i ID-tokenet også relasjon mellom innlogget innbygger og pasient som representeres (foreldrerepresentasjon eller fullmakt). Videre gir Helsenorge OIDC provider ut et AksessToken som siden kan benyttes dersom det eksterne systemet skal benytte. API’er på Helsenorge i “innbygger context”..
Innbygger er etter dette innlogget i både det eksterne systemet og på Helsenorge, og disse sesjonene er uavhengige:
Man er innlogget på Helsenorge inntil man logger seg av selv, eller etter 30 minutter inaktivitet
Det eksterne systemet har selv ansvar for å ha “management” av sin innloggede sesjon med innbygger. Utlogging (manuelt eller på inaktivitet) skjer styrt av det eksterne systemet. Når innbygger logges ut av det eksterne systemet skal dette kalle /revoke endepunktet i Helsenorge OIDC-provider. Merk! Innbygger logges da ikke automatisk ut av Helsenorge, selv om man logger ut i det eksterne systemet. Tilsvarende logges ikke innbygger ut av det eksterne systemet dersom innbygger logger seg av Helsenorge (etter at uthopp er skjedd).
Logisk flyt
Dette er en forenklet overordnet beskrivelse av dataflyten mellom eksternt system og STS (mer detaljer finnes på undersiden: V3 - OpenID Connect /API-tilgang (IdToken og AccessToken)
F1: Uthopp fra Helsenorge for allerede innlogget innbygger (URL til “startpunkt” for innbygger i eksternt system). Denne kan ha parametere f.eks. time-id ved videoløsning eller annen kontekst for uthoppet som skal “formidles” til det eksterne systemet.
Krav til eksternt system:
Det eksterne systemet må ha et endepunkt som kan nås via nettleser og som initierer autentisering av innbygger med Helsenorge OIDC-provider.
O1: Eksternt system/app kontakter STS sitt endepunkt /PAR for å autentisere seg og overføre parametere som skal benyttes. State-parameteren her kan benyttes av klienten til å beholde state mellom request og callback.
O2: Det eksterne system kontakter /Authorize endepunktet i STS for å logge innbygger inn. Det skjer da en redirect i innbyggers nettleser. Da innbygger allerede er innlogget på Helsenorge trenger ikke innbygger reautentisere seg. Resultatet er at det eksterne systemet får en AutorisasjonsKode, som systemet/app’en siden må benytte for å få ID-token, AksessToken og eventuelt Refreshtoken.
O3: Eksternt system kontakter STS endepunkt /Token for å få ID-token og AksessToken. AutorisasjonsKode som ble “mottatt” via redirect i innbyggers nettleser (O2) må være med i input. (Se: /token grant_type=authorization_code)
ID-token inneholder pålogget innbygger samt representert innbygger (pasienten). Videre angis type representasjonsforhold hvis relevant. (Se: ID token )
AksessToken gir rettigheter til å kalle Helsenorge API’er i innbygger kontekst (hvis relevant)
F2: Eksternt system/app kan siden benytte AksessToken for å få tilgang til API’er på Helsenorge i “innbygger-context”. (Se: 2. Ekstern innbyggerløsning kaller Helsenorge API i innbyggerkontekst )
O4: Når innbygger er ferdig/logger ut i eksternt system, skal dette systemet kalle STS for å revokere AksessToken (eventuelt RefreshToken) som er utstedt til systemet/applikasjonen. (Se /revoke )
Detaljert beskrivelse av endepunkter og flyt finnes i denne undersiden: V3 - OpenID Connect /API-tilgang (IdToken og AccessToken)
Krav til eksternt system for å håndtere representasjonsbytte på Helsenorge
På Helsenorge kan innlogget bruker representere andre enn seg selv:
Foreldre kan representere sine barn
Innlogget bruker kan representere andre (pasienten) gjennom fullmakt
Innbygger kan velge om hen vil være seg selv eller representere andre på Helsenorge:
I “personvelgeren” ved innlogging til Helsenorge
Etter innlogging på Helsenorge via personvelger i meny på Helsenorge
Dersom innbygger velger å endre hvem hen representerer etter innlogging på Helsenorge, og etter at det er gjort uthopp til eksternt system, må dette reflekteres ved eventuelt nytt uthopp til samme eksterne system fra Helsenorge. Dvs. at det eksterne systemet “må få vite” at innbygger nå representerer en annen pasient enn ved forrige uthopp. Det stilles derfor krav om at det eksterne systemet alltid skal reautentiser innbygger ved uthopp fra Helsenorge, uavhengig av om det eksterne systemet har en aktiv sesjon med innbygger eller ikke.