Identitetsføderering

Innhold

Innledning

Føderering av identitet er prosessen med å delegere autentiseringsansvar. For HelseID betyr det at identitetstilbyderne som det er gjort integrasjoner med garanterer for identiteten til helsepersonellet. Dette muliggjør at helsepersonell og andre ansatte kan få tilgang til tjenester som tilbys av andre virksomheter kun ved å logge seg på én gang (Single Sign-On). I praksis vil det si at man benytter en eID man allerede har på flere ulike steder. Gjenbruk av autentiserte identiteter på denne måten bidrar til mer sømløs samhandling og en bedre brukeropplevelse for helsepersonell og andre ansatte, med mer tid til pasientbehandling enn pålogging.

Sentralt for konseptet er at heller enn at de ulike tjenestene som samhandler utveksler detaljopplysninger om helsepersonellet, utveksles kun en sikkerhetsbillett som mottaker av billetten anerkjenner og agerer på. Dette kan mottaker gjøre så lenge de har tillit til avsenderen og at den har gjort en god jobb med autentisering av helsepersonellet. I en føderasjon, som HelseID, er samhandlingen basert på både organisatorisk og teknisk gjensidig tillit. Dersom et føderasjonsmedlem mister tillit påvirker det føderasjonen i sin helhet. Derfor er det viktig at alle føderasjonsmedlemmer gjør sitt beste for å hindre dette.

En positiv bi-effekt av identitetsføderering er at det i tillegg til forenklet hverdag for helsepersonell og andre ansatte, også kan gi økt sikkerhet. Dette kan skje i form at av helsepersonellet håndterer færre innloggingsdetaljer som kan komme på avveie, og ved at virksomheter ofte forbedrer sin sikkerhetsinfrastruktur og sine rutiner når man trer inn i føderasjonen.

Bakgrunn

Tradisjonelt har mange applikasjoner og tjenester løst sine autentiseringsbehov ved å tilby egne brukerdatabaser eller ved å gjøre spørringer direkte mot en LDAP-katalog eller lignende. Det finnes mange eksempler på slike systemer, både i helsesektoren og ellers.

Men, det er flere problemer med denne tilnærmingen:

  • Brukerne har mange digitale identiteter med forskjellige brukernavn/passord kombinasjoner

  • Manglende mulighet for single sign-on 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 høyt nivå på autentiseringen

  • Proprietære implementasjoner hindrer 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 fokuserer på å etterleve juridiske krav, god sikkerhet og gode brukeropplevelser.

Mønsteret i IT-industrien har i økende grad vært å benytte eksterne identitetstilbydere for forvaltning av identiteter og autentisering av brukere.

Federation Gateway

Det arkitektoniske mønsteret HelseID bygger på kalles en Federation Gateway.

Hvis du ikke vet hva en OpenID Provider er kan du med fordel lese avsnittet om dette på sidene som handler om moderne autentiseringsmekanismer.

Konseptet bygger på at man har en sentralt plassert OpenID Provider (HelseID) som fungerer som et knutepunkt for forskjellige identitetstilbydere. Identitetstilbyderne utsteder også sikkerhetsbilletter (tokens) som er signert med sitt signeringssertifikat. 

I en Federation Gateway er HelseID en konsument av tjenestene til identitetstilbyderne, og mottar et token når brukeren er autentisert. Vi kan si at tilknyttede identitetstilbydere har et gjensidig tiliitsforhold med HelseID. For eksempel vil HelseID stole på at sikkerhetsbilletter som er utstedt av ID-Porten er gyldige, og ID-Porten tillater forespørsler om autentisering fra HelseID. 

Identitetstilbyderen vil ikke behandle HelseID på en annen måte enn applikasjoner og tjenester som er tilknyttet. 

HelseID kjenner den offentlige nøkkelen (se avsnitt om PK og PKI på siden som omhandler autentisering) til de tilknyttede identitetstilbyderne og er i stand til å validere tokens som den mottar fra dem. Dermed kan vi være sikre på at innholdet i et token ikke har endret seg etter at det ble signert av identitetstilbyderen, og at det er en identitetstilbyder vi kjenner og stoler på som har utstedt  tokenet. HelseID vil i tillegg til å validere tokenet som oftest kopiere noe av innholdet i tokenet det mottar fra identitetstilbyderen og legge det inn i ett nytt token som blir signert og returnert til applikasjonen som ba om autentisering av bruker. 

Fordelen med denne tilnærmingen er at man slipper mange-til-mange tillitsforhold, som veldig raskt får et uheldig kompleksitetsnivå. I tillegg blir det mulig å få Single Sign-On mellom alle som har tillit til den sentrale OpenID Provideren.

For brukeren betyr dette mønsteret at han kan velge mellom de tilgjengelige identitetstilbydere i HelseID for å identifisere seg. Den digitale identiteten sendes så tilbake til systemet hvor brukeren ble bedt om å autentisere seg.

Men på veien tilbake kan identiteten flyte via mange utstedere av sikkerhetsbilletter, hvor tokenet kan berikes med ytterligere relevant informasjon om brukeren. HelseID vil for eksempel berike tokens med informasjon om brukeren hentet fra Helsepersonellregisteret og Personregisteret

Føderasjonen i norsk helsesektor

HelseID ønsker å tilby autentisering via to typer identitetstilbydere:

  • Interne Identitetstilbydere, for eksempel:

    • Regionale helseforetak som ønsker å tilslutte seg føderasjonen.

    • Kommuner med god teknisk infrastruktur som ønsker å tilslutte seg føderasjonen.

  • Eksterne Identitetstilbydere

    • Buypass

    • Commfides

    • BankID (via ID-Porten)