Føderering av identitet er prosessen med å delegere autentiseringsansvar. For HelseID betyr det at en identitetstilbyder (IDP) som det er gjort integrasjoner med, garanterer for identiteten til helsepersonellet.
Tradisjonell innlogging
Tradisjonelt har mange applikasjoner og tjenester løst sine autentiseringsbehov ved å tilby egne brukerdatabaser eller ved å gjøre spørringer direkte mot en katalog (enten lokalt eller i skyen).
Det er flere problemer med denne tilnærmingen:
- Brukerne har mange digitale identiteter med forskjellige kombinasjoner av brukernavn og passord
- Manglende mulighet for Single sign-on (SSO) mellom systemer; brukeren må logge inn på nytt i hvert system
- Høyt kompleksitetsnivå på brukerhåndtering i hvert enkelt system
- Manglende mulighet til å etterleve kravet om et høyt nivå på autentiseringen
- Proprietære implementasjoner vil hindre samhandling
For applikasjoner og tjenester bør fokuset være å tilby gode løsninger for brukerne innenfor sitt domene. Autentisering og identitetsforvaltning er egne disipliner som både krever spesiell kompetanse og forvaltningsmessige rutiner, og bør håndteres av spesialiserte tjenester som setter søkelys på å etterleve juridiske krav, god sikkerhet og gode brukeropplevelser.
Identitetsfødererings-arkitektur
Arkitekturmønsteret som HelseID bygger på, kalles en Federation Gateway, i dette dokumentet kalt en identitetsføderering. I vårt tilfelle er dette bunnet på OpenID Connect-spesifikasjonen[1][2]. Mønsteret bygger på at man har en sentralt plassert identitetstilbyder (HelseID) som fungerer som et knutepunkt for andre identitetstilbydere.
I dette mønsteret er HelseID en konsument av tjenestene til flere identitetstilbydere (IDP), og mottar et ID-token (et dokument som beskriver en autentisert bruker) fra en IDP når brukeren er autentisert. En tilknyttet IDP har et gjensidig tillitsforhold til HelseID: HelseID kjenner den offentlige nøkkelen til en IDP, og er i stand til å validere signerte ID-tokens fra den. På samme måte vil en IDP kunne tillate forespørsler om autentisering fra HelseID.
Dermed kan vi være sikre på at innholdet i et ID-token ikke har endret seg etter at det ble signert av en IDP, og at det er en IDP vi kjenner og stoler på som har utstedt ID-tokenet. HelseID vil, i tillegg til å validere ID-tokenet, også kopiere noe av innholdet i tokenet det mottar fra IDP-en og legge det inn i et nytt token som blir signert og returnert til applikasjonen som ba om autentisering av bruker. Dessuten vil HelseID berike tokens med informasjon om brukeren hentet fra Helsepersonellregisteret og Persontjenesten.
Dette mønsteret gjør at man slipper mange-til-mange-tillitsforhold mellom applikasjoner og identitetsleverandører, noe som fort blir komplekst. En applikasjon forholder seg bare til HelseID, og HelseID har tillit til at applikasjonen er det den utgir seg for å være.
Mønsteret gjør det også mulig for helsepersonell og andre ansatte å gjøre Single sign-on (SSO), og deretter få tilgang til tjenester (API) som tilbys av andre virksomheter. I praksis vil det si at en person kan benytte én IDP for innlogging på flere ulike steder. Dette minsker tiden som trengs for innlogging.
Identitetstilbydere
HelseID støtter to typer identitetstilbydere:
- Eksterne Identitetstilbydere
- Buypass
- Commfides
- BankID
- ID-porten
- Interne Identitetstilbydere, for eksempel i regionale helseforetak
For en mer teknisk beskrivelse av disse, kan du se på dokumentet «Styre innlogging i HelseID» i Utviklerportalen.
[1]: https://auth0.com/docs/authenticate/protocols/openid-connect-protocol
[2]: https://www.microsoft.com/en-us/security/business/security-101/what-is-openid-connect-oidc