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.
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.