Gå til hovedinnhold

Moderne autentiseringsmekanismer

Her finner du litt historikk og en beskrivelse av de moderne autentiseringsmekanismene som utgjør kjernefunksjonaliteten i HelseID

Autentiseringsprotokoller

Autentiseringsprotokoller er beskrivelser av hvordan autentiseringsdata overføres mellom to eller flere datamaskiner eller program.

Vi skiller mellom autentisering av brukere innad i et lukket nettverk og autentisering av brukere på tvers av sikkerhetsdomener. Innad i et sikkerhetsdomene er det i dag vanlig å bruke protokoller som Kerberos. Kerberos er i utstrakt bruk i helsesektoren gjennom Microsoft AD DS.

Kerberos, og lignende protokoller, er uegnet til bruk over internett blant annet fordi alle Kerberos-klienter må ha et tillitsforhold til samme Kerberos-server, og fordi Kerberos protokollen er sensitiv i forhold til tidssynkronisering.

Det vi i dag kjenner som moderne autentiseringsmekanismer dukket opp på starten av 2000-tallet. Behovet for å autentisere brukere på tvers av sikkerhetsdomener vokste fram mot slutten av 1990 tallet fordi internett hadde åpnet for nye muligheter for samarbeid mellom bedrifter og fordi det oppstod et fokus på sikker innlogging i forbindelse med netthandel.

Security Token Service

I kjernen av HelseID finner du det vi kaller en Security Token Service eller STS. Når du leser spesifikasjoner og andre beskrivelser av denne typen tjenester vil du ofte finne andre begrep i bruk.

I OAuth 2.0 spesifikasjonen brukes begrepet Authorization Server (AS), i OpenId Connect kalles tjenesten en OpenId Provider (OP), mens i SAML brukes begrepet IdP.

Begrepet Security Token Service kommer fra OASIS standarden WS-Trust, hvor den beskriver en web service som utsteder, validerer, fornyer og revokerer sikkerhetsbilletter (security tokens).

Vi synes at begrepet STS beskriver funksjonen tjenesten har på en god og presis måte - de behandler sikkerhetsbilletter. Vi har derfor valgt å bruke STS som navn på den funksjonen kjernekomponenten vår har.

De fleste bruker en eller flere STSer daglig, men vanligvis legger vi ikke merke til dem. Men, de er altså ofte i spill. For eksempel når du logger deg på Facebook eller Gmail, på nettbanken, via ID-Porten, eller på din Windows-pc på jobben.

Sikkerhetsbillettene som HelseID utsteder er alltid kryptografisk signert, noe som gjør det mulig for mottakerne å validere dem. Valideringen består av å verifisere at de ikke er endret etter signering og at de faktisk er signert og utstedt av HelseID og ikke noen andre.

Nøyaktig hvordan en STS utveksler, validerer fornyer og revokerer sikkerhetsbilletter er avhengig av hvilke protokoller og mekanismer den behersker og tilbyr.

Protokollhistorikk

De to første gruppene av standarder som ble opprettet og tatt i bruk er SAML og WS-Security. Begge oppstod på starten av 2000-tallet, og ble opprettet som følge av nye behov som oppstod i forbindelse med utbredelsen av internett, samt den brede anvendelsen av XML baserte tjenester i datasystemer.

SAML

SAML er en åpen standard som finnes i tre versjoner: 1.0, 1.1 og 2.0. Standarden beskriver hvordan autentisering og autorisasjonsdata utveksles mellom en identitetstilbyder og en tjenestetilbyder. SAML standarden definerer et XML basert språk, som brukes til å formatere meldinger. Dette språket kalles SAML assertions. I tillegg til SAML assertions finnes det også protokoller, profiler og beskrivelser av såkalte bindinger.

Såkalte SAML assertions er i utstrakt bruk i mange systemer i dag, men er ikke bare benyttet i SAML protokollene eller profilene. Blant annet brukes SAML assertions også i WS-Security baserte protokoller. 

Siste versjon av SAML ble en OASIS standard i 2005, og har ikke endret seg mye i løpet av de siste årene.

HelseID støtter foreløpig ikke SAML baserte mekanismer.

WS-Security

WS-Security er en del av WS-* standardene, som beskriver mekanismer for Web Services. Disse standardene beskriver forskjellige aspekter av sikkerhetsmekansimene som er nødvendige for å lage sikre SOAP baserte tjenester.

De mest relevante standardene er WS-Security, WS-Trust, WS-Federation.

HelseID støtter foreløpig ikke WS-Security baserte mekanismer.

Protokoller i bruk i HelseID

HelseID bruker et åpent rammeverk som heter IdentityServer4 som STS. Dette rammeverket implementerer sikkerhetsmekanismene som er beskrevet i rammeverket OAuth 2.0, og i protokollen OpenId Connect.

OAuth 2.0

OAuth 2.0 er en åpen standard som beskriver delegert tilgangsstyring av ressurser. OAuth 2.0 er ikke en enkeltstående spesifikasjon av hvordan denne mekanismen skal fungere, men et rammeverk bestående av mange relaterte spesifikasjoner.

Spesifikasjonene beskriver en mekanisme med noen få veldefinerte roller, og en av disse rollene kalles Authorization Server. HelseID er en slik Authorization Server, men vi bruker termen STS for å beskrive rollen ettersom vi tilbyr flere mekanismer enn OAuth 2.0.

OAuth 2.0 beskriver også det vi kaller Grant Types. Les mer om dette på sidene som omhandler autentiseringsflyt og grant types.

Rammeverket OAuth 2.0 forbedres kontinuerlig, og tilpasses stadig flere bruksområder og nye krav og behov. I motsetning til SAML og WS-Federation som kan ansees som ferdigutviklede er OAuth 2.0 et rammeverk som stadig er i bevegelse.

Delegering av tilgang og User Consent

Et vanlig bruk av OAuth 2.0 mekanismene er å la sluttbrukeren delegere eller gi tilgang til sin informasjon til en tredjepart uten å dele ut sin brukernavn/passord kombinasjon. Sentralt i denne flyten er mekanismen som i spesifikasjonene kalles User Consent. Dette konseptet går ut på at brukeren gir sin eksplisitte tillatelse til at en klient (mobil app, webapplikasjon osv) kan få tilgang til brukerens informasjon i en tjeneste. Et typisk eksempel på denne mekanismen i spill er når du bruker facebook eller Google til å logger deg inn i en annen applikasjon. Da vil du vanligvis bli vist et skjermbilde hvor du må godkjenne at applikasjonen gis tilgang til angitt informasjon i Facebook eller Google.

Men OAuth 2.0 mekanismene kan også benyttes uten User Consent, og i vår sektor vil dette ofte være aktuelt ettersom brukeren allerede opptrer på vegne av av pasienten.

Klienter, ressurser, scopes og claims

I tillegg til Authorization Server og User Consent finnes det andre sentrale begreper i OAuth 2.0 som: Klient, Ressurs, Scope og Claim. Les mer om disse i spesifikasjonene og på våre sider om terminologi.

Kort oppsummert kan du opprette det vi kaller klienter, med tilhørende konfigurasjon, i HelseID.

I OAuth 2.0 representerer en klient en applikasjon eller tjeneste som ber en STS (HelseID i vårt tilfelle) om å få tilgang til en ressurs (API). Klientkonfigurasjonen, som lagres i HelseID, angir hvorvidt klienten har rett til å få tilgang til ressursen. Applikasjonen kan be om tilgang på vegne av en bruker eller som en maskin-til-maskin forespørsel.

Når klientkonfigurasjonen er opprettet og konfigurert i applikasjonen vil klienten sende en forespørsel til en STS (eller Authorization Server) som inneholder et parameter som heter "scope". Verdien av parameteret angir hvilken eller hvilke ressurser klienten ber om tilgang til. STS returnerer et token som klienten legger ved i forespørselen mot APIet som et bevis på at klienten har fått tillatelse til å kalle APIet. Når APIet mottar forespørselen vil det undersøke tokenet, verifisere at det er utstedt av HelseID, og at APIet er riktig mottaker.

Tokenet kan også inneholde informasjon om brukeren som klienten opptrer på vegne av. Denne informasjonen kan brukes av APIet for å utføre tilgangsstyring.

OpenId Connect

OAuth 2.0 har fått bred oppslutning og ble raskt implementert og tatt i bruk i industrien. Men, OAuth 2.0 rammeverket mangler beskrivelser av hvordan man skal håndtere  autentisering av brukere. Det var et åpenbart behov for protokoller som sikrer interoperabilitet i forbindelse med autentiseringsprosessen, derfor ble spesifikasjonen av OpenId Connect påbegynt. OpenId er organisert som en stiftelse som består av flere av de største aktørene i industrien. Stiftelsen har utarbeidet en familie av spesifikasjoner som beskriver autentiseringsmekanismene.

I praksis er OpenId Connect et relativt tynt lag som er bygd på toppen av OAuth 2.0. OpenId Connect har derfor lånt de fleste av begrepene sine fra OAuth 2.0 spesifikasjonen, men det er greit å vita at de i noen tilfeller har forskjellig semantisk betydning.

Rollen HelseID har i sammenheng med OpenId Connect kalles i spesifikasjonene OpenId Connect Provider, i motsetning til rollen Authorization Server i OAuth 2.0. Men på et overordnet nivå utfører de den samme oppgaven - å utstede sikkerhetsbilletter. HelseID har, som tidligere nevnt, valgt å kalle kjernekomponenten en STS, selv om den i spesifikasjonen heter noe annet.

ID Token

OpenId Connect beskriver altså hvordan autentiseringsprosessen skal utføres, og bygger på mange av konseptene som blir beskrevet i OAuth 2.0 rammeverket. Men den største nyheten som OpenId Connect innfører er en ny type token som kalles et ID Token.

ID Tokenet er alltid en såkalt JWT (Json Web Token), og inneholder claims som beskriver den autentiserte brukeren. Det kan være informasjon som f.eks. fornavn, etternavn, fødselsnummer. I HelseID vil du også kunne få informasjon som er spesifikk for vår sektor, f.eks. HPR-nummer samt annen informasjon fra HPR i ID Tokenet.

Ressurser og scopes i OpenId Connect

Begrepene klient, ressurs, scopes og claims brukes i OpenId Connect, men i motsetning til i OAuth 2.0 er ressursene i dette tilfellet brukere. Et scope i denne sammenhengen er altså en forespørsel om en informasjon eller en påstand om brukeren. Mens du i OAuth ber om et scope som representerer en tilgang til et API vil du OpenId Connect be om et scope som beskriver brukeren.

I HelseID vil for eksempel en forespørsel om scopet "profile" bety at ID Token vil inneholde brukerens navn, fornavn, mellomnavn og etternavn.

På sidene Autentisering og  Autentiseringsflyt og grant types kan du lese mer om OpenId Connect, og hvordan mekanismene fungerer.