Security profile for identity providers

 

ID

Krav

Kategori

(Obligatorisk eller Valgfritt)

ID

Krav

Kategori

(Obligatorisk eller Valgfritt)

T-1

Alle endepunkter i tjenesten skal være sikret med TLS.

O

T-2

Tjenesten skal støtte protokollen OpenID Connect.

O

T-3

Tjenesten skal støtte brukerautentisering på et sikkerhetsnivå angitt av selvdeklarasjonsforskriften. Forskriften finnes her: https://lovdata.no

O

T-4

Tjenesten skal angi hvilket sikkerhetsnivå en vellykket autentisering ble gjennomført på i påstanden "acr" [OIDC].

Følgende verdier ansees som gyldige: 

  • "Lavt" 

  • "Betydelig" 

  • "Høyt" 

O

T-5

Tjenesten skal angi hvilken autentiseringsmekanisme som ble brukt for en vellykket autentisering i påstanden "amr" [OIDC].

O

T-6

Tjenesten skal alltid signere ID Tokens og JWT formatterte Access Tokens. 

O

T-7

Tjenesten skal ikke bruke "none" i JOSE header for JWTs eller Access Tokens. 

O

T-8

Tjenesten skal bruke de kryptografiske algoritmene PS256 eller ES256 til signering og kryptering.

O

T-9

Tjenesten skal ikke benytte algoritmer som er definert i kryptopakken RSASSA-PKCS1-v1_5 til signering eller kryptering. 

O

T-11

Tjenesten skal autentisere HelseID som klient, enten med:

  • mTLS, eller hemmelighetstypen

  • "private_key_jwt" client-assertion

O

T-12

Tjenesten skal enten kreve verdiene "code" eller "code id_token" som gyldige verdier for parameteret response_type i autentiseringsforespørselen. 

O

T-13

Tjenesten skal ikke støtte klienter som ikke blir autentisert (public clients), f.eks. ved bruk av “implicit flow”.

O

T-14

Tjenesten skal kunne beskytte autorisasjonskoden i Authorization Code Flow ved å tilby mekanismen Proof Key for Code Exchange (som definert i https://tools.ietf.org/html/rfc7636). 

O

T-15

Tjenesten bør støtte kryptering av ID Token

V

T-16

Tjenesten bør støtte autentiseringsforespørsler i form av JWT som angitt i OpenID Connect (https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests).

Dersom tjenesten støtter autentiseringsforespørsler som JWT: 

  • må verdien i parameteret "request" i autentiseringsforespørselen være en signert JWT. 

  • må tjenesten ikke akseptere verdien alg: 'none' i JOSE headeren.

  • bør tjenesten støtte at alle parametre for autentiseringsforespørselen kan finnes i et request object som blir sendt i request eller request_uri parameteret.

V

T-17

Tjenesten bør tilby MTLS (https://www.rfc-editor.org/rfc/rfc8705.html) som mekanisme for å verifisere eierskap til privat nøkkel, og for å sikre mot tyveri av tokens. 

V

T-18

Som angitt i anbefalingene for sikker bruk av TLS og DTSL (https://tools.ietf.org/html/bcp195) bør kun følgende kryptopakker (cipher suites) benyttes for TLS: 

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 

V