Gå til hovedinnhold

Arkitektur

Her finner du informasjon om teknisk arkitektur for HelseID.

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.

Eksternalisert identitet

Konseptet som handler om at man kan konsumere identiteter via tjenester kalles eksternalisert identitet. De mest kjente identitetstilbyderne er store kommersielle aktører som Microsoft, Google og sosiale nettverk som Facebook, LinkedIn og Twitter. De tilbyr autentisering som en tjeneste andre systemer og applikasjoner kan konsumere. Dette innebærer at de som benytter disse autentiseringstjenestene må stole på at identitetstilbyderen forvalter sine digitale identitetene godt og at de sørger for tilstrekkelig god sikkerhet både i forbindelse med identifisering av bruker og utveksling av informasjon om den autentiserte brukeren.

I helsesektoren i Norge finnes det i dag mange identitetstilbydere, men vi skiller i hovedsak mellom tre kategorier:

  • Interne identitetstilbydere (de regionale helseforetakene)
  • Lokale identitetstilbydere (forskjellige systemer, f.eks EPJ, Kurve osv)
  • Eksterne identitetstilbydere (Buypass, Commfides, BankID) 

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)