Checklista anslutning till SITHS Autentiseringstjänst

Denna checklista innehåller sammanfattande information om vad respektive organisation måste göra med anledning av införandet av SITHS nya autentiseringslösning, vilken även inkluderar Mobilt SITHS. Det är viktigt att du som ansvarig utgivare tar ansvar för detta arbete och planerar samtliga aktiviteter inom din organisation. Om inte dessa aktiviteter genomförs, kommer ni inte att kunna använda Mobilt SITHS för inloggning i tjänster, inte heller någon av de andra autentiseringsmöjligheterna som den nya autentiseringstjänsten innebär.

Observera att denna checklista är ett levande dokument som kommer att uppdateras kontinuerligt.

Vi behöver hjälp att sprida informationen vidare

Vi vill be dig som är ansvarig utgivare att hjälpa oss att sprida informationen vidare till rätt personer inom din organisation samt till eventuella leverantörer, som informationen i checklistan riktar sig till. Tänk också på att om din organisation är SITHS-ombud, har ni ett ansvar att informera organisationer som anslutit till SITHS via er organisation. Inera ansvarar endast för information mot sina direktanslutna kunder.

Huvudsakliga målgrupper för checklistan är

  • Ansvariga utgivare

  • Tekniskt ansvariga för SITHS, lokal IdP och tjänster anslutna till Ineras IdP

  • IT-arkitekter

  • IT-säkerhetsansvariga

  • ID-administratörer för SITHS

  • Leverantörer av funktionalitet som gäller SITHS

Revisionshistorik

Datum

Författare

Version

Vad har förändrats

2020-05-25

Hasanein Alyassiri

0.97

Upprättande av detta dokument.

2020-05-28

Team autentiseringsprojeket

0.98

Uppdatering av checklistan

2020-06-09

Team autentiseringsprojeket

0.985

Uppdatering av checklistan

2020-06-18

Team autentiseringsprojeket

1.0

Uppdatering av checklistan

2020-09-21

Team autentiseringsprojektet

1.01

Uppdatering av avsnittet brandväggsöppningar

2020-09-23

Team autentiseringsprojektet

1.02

Uppdatering av frågor och svar, Net ID versioner

2020-10-05

Team autentiseringsprojektet

1.03

Uppdatering av Autentiseringstjänstens Relying Party API med exempel

2020-10-06

Team Autentiseringstjänst

1.04

Lade till viktig information för kunder som kör inbäddade webbläsare

2020-10-08

Team Autentiseringstjänst

1.05

Lade till information om routing kopplat till Sjunet

2020-10-13

Team Autentiseringstjänst

1.06

Länk till kodexempel för appväxling vid användning av inbäddade webbläsare

2020-10-19

Team Autentiseringstjänst

1.07

Uppdaterade beskrivningar efter synpunkter från kund

2020-12-18

Team Autentiseringstjänst

1.08

Ny länk till Utfärdandeportalen för Mobilt SITHS i TEST-miljön

2021-01-19

Team Autentiseringstjänst

1.1

Justering av länkar och information som varierar per miljö

Översikt över förberedelser och aktiviteter

1. Utse lokal införande ansvarig och ev. projektorganisation

Utse redan nu en lokal införandeansvarig som ansvarar för införandet av nya autentiseringstjänsten och de autentiseringsmetoder som nya tjänsten innebär bl.a. Mobilt SITHS eID. Lokal införandeansvarig ska tillsammans med ansvarig utgivare ansvara för införandet. Se följande bilaga för rollbeskrivning.  Se bilaga 1 i detta dokument.

2. Teckna anslutningsavtal

För att kunna ansluta er till nya autentiseringsmetoden behövs ett avtal med Inera AB. Avtalet innebär inte nya kostnader för er organisation men reglerar ansvarsfördelningen mellan er organisation och Inera AB. Avtalet ska signeras av firmatecknare i er organisation. Avtalet ska signeras och mailas till oss på Inera.

3. Beställ brandväggsöppningar

För att kunna kommunicera med nya Autentiseringstjänsten och Utfärdandeportalen för Mobilt SITHS eID under era integrationstester, vilka kommer utföras mot Ineras TEST-miljö, krävs det öppningar från er tekniska miljö enligt:

https://inera.atlassian.net/wiki/spaces/IAM/pages/559415533

4. Säkerställ routing

Samtliga komponenter finns både på Internet och Sjunet och det gäller att routa nätverkstrafiken rätt beroende på vilket nätverk som ska användas: Guide för routing över Internet och Sjunet

4. Generellt om IdP-inloggning

För att kunna använda SITHS nya autentiseringstjänst måste respektive tjänst som använder SITHS vara ansluten till en IdP. Det kan vara en egen IdP, Ineras IdP eller annan organisations IdP. Oavsett vilken IdP som används, behöver ni kontrollera nedanstående:

  • Inventera vilka lokala tjänster inom din organisation som använder SITHS för inloggning, säkerställ sedan att de även är anslutna till en IdP. Om tjänsterna inte är anslutna till en IdP måste de anslutas.

  • Om ni vill använda Ineras IdP kontrollera vilka attribut era lokala tjänster behöver och samt om dessa finns i HSA-katalogtjänsten från Inera.

  • Om ni använder egen IdP säkerställ att den kan leverera dessa attribut och att dessa attribut finns i er lokala katalogtjänst som ni ämnar använda.

5. Beskrivning av anslutningsmetoder

Lokal tjänst till Ineras IdP

Förutsättningar:

  • E-tjänsten ansluts som SP till Inera IdP med via SAML2 eller OIDC-protokollet. Här väljs också vilka autentiseringsmetoder som ska finnas tillgängliga för användare.

  • Användarorganisationerna administrerar nödvändiga användarattribut i sin del av HSA-katalogen.

  • Användarnas datorer / mobiler förses med programvara för SITHS eID, antingen på dator och/eller mobilt

Anslutnign av lokal tjänst till Ineras IdP

 

Lokal Idp till Ineras Autentiseringstjänst

I detta fall tillhandahåller organisationens egna IdP de nya autentiseringsmetoderna genom att anropa gemensam Autentiseringstjänst för SITHS.

Användarflödet blir i princip samma som för lokal tjänst till Ineras IdP , men denna gång är det egen IdP som tillhandahåller användargränssnittet.

Förutsättningar:

  • Egen IdP ansluts till Relying party API för Ineras Autentiseringstjänst, se figur 1 nedan

  • E-tjänsten ansluts (är ansluten) som SP till egen IdP. Här väljs också vilka autentiseringsmetoder som ska finnas tillgängliga för användare

  • Användarorganisationerna administrerar nödvändiga användarattribut i den aktuella katalogtjänsten.

  • Användarnas datorer / mobiler förses med programvara för SITHS eID, antingen på dator och/eller Mobil enhet .

Figur 1 - Lokal IdP ansluts direkt till Relying party API för Ineras Autentiseringstjänst

Anslutning av lokal IdP till Ineras Autentiseringstjänst

6. Förberedelser för att kunna använda SITHS Autentiseringsklient

SITHS eID Autentiseringsklient på Windows 10

Detta måste ni göra för att kunna använda den nya Autentiseringstjänsten med SITHS eID-kort på Windows 10. Säkerställ att användarnas datorer:

  1. OBS Framförallt vid användning av inbäddade webbläsare! Säkerställ att den applikation som ni använder för att visa er eller Ineras IdP klarar av att starta protokollet siths:// - Detta används för att starta SITHS eID app vid valet “SITHS eID på denna enhet”. Exempelvis om man kör en webbläsare inbäddad i sitt journalsystem kan detta kräva en åtgärd för att möjliggöra.

    1. För de vanligen förekommande webbläsarna på operativsystemet kommer SITHS eID app installera stöd för detta.

    2. Kodexempel för appväxling via inbäddade webbläsare: https://inera.atlassian.net/wiki/spaces/IAM/pages/482968652

  2. Kan nå Utfärdandeportalen och Autentiseringstjänsten via Internet eller Sjunet med HTTPS på port 443

    1. För detaljer, se https://inera.atlassian.net/wiki/spaces/IAM/pages/559415533

  3. har SITHS eID TEST klienten för Windows 10 installerad: Nedladdningssida för SITHS eID app till Windows 10

SITHS eID Autentiseringsklient på Mobila enheter (Mobilt SITHS eID)

Detta måste ni göra för att kunna använda Mobilt SITHS eID:

  1. OBS! För integrationstester i TEST-miljön krävs att användaren har tillgång till ordinarie SITHS TEST-kort  med TEST SITHS eID certifikat på tillitsnivå 3. Anledningen till detta är att det initialt bara kommer gå att utfärda Mobilt SITHS efter autentisering av användaren på tillitsnivå 3.

  2. OBS! Framförallt vid användning av inbäddade webbläsare! Säkerställ att den applikation som ni använder för att visa er eller Ineras IdP klarar av att starta protokollet siths:// - Detta används för att starta SITHS eID app vid valet “SITHS eID på denna enhet”. Observera dock att rekommendationen vid appväxling på den mobila enheten är att använda sig av standardwebbläsaren på enheten för att visa IdP:ns användardialog.

    1. För de vanligen förekommande webbläsarna på operativsystemet kommer SITHS eID app installera stöd för detta.

    2. Kodexempel för appväxling via inbäddade webbläsare:

  3. Införskaffa mobila enheter enligt Ineras kravlista. Se följande sida för krav och supportade Mobila enheter Mobila enheter och OS som uppfyller kraven för SITHS eID version 1.0

  4. Kan nå Utfärdandeportalen och Autentiseringstjänsten via Internet eller Sjunet med HTTPS på port 443

    1. För detaljer, se

  5. Säkerställ att användarnas datorer har SITHS eID TEST klienten för Windows 10 installerad: Nedladdningssida för SITHS eID app till Windows 10

  6. Säkerställt att användarna har appen för SITHS eID TEST installerad på sina mobiltelefoner eller surfplattor. Appen ligger dold i nuläget, men kommer vara tillgänglig för betatestning via direktlänkar till appbutiken för  iOS respektive Android.

  7. Hänvisa era användare till nedladdning av Mobilt SITHS eID:

    1. TEST - Utfärdandeportal för Mobilt SITHS

    2. QA - Utfärdandeportal för Mobilt SITHS

    3. PROD (TEMPORÄR) - Utfärdandeportal för Mobilt SITHS

7. Förberedelser för att kunna använda SITHS Autentiseringstjänst

Generella förberedelser

Oavsett vilken anslutningsmetod ni använder behöver följande aktiviteter genomföras:

  1. Gör en anmälan till: hasanein.alyassiri@inera.se

  2. Behörig representant för kunden måste teckna Kundavtal 2 (”ramavtal med Inera”) om detta inte redan finns, se: https://www.inera.se/kundservice/bli-kund/

  3. Maila nedan uppgifter till hasanein.alyassiri@inera.se

    1. Undertecknat anslutningsavtal, (OBS! måste undertecknas av behörig representant för organisationen)

    2. Kontaktuppgifter till lokal införandeansvarig

1a. Anslut egen lokal tjänst till Ineras IdP

  1. Säkerställ att era användare har tillgång till aktuella versioner av SITHS eID Autentiseringsklient och även har hämtat Mobilt SITHS eID om detta ska ingå i era tester, se: Förberedelser för att kunna använda SITHS eID Autentiseringsklient

  2. Hämta IdP:ns konfiguration baserat på vald teknik för anslutning OIDC eller SAMLv2 (måste bytas ut vid övergång till förvaltningens IdP):

    1. Sökvägar till OIDC-konfiguration och SAMLv2 metadata återfinns här:

  3. Utfärda SITHS funktionscertifikat från er egen organisation och använd det för att signera SP:ns metadata

    1. Om ni inte kan beställa SITHS-funktionscertifikat på egen hand finns det möjlighet att beställa SITHS-funktionscertifikat från Inera:

    2. Certifikatet utfärdas via SITHS Admin Preprod eller Produktion av er egen utfärdarorganisation för SITHS

    3. Vilka certifikat som används i olika miljöer framgår av:

    4. Använd ett domännamn där som överensstämmer med tjänstens domännamn hos aktuellt organisation. Använder ni en extern leverantör använder ni deras domännamn till aktuell tjänst. I SITHS TEST-miljö finns inga krav kring bevis för ägandeskap av domännamnet innan utfärdande.

    5. Säkerställ att ni använder ett certifikat från någon annan betrodd utfärdare än SITHS för den del av tjänsten gränssnitt som användaren besöker via sin webbläsare för att hen ska slippa få certifikatsvarningar

    6. OBS! Notera giltighetstiden för certifikatet och kom ihåg att förnya det i tid och förmedla ny metadata med IdP:n innan ni byter utd et. Om certifikatet blir ogiltigt eller ny metadata för SP inte förmedlats kommer inloggning att sluta fungera för din organisation

  4. Ta reda på följande information om er lokala miljö

    1. Er tjänsts (SPs) metadata

    2. Bestäm vilka attribut er tjänst vill hämta från Ineras IdP, se Attributslista Inera IdP

      1. Utökad läsning om attributsstyrning inom Ineras IdP: Attributstyrning SAMLv2 och Attributsstyrning OIDC

      2. Utökad läsning om de profiler som används inom Ineras IdP: SAMLv2 profil och OIDC-profil

    3. Vilka autentiseringsmetoder ni vill ha:

      1. SITHS-kort med hjälp av Net iD

      2. SITHS eID på samma enhet (Både Mobilt SITHS eID och SITHS-kort)

      3. SITHS eID på annan enhet (Primärt usecase för Mobilt SITHS eID)

  5. Maila in uppgifterna under punkt 4 ovan till: hasanein.alyassiri@inera.se

  6. Samtliga SITHS-kort som har SITHS-certifikat på sig kommer gå att använda för inloggning med Inera Autentiseringstjänst och SITHS eID Autentiseringsklient på Windows 10.

    1. Beroende på vilken typ av SITHS e-legitimation som finns på SITHS-kortet kommer identitetsintyget att förses med olika tillitsnivåer enligt: Ny LoA-hantering för SITHS-kort 2020.

    2. Mobilt SITHS kommer, av Ineras IdP, inledningsvis att tolkas som tillitsnivå 2 i väntan på flytt till ny driftleverantör och godkännande från DIGG.

  7. Installera tillit till utfärdaren av det certifikat som används för signering av Identitetsintyget från Ineras IdP:

1b. Förberedelser inför tiden efter den initialperioden - Anslutning av tjänst till förvaltningens miljöer

  1. För att använda Ineras IdP behöver ni beställa IdP och fylla i en förstudie.

    1. Anmäl att ni vill denna förstudie till hasanein.alyassiri@inera.se

  2. Gå igenom följande guide: Guide till IDP

2. Anslut egen lokal IdP

  1. Säkerställ att era användare har tillgång till aktuella versioner av SITHS eID Autentiseringsklient och även har hämtat Mobilt SITHS eID om detta ska ingå i era tester, se: Förberedelser för att kunna använda SITHS eID Autentiseringsklient

  2. Ta reda på följande information om er lokala miljö

  3. Utfärda ett funktionscertifikat för TEST från er egen organisation och ta reda på dess HSA-id. (Detta används som klientcertifikat för kommunikationen med Autentiseringstjänsten)

    1. Om ni inte kan beställa SITHS-funktionscertifikat på egen hand finns det möjlighet att beställa SITHS-funktionscertifikat från Inera:

    2. Certifikatet utfärdas via SITHS Admin Preprod av er egen utfärdarorganisation för SITHS.

    3. För TEST-miljö ska utfärdaren vara antingen SITHS Type 3 CA v1 PP eller TEST SITHS e-id Function CA v1

    4. Använd ett domännamn där som överensstämmer med tjänstens domännamn hos aktuellt organisation. Använder ni en extern leverantör använder ni deras domännamn till aktuell tjänst. I SITHS TEST-miljö finns inga krav kring bevis för ägandeskap av domännamnet innan utfärdande.

    5. Säkerställ att ni använder ett certifikat från någon annan betrodd utfärdare än SITHS för den del av tjänsten gränssnitt som användaren besöker via sin webbläsare för att hen ska slippa få certifikatsvarningar

    6. OBS! Notera giltighetstiden för certifikatet och kom ihåg att förnya det i tid. Om det blir ogiltigt kommer inloggning att sluta fungera för din organisation

  4. Ta reda på den IP-adress er IdP kommer presentera mot SITHS eID Autentiseringstjänst

  5. Information om kapacitetsbehov 

  6. Maila HSA-id för funktionscertifikatet, IdP:ns IP-adress och uppskattat kapacitetsbehov till: hasanein.alyassiri@inera.se

  7. Säkerställ att er IdP har relevanta brandväggsöppningar och rätt routing för åtkomst till SITHS eID Autentiseringstjänst Relying Party API,

  8. Anpassa er lokala IdP till Autentiseringstjänstens Relying Party API:

  9. Installera tillit till följande utfärdare i er IdP då Autentiseringstjänsten använder certifikat från den vid kommunikation över Relying Party API:

  10. Avgör vilken tillitsnivå ni vill att respektive typ av SITHS-certifikat ska få i er lokala IdP’s identitetsintyg. Ineras IdP kommer göra tolkningar enligt: Ny LoA-hantering för SITHS-kort 2020.

    1. Mobilt SITHS kommer, av Ineras IdP, inledningsvis att tolkas som tillitsnivå 2 i väntan på flytt till ny driftleverantör och godkännande från DIGG.

    2. Här återfinns SITHS lista över e-legitimationer och hur de borde tolkas. Ytterst är det dock upp till respektive anslutande organisation vilken tolkning som används:

8. Frågor och svar

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

  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 ;

    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, den finns här:

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

Bilaga 1

Rollbeskrivning: Lokalt införandeansvarig för ny autentiseringsmetod

Inera levererar idag, via identifieringstjänsten SITHS, utgivning av certifikat på smarta kort samt autentiseringslösning till alla regioner, kommuner, privata utförare, tjänsteleverantörer och några myndigheter. Totalt finns det över 550 000 användare av tjänsten.

Inera arbetar för närvarande med framtagande och införande av en ny autentiseringslösning baserad på en så kallad Out of Band-teknik, vilken kommer att läggas till den befintliga SITHS-tjänsten. Denna lösning omfattar autentiseringsklienter för Windows, Android samt IOS och skapar bland annat förutsättningar för införande av mobil autentisering. Lösningen kommer under en övergångsperiod finnas parallellt med befintlig autentiseringslösning.

SITHS-tjänsten kommer att vidareutvecklas med bl.a. följande komponenter:

  • Ny mobil klient för SITHS e-id för autentisering och underskrift mha mobilklient

  • Ny desktopklient för SITHS e-id för autentisering och underskrift som eliminerar beroendet till Internet Explorer 11 vid autentisering och underskrift och på sikt ersätter Net id Enterprise

  • Nya funktioner baserat på regionernas prioriteringar

Lokalt införande av ny autentiseringsmetod

Beroende på hur den lokala IAM-infrastrukturen är utformad kan införandet av den nya autentiseringsmetoden ge mer eller mindre påverkan. Detta är något som behöver utredas och en plan anpassad till den lokala situationen behöver tas fram samt genomföras.

Inera rekommenderar att en lokalt införandeansvarig utses samt leder förstudie, planering samt genomförande av erforderliga lokala införandeaktiviteter i syfte att säkerställa att övergången till ny autentiseringsmetod sker så snart som möjligt samt med minimala störningar hos den egna organisationen.

Ett införande kan komma att påverka både användare, personal som arbetar med eID-utgivning, IT-organisationen och systemförvaltare.

Resursen ska tillsammans med ansvarig utgivare:

  • Genomföra förstudie och kartlägga och föreslå förberedelseaktiviteter som ska leda fram till lyckat införande

  • Leda övergången till ny autentiseringsmetod inom egen organisation

  • Samla in förbättringsförslag och förmedla dessa till ansvarig utgivare och till Inera enligt instruktion från Inera

  • Rollen omfattar följande Ansvarsområden:

    • Organisera och leda genomförandet av införandeaktiviteter både inom verksamheten och IT-organisationen

    • Samverka samt ge löpande stöd till ansvarig utgivare under införandet

    • Hantera kommunikation till berörda parter inom organisationen

    • Vid behov utbilda berörd personal t.ex. IT Helpdesk eller Kundtjänst

    • I samråd med ansvarig utgivare ta fram instruktioner och utbildningsmaterial

    • Följa upp införande och anslutningsgraden inom organisationen

    • Kanalisera frågeställningar och förbättringsförslag till både ansvarig utgivare och Inera

    • Agera som single point of contact för eventuella projekt i organisationen

    • Stöd i samband med att organisationen börjar använda en ny komponent