Funksjonelle krav for klienter og API-er som integerer med HelseID
| Termer | |
|---|---|
| HelseID | En autorisasjonstjener, som beskrevet i RFC 6749. Blir brukt til å sikre nasjonale API-er for helsesektoren. |
| Klient | En klient (client) som definert i RFC 6749. I kontekst av HelseID er en klient en programvareinstallasjon som følger denne sikkerhetsprofilen. |
| Nøkkelord | Nøkkelordene må, må ikke, skal, skal ikke, bør, og kan i dette dokumentet må tolkes slik som nøkkelordene must, must not, shall, shall not, should, og may i RFC2119. |
Funksjonelle krav for alle HelseID-klienter
FK1: Alle klienter må bruke et sertifisert OAuth2- eller OpenID Connect-klientbibliotek hvis et slikt er tilgjengelig for det brukte programmeringsspråket. Vår liste over anbefalte klientbiblioteker finnes her.
FK2: Alle klienter må bruke informasjon fra HelseIDs metadata-endepunkt i stedet for å hardkode URL-er for endepunkt og andre konfigurasjonsverdier. Metadata-endepunktet vil alltid være tilgjengelig på https://helseid-sts.nhn.no/.well-known/openid-configuration (i produksjon). Metadataene skal caches slik at klienten ikke gjør unødvendige kall mot HelseID, vi anbefaler caching i 24 timer.
FK3: Klienter skal ikke be om nye Access-token dersom et allerede utstedt token fremdeles er gyldig for den aktuelle ressursen de skal kalle. Dette betyr at klienten må implementere en caching-mekanisme der expires-in-parameteren definerer hvor lenge Access-tokenet skal lagres.
FK4: Klienter må synkronisere sin lokale klokke med klokken til HelseID. Klienter med tilgang til Helsenettet kan bruke ntp.nhn.no for dette formålet.
FK5: Hvis klienten trenger å sende fingranulert autorisasjonsinnhold (organisasjonsnummer, helsepersonellets attest, eller lignende) til HelseIDs /token-endepunkt, skal den bruke assertion_details-strukturen som beskrevet her.
FK6: Enhver klient må kvalitetssikre og verifisere integrasjonen mot HelseID. Dette skal gjøres i HelseID sitt testmiljø. Denne klienten må testes på nytt hvis integrasjonen skal endres. Når HelseID oppdateres (ved planlagte endringer) bør klienten også testes på nytt.
Funksjonelle krav for klienter som trenger brukerinnlogging
Kravene er en utvidelse av de generelle kravene for alle HelseID-klienter.
FB1: Klienten skal ikke bruke Access-tokenet for tilgangskontroll. Access-tokenet skal ikke inspiseres av klienten, og må sees på som ugjennomsiktig for klienten.
FB2: Klienten skal ikke tillate innlogging for pasienter eller innbyggere, innlogging via HelseID skal bare brukes av ansatte i helsesektoren i jobbsammenheng.
Funksjonelle krav for API-er som skal sikres med HelseID
FA1: API-et må bruke et sertifisert OAuth2-bibliotek for tokenvalidering hvis et slikt er tilgjengelig for det brukte programmeringsspråket. Vår liste over anbefalte klientbiblioteker finnes her.
FA2: API-et skal bruke informasjon fra HelseIDs metadata-endepunkt i stedet for å lagre signeringsnøkler og andre konfigurasjonsverdier. Metadata-endepunktet vil alltid være tilgjengelig på https://helseid-sts.nhn.no/.well-known/openid-configuration (i produksjon). Metadataene skal caches slik at API-et ikke gjør unødvendige kall mot HelseID, vi anbefaler caching i 24 timer.
FA3: API-et må synkronisere sin lokale klokke med klokken til HelseID. API-er med tilgang til Helsenettet kan bruke ntp.nhn.no for dette formålet.
FA4: FAPI 2.0-profilen og sikkerhetsprofilen til HelseID tar utgangspunkt i at all trafikk kjører over HTTP-protokollen. Tjenester som bruker andre protokoller eller mekanismer kan brukes, men de krever at vi gjør egne sikkerhetsvurderinger. Ta kontakt med HelseID-teamet hvis du har et slikt behov.