...
System som bare gjør brukerpålogging | Trenger normalt ikke å godkjennesGodkjenning er anbefalt | |
|---|---|---|
System som bare gjør maskin-til-maskin for api-kall | Trenger normalt ikke å godkjennesGodkjenning er anbefalt | |
System som kombinerer brukerpålogging med api-kall | Godkjenning er påkrevd | |
API-er som beskytter sensitive helseopplysninger | Godkjenning er | anbefaltpåkrevd |
HelseID kan be om en godkjenning av en programvare selv om den normalt ikke trenger å godkjennes dersom vi likevel mener det er behov for det.
I kodegjennomgangen ser vi på følgende:
Implementasjon av protokollmekanismer.
Har klienten implementert de påkrevde mekanismene på en tilfredsstillende måte?
Vi ser særlig på hvordan access tokens og refresh tokens håndteres og beskyttes.
Håndtering av hemmeligheter.
Er hemmelighetene som benyttes for klientautentisering beskyttet godt nok?
Systemarkitektur.
Følger klienten beste praksis? Bryter klienten med noen av kravene som sikkerhetsprofilen til HelseID stiller?
Følger klienten beste praksis for webklienter?
Gjør klienten unødvendig mange kall mot HelseID?
Er klienten robust for endringer i HelseID?
Validering av tokens og claims
Valideres tokens på riktig måte?
Gjør klienten validering av de riktige claimene?
Brukes riktige claims for å gi tilgang til klient eller api?
Vi ser ikke på følgende:
Overordnet systemarkitektur
Brukergrensesnitt
Annen implementasjon som ikke angår HelseID
...
I de tilfeller der leverandør ikke kan dele kildekoden for integrasjonen med HelseID kan alternative framgangsmåter diskuteres. Det viktige for HelseID er å sikre at løsninger som produksjonsettes ikke har store feil eller svakheter og at leverandør tar ansvar for å rette eventuelle mindre feil eller svakheter som blir funnet. En tilstrekkelig detaljert løsningsbeskrivelse kombinert med et inngående intervju med med teknisk personell fra leverandør kan erstatte innsyn i kildekoden.