Innehåll:

Bakgrund

All SITHS-kortinloggning med hjälp av både gamla och nya IdP:n har hittills efter dispens från Sambi setts som likvärdiga oavsett utgivningssätt. Sättet ett SITHS-kort är utgivet på styr vilken tillitsnivå det anses ha. Nivåerna kallas Level of Assurance (LoA) och kommer härefter kallas LoA-nivå.

Med lanseringen av SITHS e-id har LoA-nivån på SITHS-korten förtydligats genom att denna ingår i namnet på kortets certifikat. Till exempel är ett SITHS e-id-kort med certifikatet SITHS e-id Person HSA-id 3 CA v1 är ett kort utgivet med högsta använda tillitsnivå LoA 3 medan SITHS e-id Person HSA-id 2 CA v1 är utgivet med lägre tillitsnivå LoA 2 utgivet med rutiner för utlämnande av reserv- och crossborder-kort.

Hittills har alltså all lyckad SITHS-kortinloggning resulterat i en SAML-biljett med tillitsnivå LoA 3. Förändringen när dispensen löper ut betyder att IdP kommer att börja rapportera SITHS-kortets verkliga tillitsnivå i, bland annat, den utställda SAML-biljetten. Notera att gamla, ej uppgraderade SITHS-kort (inklusive eventuella s k "mjuka" certifikat av typen SITHS Type 3 CA v1 PP som ibland används i automatiska tester) kommer att betraktas som LoA 2.

Tidsplan för förändringen

Vad behöver e-tjänsterna göra?

Den första frågan förvaltningen av en e-tjänst måste reda ut är vilka krav på LoA-nivå som gäller för inloggning i den aktuella e-tjänsten. Får man logga in med reserv/crossborder-kort LoA 2 eller krävs den högsta använda LoA-nivån 3?

Den andra frågan är hur e-tjänsten vill kontrollera att inloggningen sker med ett SITHS-kort med tillräckligt hög tillitsnivå. Gör man det genom att evaluera utställd biljett och därmed sköta behörighetsstyrningen själv eller vill man att IdP:n ska rapportera misslyckad inloggning genom att i anropet till IdP:n (AuthRequest→ RequestedAuthnContext) ange vilken/vilka LoA-nivåer som e-tjänsten kräver för en lyckad inloggning?

1. Varje förvaltning av en e-tjänst ansluten till IdP ombeds att se över ifall den anger LoA-nivå i sitt AuthRequest (eller motsvarande filtrering av claim/scope inom OIDC)  och fundera på om detta fungerar med e-tjänstens krav på LoA-nivå när reservkort och gamla, ej uppgraderade, SITHS-kort börjar att rapporteras som LoA 2 enligt tabellen nedan. 

Observera att ifall en SP till exempel accepterar både LoA 2 och LoA 3 och vill ange detta i sitt AuthnRequest så måste båda skickas med då IdP endast har stöd för exakt jämförelse av tillitsnivå (detta då SAMBI ställer det som tekniskt krav).

Ett tillvägagångssätt att ta reda på en e-tjänsts AuthnRequest finns beskrivet i FAQ #28. Motsvarande för OIDC (jwt) i FAQ #29.

2. Varje förvaltning av en e-tjänst ansluten till IdP ombeds att se över ifall

a) den begär attributet (urn:sambi:names:attribute:levelOfAssurance eller acr i OIDC fallet) för LoA-nivå i sitt metadata och därmed i SAML/JWT-biljetten och

b) fundera på om detta attribut evalueras av e-tjänsten och - i sådana fall om detta fungerar med e-tjänstens krav på LoA-nivå när reservkort och gamla, ej uppgraderade, SITHS-kort börjar att rapporteras som LoA 2 enligt tabellen nedan.

Se även avsnittet om Tillitsnivå (LoA) i Anslutningsguide till IdP

SITHS-kort och eventuell ny LoA-nivå

Följande tabell visar på vilka typer av kort/certifikat IdP stödjer och vilken LoA-nivå som kommer att rapporteras i och med förändringen.

För frågor kontakta Ineras Support