Bakgrund

Inera lanserar nu en ytterligare autentiseringsmetod som har stöd för nyare versioner av Android och iOS samt Windows 10. Detta skapar förutsättningar för autentisering i fler tekniska plattformar än dagens lösning, till exempel mobila enheter som telefoner och surfplattor. Autentiseringsmetoden är godkänd av Myndigheten för digital utveckling (DIGG) och får bära kvalitetsmärket Svensk e-legitimation.

Inera har som ett övergripande mål att främja digital utveckling i samhället i allmänhet, och i den offentliga sektorn i synnerhet. En bärande idé i detta är att Inera ska bidra till att skapa förutsättningar för säker digital samverkan genom att tillhandahålla långsiktigt hållbara lösningar som kan accepteras och tillämpas inom hela den offentliga sektorn.

Inera levererar idag smarta kort till regioner, kommuner, privata utförare, tjänsteleverantörer och några myndigheter. Totalt finns det över 550.000 innehavare av SITHS-kort.

Om vägledningen

Syftet med denna vägledning är att stödja kommuner, regioner och andra organisationer som har tjänster som ska konsumera den nya autentiseringsmetoden. Vägledningen ska hjälpa beslutsfattare i sina strategiska val och guida i införandet.

Målgruppen för vägledningen är beslutsfattare, CIO, it-ansvarig eller motsvarande samt nyckelpersoner som arbetar med e-legitimationer och IAM i kommuner, regioner och andra SITHS-anslutna organisationer.

Vägledningen har samma disposition och upplägg som SKR:s vägledning om anslutning till eIDAS.

Målbild

Målbilden är att samtliga kommuner, regioner och andra SITHS-anslutna organisationer som har behov av en mobil autentiseringslösning adderar den nya autentiseringsmetoden i sin lösning för intygsutfärdande (Identity Provider, IdP). På längre sikt även använda samtliga funktioner som den nya autentiseringsmetoden erbjuder.

För att kunna införa den nya autentiseringsmetoden behöver ett förarbete göras. Strategiska och taktiska beslut behöver fattas innan man tekniskt implementerar den nya lösningen.

Inera stödjer kommuner och regioner genom att löpande ha direktkontakt med lokal införandeansvariga, publicera webinarier, förstärkt support, löpande uppdatera på publika webbsidor och nyhetsbrev.

Nya autentiseringsmetoden

Lösningen bygger på den gemensamma referensarkitekturen för identitet och åtkomst och ska verka för gemensam hållbar samverkan.

Open

Figuren ovan visar arkitekturen på lösningen för separata kanaler mellan verksamhetsinformation och säkerhetsinformation.

Lösningen är byggd så att klienter på mobil och i datorn kommunicerar i säker, separat kanal vid autentisering.

Konsumtionsmöjligheter

Det finns flera olika konsumtionsmöjligheter för den nya lösningen . Den nya autentiseringsmetoden är tillgänglig via:

• Ineras Säkerhetstjänster (IdP)

• SAML i egen eller upphandlad intygsutfärdare (IdP)

• Relying Party API i egen eller upphandlad intygsutfärdare (IdP)

Egna eller upphandlade e-tjänster (SP) konsumerar den nya autentiseringsmetoden via SAML eller OpenID Connect (OIDC) från den egna eller den upphandlade intygsutfärdaren (IdP).

Vägval

Alla kommuner, regioner och andra SITHS-anslutna organisationer har olika förutsättningar att konsumera autentiseringsmetoder. Förslagen väg fram tar utgångspunkt från idag vanligt förekommande lösningar för konsumtion av nationella och internationella e-legitimationer, e-tjänstelegitimationer och egna autentiseringslösningar.

I denna vägledning används begreppet e-legitimation oavsett vilken form av autentiseringslösning eller autentiseringsmetod som avses, oavsett också om e-legitimationen används i tjänsten eller privat. Gemensamt är att de autentiserar en fysisk person.

Det är inte ovanligt att en organisation av olika skäl har flera olika lösningar för att konsumera e-legitimationer varför det också kan bli aktuellt att resonera om en konsolidering av lösningar i samband med en vägvalsdiskussion. Det är sällan något självändamål att ha flera olika lösningar.

De scenarios som beskrivs i denna vägledning är:

1. Egen IdP - Egen konsumtion av e-legitimationer

2. Egen IdP - Konsumtion av e-leg via infratjänst

3. Intygsutfärdare (IdP) som tjänst

4. Ineras Säkerhetstjänster som IdP

Resonemangen i vägledningen är allmänt hållna och ska ses som just vägledande. I resonemangen finns det inte några hinder att exempelvis flera kommuner tillsammans hittar en gemensam väg fram för att lösa konsumtion av den nya autentiseringsmetoden. 

I samtliga scenarios förutsätts att e-tjänsterna (SP) redan idag konsumerar e-legitimationer via en intygsutfärdare (IdP) med protokoll likt SAML eller OpenID Connect (OIDC). Tillägget av ytterligare en autentiseringsmetod, e-legitimation, påverkas inte av detta utan användaren får ytterligare ett val när denne ska välja e-legitimation vid inloggningstillfället.

Om e-tjänsterna har direktintegrationer med e-legitimationerna behöver dessa ses över. Det är även fortsatt ett möjligt scenario att konsumera alla e-legitimationer med en direktintegration i varje enskild e-tjänst, men det kan inte anses vara en långsiktigt hållbar väg fram varför denna vägledning avgränsas från det scenariot.

Single sign-on (SSO)

Det är fullt möjligt att etablera single sign-on för e-legitimationsinnehavarna i lösningarna som resoneras kring i denna vägledning. Det är dock viktigt att tänka på att en organisation kan ha flera olika lösningar för att konsumera e-legitimationer vilket tydliggörs i några av vägvalen. Det är heller inte ovanligt att en organisation har implementerat flera av lösningarna som presenteras i vägvalsdiskussionen. Det försvårar onekligen en övergripande användarupplevelse av single sign-on för e-legitimationsinnehavaren. Det tillhör dessutom ovanligheten att flera olika lösningar för att konsumera e-legitimationslösningar samverkar utan de uppträder oftast som enskilda öar, här beskrivet som domäner. Detta blir särskilt märkbart om det finns en önskan att etablera single sign-on i en lösning som inte är homogen vilket särskilt behöver beaktas. Inte minst i en vägvalsdiskussion.

Open

I det exemplifierade scenariot återfinns samma e-legitimation bakom flera olika intygsutfärdare (IdP). För en användare som loggar in i en tjänst som använder en IdP och sedan i en annan tjänst som använder annan IdP är det långt från självklart att single sign-on inträffar. Det går att skapa en form av single sign-on på klientnivå, exempelvis genom att memorera pinkoden i den programvara som hanterar ett smart kort, men det är inte en önskvärd väg fram då det äventyrar säkerheten i lösningen.

Omfattning - arbetsinsats

Beroende på organisationens förutsättningar så är omfattningen av ett införande av en ytterligare autentiseringsmetod varierande.

Resonemangen här förutsätter att organisationens e-tjänster har förmåga att konsumera e-legitimationer via SAML och/eller OpenID Connect (OICD).

I de fall organisationen inte har den förmågan kan anpassningen bli omfattande, i vissa fall inte ens möjliga. I de fallen rekommenderas att utredning görs för att dels hitta alternativa vägar fram, dels för att säkerställa att organisationen inte hamnar i en liknande situation igen. Genom att följa referensarkitekturen för identitet och åtkomst säkras detta.

I scenario 1 och scenario 2 har organisationen sannolikt en egen förvaltningsorganisation som har en vana av att implementera autentiseringsmetoder. I det fallet rör det sig sannolikt om ett par dagar att göra den tekniska implementationen och ytterligare någon dag för att lösa de administrativa formaliteterna.

I scenario 3 och scenario 4 har organisationen en köpt tjänst där tjänsteleverantören sannolikt redan anslutit den nya autentiseringsmetoden, eller är på väg att ansluta den. Därför kvarstår det endast administrativa formaliteter att få denna lösning på plats. Här är det också viktigt att säkerställa att detta inryms i befintliga avtal med tjänsteleverantören. Om inte kan det vara aktuellt att tillsätta en mindre utredning för att undersöka den långsiktigt bästa vägen fram.

I sammanhang där organisationen inte kan identifiera sig med något av de scenarios som målats upp här är en utredning att rekommendera för att lägga grund för en långsiktigt hållbar lösning för att konsumera e-legitimationer i största allmänhet. Dvs att utredning inte bara är avgränsad till att införa den nya autentiseringsmetoden utan att ett bredare grepp tas i frågan.

I samtliga fall bör organisationer som ännu inte har förmågan att konsumera europeiska e-legitimationer inom ramen för eIDAS-förordningen se detta som ett tillfälle att även lösa detta. I SKR:s Vägledning för anslutning till eIDAS, vilken denna vägledning inspirerats av, finns förslag på väg fram utifrån likartade scenarios som beskrivs här.

Testning

Att ansluta till den nya autentiseringsmetoden innebär olika arbetsinsatser, beroende på de befintliga lösningarna för konsumtion av SITHS idag. Till exempel om direktintegration med SITHS PKI är gjord idag, kan förmågan till konsumtion via SAML eller OIDC vara omöjlig om inte nyutveckling görs enligt beskrivna scenarion.

Det är viktigt att lägga upp en plan för övergång och genomföra piloter på ett fåtal tjänster för att testa den nya autentiseringsmetoden innan breddinförande genomförs.

Som en del av tekniska anslutningen ska de tekniska delarna i implementationen av en ny autentiseringsmetod testas. Exempelvis i scenario 1 och 2 där utbyten av SAML-metadata samt livscykelhantering av signeringsnycklar i intygsutfärdaren och i Ineras Säkerhetstjänster är av största vikt att kunna hantera.

Att ansluta

Oavsett vilket scenario som en organisation väljer medför det en teknisk anslutning till Inera. För att ansluta till den nya autentiseringsmetoden måste tjänsten beställas. Därefter kan den tekniska anslutningen med förstudie genomföras.

Scenario 1 och 3 avser båda att ansluta en IdP till Ineras IdP och behandlas lika från ett Inera perspektiv. En sammanfattande tabell över för- och nackdelar med de tre olika varianterna kan ses här, där även mer teknisk information finns.

Oavsett vilket scenario som ska realiseras, behöver det göras en beställning och en teknisk anslutning.

För att realisera scenario 1, 3 och 4 beställs anslutning till Säkerhetstjänster IdP

För att realisera scenario 2 beställs anslutningen till Säkerhetstjänster Autentiseringstjänsten

Dessa anslutningar är i dagsläget inte tillgängliga för andra än kommuner och regioner.

Efter att beställningen godkänts och tjänsteavtalet undertecknats går man vidare med förstudien för den tekniska anslutningen.

För att beställa följ instruktionerna här på tjänstesidorna, på Inera.se (Kapitel Beställ Säkerhetstjänster).

Frågor och svar

1. Vilka av Ineras tjänster använder Ineras IdP?
   Det är flera tjänster men främst, Pascal, NPÖ, Intytjänsterna, Personuppgiftstjänsterna, Sebra, Infektionsverktyget, Svevac, Hitta Jämför Vård, Säkerhetstjänster, Pascal Admin och 1177 Admin.

2. Vi har Android-telefoner som inte finns på er lista, kommer dessa att fungera med Mobilt SITHS eID?
   Det är inte möjligt att testa testa alla mobila enheter på marknaden men finns de på Google Enterprise lista kommer de med stor sannolikhet att fungera

3. Kommer det behövas en ny “enrollment”/utfärdande när en användare tar över mobilen/enheten från en annan användare?
   Ja, en enrollment behövs.

4. Finns användarguide för utfärdandet av Mobilt SITHS?

   1. Ja, den finns här Användarhandbok - Utfärdandeportal för Mobilt SITHS ;

   2. och en film finns här Demofilm - utfärdande av Mobilt SITHS

5. Finns användarguide på hur en autentisering går till?

   1. Ja, här finns en film på autentisering med Mobilt SITHS finns här: Autentisering via SITHS eID

6. Jag kan inte installera SITHS eID appen på en iOS-enhet trots att det en giltig/supporterad enhet.
   För att installera och använda SITHS eID appen på en iOS enhet krävs att enheten är ”lösenordsskyddad”

   ”iOS klienter kräver lösenordsskydd för installation/användning (beror på deras Secure Enclave-lösning). För Android klienter behövs inte lösenordsskydd.”

7. Hur många förstudier ska lämnas in för anslutning av en lokal IdP som i sin tur har flera SP?
   En förstudie behöver lämnas in.

8. Vad händer om den nationell HSA-katalogen ligger nere. Kommer Ineras IdP ändå utfärda en biljett?
   Är HSA nere så kommer IdP utfärda en biljett bara om e-tjänsten inte begärt några HSA-attribut ö.h.t. Se Attributlistan på https://inera.atlassian.net/wiki/x/9osjzw, avsnitt 3.1 (Valbara attribut/claims). Tabellen där visar vilka attribut som kommer från HSA.
   E-tjänsten (om SAML) skulle t.ex. kunna ha två "AttributeConsumingService" i sitt metadata, en som begär HSA-data och en (backup) som bara begär certifikatsdata. Får e-tjänsten felmeddelande från IdP att HSA är nere så kan den skicka en ny begäran och ange AttributeConsumingServiceIndex för backup-attributuppsättningen.
   E-tjänster som ansluter via OIDC kan justera sina claimsrequest i Authentication Request till att inte begära HSA-attribut.
   Tyvärr kommer felet att ske först efter att användaren autentiserat sig. D.v.s användaren loggar in korrekt, med i.o.m. att IdP inte får kontakt med HSA så kastas ett fel och ingen SSO-session sätts upp. Om e-tjänsten gör som beskrivet ovan så kommer användaren alltså behöva autentisera sig en gång till.
   
   

9. Behöver man flera anslutningar vid ADFS vid begäran av medarbetaruppdrag?
   Huruvida användaren ställs inför ett val av vårdmedarbetaruppdrag styrs av vilka attribut som e-tjänsten begär från IdP. Se Attributlistan på https://inera.atlassian.net/wiki/x/9osjzw, avsnitt 3.1 (Valbara attribut/claims).
   Tabellen där visar vilka attribut som leder till val av uppdrag respektive val av personpost (EmployeeHsaId). Om användaren bara har ett uppdrag i HSA så väljs det uppdraget implicit av IdP. Användaren ställs alltså inte inför ett uppdragsval.Om användaren bara har en personpost (EmployeeHsaId) i HSA - eller loggar in med ett cert som har HSA-id som identifierare - så väljs personpost implicit av IdP.

10. Vilka attribut behövs för att byta medarbetaruppdrag under pågående pass?
    Om uppdrag redan är valt så måste sessionen avslutas via en utloggningsbegäran till IdP, varpå en ny autentiseringsbegäran görs som kan leda till ett nytt uppdragsval.
    Om uppdrag inte redan är valt så kommer nästa autentiseringsbegäran som begär uppdragsinformation att leda till ett uppdragsval.

11. Vad krävs för att kunna logga in och underteckna i SITHS eID portalen när den införs?SITHS eID Windowsklient (Windows 10) eller SITHS eID Mobilklient (Android/iOS). Notera att Net ID Enterprise inte används för SITHS eID Portalen.

12. Kan Net ID Enterprise och Windowsklienten installeras på samma dator?
    Ja, de kommer kunna samexistera

13. När kommer de nationella tjänsterna stödja inloggning med SITHS eID Windowsklienten eller SITHS eID Mobilklient
    Se följande lista för status för respektive tjänst och införandet av nya autentiseringsmetoden.

14. Vad krävs för att kunna logga in på de nationella tjänster som har inför nya autentiseringsmetoden?
    SITHS eID Windowsklient (Windows 10) eller SITHS eID Mobilklient (Android/iOS)

15. Kommer de nationella tjänsterna fortsätta stödja Net ID Enterprise?
    Finns i dagsläget inget beslutat datum för borttag av stödet för MTLS (den tekniken som Net ID Enterprise använder) men stödet kommer att tas bort i framtiden

16. Vilken kod används för att kunna göra underskrifter i SITHS eID portalen?
    Legitimeringskoden används för både inloggning och underskrift

17. Nu slutar Inera supporta Net iD Enterprise?
    Inera kommer inte ta emot supportfrågor som berör Net iD Enterprise efter januari 2024. Beroendet till Net iD Enterprise avvecklats i och med lanseringen av SITHS eID Portal och SITHS eID Mina sidor januari 2024

18. Finns det en film eller webinar med heltäckande information om nya autentiseringslösningen?
    Ja, här finns den.

     

19. Kommer hantering av korthändelser (kort-i och kort-ur) finns som funktionalitet i SITHs e-ID appen för Windows (Windowsklienten)?

    Denna funktionalitet kommer ej att finnas enligt den omfattning som beslutats just nu. Direktanslutna organisationer får gärna driva att detta ska läggas till i framtiden genom att beställa det från Inera via t.e.x programrådet eller SLIT. Det finns även produkter på marknaden för hantering av denna funktion.
    
    Har er organisation funderat på en separat tag som låser datorn om man inte är nära datorn? Det finns även denna typ av lösningar. Tänk på att kort-in/ut ej fungerar om man loggat in mobilt, då är en tag-lösning bättre.

20. Användningsfall: SSO och uthopp till externa webbapplikation

     

    Ett lokalt system A (t ex ett journalsystem) är anslutet för autentisering via en lokal IdP, vilken i sin tur är ansluten som proxy-IdP mot Ineras IdP för att konsumera autentiseringstekniken med SITHS eID.

     

    Steg 1: En användare loggar in med SITHS eID (på kort eller mobilt) i lokala systemet A.
    Steg 2: Från system A görs uthopp till en extern webbapp, t.ex. NPÖ, som är ansluten till Ineras IdP. 

    Fråga: Kan användaren erhålla SSO i detta fall?

    Svar: Ja, dock förutsatt att samma user agent (webbklient) används vid båda inloggningarna, så att SSO-cookien från Ineras IdP är tillgänglig i Steg 2. 
    Vald webbklient och konfiguration måste verifieras för detta, t.ex. om nya webbfönster eller flikar öppnas så beror ovan funktionalitet på hur webbklienten hanterar dessa (t ex om säkerhetskontextet delas mellan fönster).
    Att tänka på: Förutom detta kan användaren få välja medarbetaruppdrag beroende på vad den externa webappen kräver; detta är inte en del av SSO.

21. Kommer det att ske någon kontroll av hårdvarukraven i prodmiljön? Dvs att man får ett meddelande om man inte uppfyller hårdvarukraven?

    Det kommer finns kontroller för om en given version av SITHS eID-appen eller en version av ett visst OS får användas på enheten. Man får meddelande om enhet inte stöds.

    Dessutom kommer extra kontroller ang aktivering av biometri göras.

22. Finns det support för lagring av egenutfärdade nycklar & certifikat på SITHS-kort?
    I enlighet med nya autentiseringslösningen som följer referensarkitekturen för Identitet och åtkomst och efter en behovsinventering bland SITHS-kollektivet kommer Inera framöver inte supporta lagring av egenutfärdade nycklar & certifikat från lokalt CA på SITHS-kort inom ramarna för SITHS-tjänsten.

    Om en organisation har valt att implementera en lokal utfärdare av nycklar och certifikat är organisationen själv ansvarig för att säkerställa att detta inte påverkar SITHS-tjänsten i övrigt

23. När kommer en version av SITHS eID-appen med möjlighet till anslutning till olika milöer?
    Oktober 2022

24. Testar Inera paketeringar av SITHS eID-Windowsapp på eKlient?

    Inera testar förnärvarande inte nationella tjänster på eKlient, vilket innebär att något formellt test av SITHS eID-app för Windows inte genomförs på eKlient. Inera utreder dock om tester eventuellt ska göras på eKlient i framtiden.  

25. Varnar SITHS eID-appen användaren när Mobilt SITHS närmar sig sista giltighetsdatum?
    Ja, beskrivning finns under punkt 5.1.2. “Ditt eID går ut om XX dagar” i Användarhandboken Användarhandbok - SITHS eID-app för Mobilt SITHS - Inera - Identitet och åtkomst - Confluence (atlassian.net).

26. Kommer Inera att tillhandahålla en autentiseringsapp för Chromebook?

    Inera har för närvarande inga planer på att tillhandahålla en autentiseringsapp för Chromebook. Vill man använda Chromebook för att logga in i SITHS så kan det fungera FÖRUTSATT att de system som används stödjer mobil autentisering. I det fallet används en mobil enhet för autentiseringen, motsvarande när man vid dator loggar in i en internetbank och autentiserar sker via en annan enhet, exempelvis mobil.

27. Q: Konfiguration av Minidriver och SITHS ROTT Ca v1?  

    Om man har ett äldre distansuppgraderat kort som har certifikatet för: SITHS ROOT CA v1 så får användare en dialog från SafeNet som frågar om man vill installera tilliten till certifikatet. Eftersom den CA är avvecklad och vi inte längre centralt hanterar tilliten så litar vi inte på det certifikatet. Vi anser inte att Minidriver ska ha default konfiguration att användare ska få installera tillit till certifikat som SITHS eID klienten läser in.

28. Problem med att SITHS eID-appen kraschar i Citrix på Windows Server 2016 och 2019?

    Som vi tidigare har informerat om tillhandahåller Inera begränsad support för användning av SITHS eID-appen på tunna klienter och virtualiserade klientplattformarna (VDI) Citrix och VMware. För att erhålla denna support krävs att ni som kund tecknar ett extra supportavtal.

    Vi har fått in rapporter om att SITHS eID-appen kraschar i Citrix på Windows Server 2016 och 2019. Detta beror på att SITHS eID-appen kräver att ”Windows push notification service” är aktiverad och startas automatiskt. Läs gärna mer här: SITHS eID-appen på tunna klientplattformar - Inera

29. SAC för Linux  

    Nu finns Safenet Authenticaton Client PKCS#11 för Linux tillgänglig för nedladdning på sidan Programvaror och tillbehör för SITHS under rubriken Användning av SITHS eID på Linux. Observera att om Igel används så ingår det redan i den senaste Igel-distributionen.

30. HSA-ID och personnummer som identifierare
    Personnummer som primär identifierare sker för autentiseringslösningen baserad på Out-of-band-teknik (OOB) men ni har möjlighet att översätta personnumret till HSA-iD i er lokala Idp innan den når den lokala tjänsten.

    Använder ni däremot autentiseringslösningen baserad på Dubbelriktad TLS/Mutual TLS (mTLS) som finns i SITHS eiD-appen för Windows i MD-paketering (som innehåller SAC minidriver) så går det att ha kvar HSA-iD som primär identifierare då detta bestäms av vilka certifikatutfärdare som servern litar på, ingen skillnad mot hur det är idag med Net iD Enterprise.

    Vi har skrivit en fördjupad information om det här: https://inera.atlassian.net/wiki/display/ST/Hantering+av+personidentifierare+vid+autentisering

31. Testmiljö för systemleverantörer - nya autentiseringslösningen
    Vi rekommenderar systemleverantörer som önskar testa Ineras nya autentiseringslösningen tillsammans med systemleverantörens egna tjänster att ta kontakt med sin kund (Region, kommun eller offentligt finaniserad vårdgivare). Det är i dagsläget inte är möjligt för systemleverantörer att ansluta direkt till Ineras IdP eller Autentiseringstjänstens testmiljöer.

32. Reservrutin för testkort och funktionscertifikat för testmiljöer
    Nu finns en reservrutin som ni kan använda om ni har ett akut behov av nytt testkort eller ett funktionscertifikat för testmiljöer. Rutinen gäller fram till dess att den nya SITHS eID Portalen i QA öppnar för testkort samt funktionscertifikat för test. Den nya QA-miljön kommer att öppnas under hösten 2023. Inera återkommer så fort som möjligt med datum: Beställ funktionscertifikat och testkort av Inera - Identifieringstjänst SITHS - Confluence (atlassian.net)