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.

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.

 Scenario 1 - Egen IdP - Egen konsumtion av e-legitimationer

Organisationen har en central intygsutfärdare (identity provider, IdP) i egen eller annans regi och är direkt ansluten till de nationella e-legitimationsutfärdarna som organisationen valt att konsumera. E-tjänsterna (SP) i organisationerna använder den centrala intygsutfärdaren för att konsumera e-legitimationer via SAML eller OpenID Connect (OIDC).  Organisationen i detta exempel har också den tekniska förmågan att konsumera autentiseringsmetoder via SAML och den IdP som används har förmåga att anslutas till Ineras säkerhetstjänster (IdP).

Som alternativ till att konsumera den nya autentiseringsmetoden via SAML kan den också konsumeras via autentiseringstjänstens API (den streckade linjen).

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

Organisationen har en central intygsutfärdare (identity provider, IdP) i egen eller annans regi och är via en så kallad infratjänst, ibland också benämnd e-legitimeringstjänst, ansluten till de nationella e-legitimationsutfärdarna som organisationen valt att konsumera. E-tjänsterna (SP) i organisationerna använder den centrala intygsutfärdaren för att konsumera e-legitimationer.

Med infratjänst avses en leverantör som levererar en e-legitimationstjänst som oftast upphandlats i egen regi eller avropats via Kammarkollegiets ramavtal Programvaror och tjänster 2014, Informationsförsörjning eller motsvarande. Ofta förekommande leverantörer är bland annat CGI, Cybercom, Nexus, PhenixID, Svensk e-identitet, Tieto och Visma.

Om organisationen har den tekniska förmågan att hantera konsumtion av autentiseringsmetoder via SAML så bör anslutning ske direkt till Ineras säkerhetstjänster i enlighet med Scenario 1.

Om organisationen inte har den tekniska förmågan att ansluta till Ineras Säkerhetstjänster bör anslutning ske via den mellanhand som också hanterar de nationella e-legitimationerna.

Undersök kostnadsbilden för anslutning till Ineras autentiseringstjänst via infratjänsten. Inryms det i befintligt avtal, eller måste det upphandlas? Samt se över personuppgiftsbiträdesrelationen

 Scenario 3 - Intygsutfärdare (IdP) som tjänst

Organisationen har en köpt tjänst för att ställa ut identitetsintyg till konsumerande e-tjänster.

För denna organisation rekommenderas en anslutning till Ineras Säkerhetstjänster IdP via den köpta tjänsten. 

Undersök kostnadsbilden hos tjänsteleverantören för anslutning direkt till Ineras Säkerhetstjänster Idp, Inryms det i befintligt avtal, eller måste det upphandlas? Samt se över personuppgiftsbiträdesrelationen.

 Scenario 4 - Ineras Säkerhetstjänster som IdP

Om det är Ineras Säkerhetsjänster som används som IdP-tjänst har denna redan stöd för den nya autentiseringsmetoden. Det enda som behöver göras är att fylla i förstudien för den tekniska anslutningen.

Notera att Ineras Säkerhetstjänster idag inte konsumerar alla av DIGG godkända e-legitimationer.

Det är viktigt att säkerställa de kommersiella villkoren med e-legitimationsutfärdarna och mellanhänderna om anslutningsvägarna till e-legitimationsutfärdarna förändras. Inte sällan är det den bakomliggande orsaken till att det finns en infratjänst, dvs den har upphandlats som en tjänst i syfte att förenkla konsumtion av flera e-legitimationer inom ramen för ett avtal.

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.

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. Vilken version av Net ID Enterprise använder Inera under testarna?
   Versionerna 6.8.1 och 6.8.2

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

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

9. 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://confluence.cgiostersund.se/x/GaihCg, 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 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.
   

10. Behöver man flera anslutningar vid ADFS vid begär 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://confluence.cgiostersund.se/x/GaihCg, 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.

11. Vilka attribut 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.

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

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

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

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

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

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

18. Nu slutar Inera supporta Net iD Enterprise?
    Inera kommer inte ta emot supportfrågor som berör Net iD Enterprise efter 2023-06-30

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

    Nya lösningar inom SITHS.mp4

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

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

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

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