Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.
Innehållsförteckning

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

...

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.

...

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.

...

Expandera
titleUtfärdandeprocess mobilt SITHS eID

SITHS eID i Android och iOS utfärdas genom att id-växling sker från ett aktivt SITHS-kort (SITHS eID på tillitsnivå 3) varpå ett nytt SITHS eID-certifikat skapas med nyckelmaterialet från klienten som grund.

Konsumtionsmöjligheter

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

...

Expandera
titleAvgränsade konsumtionsmöjligheter

Det är inte ovanligt att autentiseringslösningar konsumeras på andra sätt än via SAML eller OpenID Connect (OIDC) i de egna eller de upphandlade e-tjänsterna (SP), exempelvis genom en direkt integration med en PKI-infrastruktur vilket är rätt vanligt i just SITHS-fallet. Ofta benämns denna typ av integration för mutual TLS (mTLS)

Den nya autentiseringslösningen har inte den integrationsmöjligheten vilket särskilt måste beaktas.

För att inventera vilka direktintegrationer med SITHS PKI som finns kan exempelvis anrop till SITHS spärrlistor detekteras i centrala kommunikationspunkter i den egna infrastrukturen där dessa anrop passerar. För detaljer om adresser se Nätverksinställningar för SITHS Certifikatsutfärdare.

Notera att anrop görs även för att exempelvis spärrkontrollera SITHS-funktionscertifikat vilket behöver beaktas vid analysen av den insamlade trafiken.

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.

...

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

...

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.

...

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.

...

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.

...