Sammanfattning

Ineras IdP syftar till att erbjuda vårdgivare och dess vårdsystem en säker autentisering av aktörer/vårdpersonal för olika behov. Ineras IdP tillhandahåller s.k. single sign on (SSO) inom webbapplikationer enligt väl definierade standarder, så som SAML Web SSO Profile samt OpenID Connect. E-tjänst och system används synonymt i följande dokument.

Tjänsten tillhandahåller också funktion för att logga ut aktören och avsluta SSO-sessionen hos IdP.

Vid en lyckad autentisering utfärdas ett identitetsintyg, (SAML-biljett, eller Id-token för OIDC) som innehåller information om autentiseringen samt eventuellt ytterligare användarattribut, som kan användas av ett ABAC (Attribute Based Access Control) behörighetssystem, d.v.s. behörighet på egenskapsnivå.

Anslutning till IdP kan ske direkt för en e-tjänst, men det går också att ansluta en lokal IdP som en proxy till Ineras IdP. För jämförelse mellan olika anslutningsmönster, se Att ansluta e-tjänster.

För att anslutande e-tjänst skall få ut ytterligare användarattribut måste slutanvändare som skall autentiseras existera i den nationella HSA-katalogen. Beroende på vilka attribut som efterfrågas för en aktör kan eventuella val behöva göras i inloggningsflödet. Exempel på detta är medarbetaruppdrag och/eller autentiseringsmetod.

De e-tjänster som vill nyttja elektronisk underskrift kan ansluta till Underskriftstjänsten. I och med denna anslutning möjliggörs autentisering för underskrift via Ineras IdP, se Underskriftstjänsten.

Exempel på e-tjänsts anslutning till Ineras IdP som Service Provider och med ny auteniseringsmetod och klient:

Tekniska förutsättningar för användning Inera IdP

Nedan följer information om de övergripande tekniska kraven och komponenterna för anslutning och användning

I dagsläget utfärdas identitetsintyget enligt två protokoll, SAML (Security Assertion Markup Language) och OIDC (OpenID Connect).

Anslutande e-tjänster väljer vilket av dessa båda protokoll som de vill nytta.

SAML

Ansluten e-tjänst registreras manuellt i Ineras IdP genom förmedling av metadata. Genom metadata kan man ex. specificera vilka attribut man önskar få från IdP:n och utbyta vilka nycklar som ska användas, adresser vid utloggning, o.s.v.
Se SAML-Profilen och Attributstyrning SAML för detaljer kring hur Inera IdP implementerar SAML-protokollet.

För åtkomst till IdP:s SAML-metadata, se Adresser och portar nedan.

Förmedlingen av metadata kan ske på flera olika sätt. Som del av den förstudie som skickas in när e-tjänsten ska registreras väljs vilket sätt som ska användas. De tre möjligheterna som erbjuds idag är som följer:

Skicka in metadata på fil för engångs-inläsning

Väljs detta alternativ skickas en .xml-fil innehållandes metadatat in som senare också ska bli inläst i IdP:n. Detta görs enklast genom att skicka in filen i samband med att förstudien skickas in för granskning. Metadatat kommer då att granskas i samma veva som förstudien granskas.

Skicka in metadata via en URL för engångs-inläsning

Vid detta alternativ anges en URL varifrån metadatat kan hämtas som ska bli inläst till IdP:n. Säkerställ gärna en extra gång att URL:en funkar och att metadatat som fås via URL:en är rätt metadata för anslutningen. Under förstudiegranskningen kommer samma metadata som hämtas från URL:en användas för granskning.

OIDC

Registrering av OIDC-klienter i Inera IdP sköts manuellt. Se OIDC-Profil och Attributstyrning OIDC för detaljer kring hur Inera IdP implementerar OIDC-protokollet.

För åtkomst till IdP:s OIDC-metadata, se Adresser och portar nedan.

Sjunet

Ineras IdP är tillgänglig från både internet och Sjunet med samma instans och domän (se Adresser och portar nedan).

Se Nätverksinställningar för IAM-tjänster för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.), inklusive information om Sjunet-routing.

Funktionscertifikat 

Produktion

Anslutande systems signeringscertifikat (det certifikat som bifogas i t.ex. SAML metadata och som meddelanden signeras med) för produktionsmiljö kan ställas ut av valfri utfärdare men nyckelhanteringen förutsätts följa de instruktioner och rekommendationer som anges i "Instruktion, nyckelhantering för lagrade krypterade data".

Inera rekommenderar välrenommerade och robusta utfärdare med följsamhet mot principerna i ISO-27002 (wikipedia, riktlinjer till ISO-27001). Väljs "SITHS e-id Function CA v1" (utfärdare, SITHS e-id Root CA v2) kan mer information ges på SITHS på inera.se. Se SITHS CA repository för de utfärdande certifikaten.

Testmiljöer

Vilken utgivare som helst är godkänd för funktionscertifikaten som används i anslutningar till testmiljöerna.

Slutanvändarklienter

En eller flera klientapplikationer behöver vara tillgängliga för e-tjänstens slutanvändare, se avsnitt längre ner för testade versioner och länkar till klienter.

Livscykelhantering - förändring av existerande anslutningar

Anslutningen till IdP kan förändras t.ex. om e-tjänsten har nya kontaktuppgifter, har förnyat sitt funktionscertifikat, vill få tillgång till ytterligare användarattribut eller tillgängliggöra flera (eller andra) autentiseringsmetoder för sina slutanvändare.

Vid önskade förändringar i anslutningen följs följande principiella mönster:

1. Inkom med en uppdaterad förstudie för testmiljö(er) där ni fyller i relevanta ändringar och noterar i revisionstabellen vad som ändrats. Bifoga även eventuellt metadata
   
   1. Efter godkänd förstudie justeras anslutningen hos den aktuella test-IdP:n. Vid nekad förstudie kontaktas e-tjänstens förvaltning
2. Verifiera funktionen i testmiljö(erna) genom att
   
   1. Inkom med en motsvarande uppdaterad förstudie för produktionsmiljön.
   2. Bifoga testrapport från testmiljö.
   3. Ange eventuellt önskat datum och tidpunkt för aktivering av ny funktionalitet.
3. Vid godkänd förstudie justeras anslutningen i prod-IdP:n, direkt eller vid vald tidpunkt. Vid nekad förstudie kontaktas e-tjänstens förvaltning

Anslutningsmönster

Anslutning av e-tjänst till Ineras IdP

En e-tjänst kan ansluta till Ineras IdP som en SAML SP (Service Provider) eller OIDC RP (Relying Party).

• Vilka metoder som är tillgängliga för slutanvändarna konfigureras i IdP per e-tjänst, det går således att i förstudien att endast använda ett urval av de autentiseringsmetoder som Ineras IdP tillhandahåller.
• e-tjänsten anger i sitt metadata (om SAML) eller i autentiseringsanropet (om OIDC) vilka användarattribut som önskas. Se Attributstyrning SAML alternativt Attributstyrning OIDC.
• Inera IdP tillhandahåller begärda användarattribut som finns på certifikatet och eventuella attribut på personposten i den nationella HSA-katalogen samt presenterar uppdragsval för användaren.
• Inera IdP tolkar och förmedlar tillitsnivå (LoA) utifrån användarens certifikat.

Anslutning av lokal IdP till Ineras IdP (proxy-anslutning)

Lokala e-tjänster kan erhålla identitetsintyg från Ineras IdP via en lokal IdP genom anslutning som en OIDC RP eller SAML SP och agera som en "proxy-IdP". Anslutningen sker som en vanlig anslutning (som ovan) av en e-tjänst till Ineras IdP men skillnaderna består i stor sett av en förskjuten ansvarsfördelning från Ineras till den lokala IdPn.

Inera IdP:

• tillhandahåller eventuellt autentiseringsmetod samt de attribut som rör autentisering av användaren, se nästa avsnitt för de idag rekommenderade
• revokeringskontroll

Lokal IdP:

• implementerar en SAML-SP eller en OIDC-RP som ansluts till Ineras IdP,
• väljer vilken eller vilka autentiseringsmetoder som Inera IdP skall exponera för slutanvändare,
• ansvarar för eventuellt uppdragsval,
• (valbart men starkt rekommenderat, revokeringskontroll)
• beräknar tillitsnivå (LoA) utifrån certifikatsattribut som Ineras IdP tillhandahåller
  • Se Tillitsnivå (LoA) för information om hur Ineras IdP tolkar tillitsnivåer för en rekommendation.
• hämtar eventuella övriga användarattribut från en lokal katalogtjänst

Användning av iframes

System som har för avsikt att använda sig av iframes för att visa IdP:ns användargränssnitt för slutanvändaren blir inte godkända för att ansluta sig mot IdP:n. Detta med anledning av att vi inte kan lämna några garantier för att IdPn:s funktionalitet bibehålls när iframes används. Detta är ett hårt krav där inga undantag kommer göras. Vidare så avrekommenderar även DIGG emot användningen av iframes, se DIGGs artikel för mer information.

Rekommenderade attribut för en lokal IdP

Förutom attribut som alltid anges i SAML-biljetten eller OIDC-tokens per default (se Attributlista), så är följande attributlista för en rekommendation på en "maximal" lista för lokal IdP att begära från Inera IdP. Detta för att undvika att slutanvändare presenteras uppdragsvalsdialogen i Ineras IdP och förbättra mönstrets effektivitet.

Dokumentation

Utöver denna guide finns följande dokumentation framtagen för tjänsten.

Adresser och portar

Se Nätverksinställningar för IAM-tjänster för gemensam nätverksteknisk information för alla IAM-tjänsterna (IdP, Autentiseringstjänsten, Utfärdandeportalen, etc.) och övriga tjänster.

Följande adressmatris används för anslutning till Inera IdP och tydliggör i vilken HSA miljö som slutanvändare förväntas finnas. Dessa adresser och IP-adresser är samma för både Internet och Sjunet.
HSA adresserna anger både Sjunet respektive internetgränssnitten för administration.

Tillitsnivå (LoA)

För hantering av tillitsnivå för olika typer av certifikat, se Tillitsnivå (LoA).

Autentiseringsmetoder

Aktivering av autentiseringsmetoder

I dagsläget har alla anslutna tjänster endast en autentiseringsmetod tillgänglig, mTLS med Net iD Enterprise.

Anslutna tjänster kan välja vilka inloggningsmetoder som skall vara aktiva och därmed valbara för användarna vid autentisering.

Tillgängliga metoder:

• SITHS eID på samma enhet
• SITHS eID på annan enhet
• mTLS med Net iD Enterprise

Observera: om endast en metod är aktiv för given e-tjänst så ställs användaren inte inför något val av autentiseringsmetod.

Aktivering av ny autentiseringsmetod som använder SITHS eID-klienterna görs vid ifyllande av förstudiemall version 3.x, både för nya anslutningar samt befintliga. Se den generella rutinen för livscykelhanteringen ovan

Förutom det formella anslutningsförfarandet tillkommer arbete kring att

1. ordna med brandväggsöppningar mot Autentiseringstjänsten (Nätverksinställningar för IAM-tjänster),
2. säkerställa att slutanvändarna använder en webbläsare (för att anropa IdP) på ett sätt som möjliggör för autostart av SITHS eID-klienten (se även nedan samt SITHS eID Appväxling - Exempel för inbäddade webbläsare),
3. informera och eventuellt utbilda slutanvändarna i användningen av klienter/mobila enheter samt
4. distribuera klienter, (inklusive att över tid säkerställa förmåga till robust testning och uppdatering)

För mer detaljerad information om de nya autentiseringsmetoderna och vilka krav som ställs på anslutande organisationer, se Anslutningsguide till Autentiseringstjänsten.

Användarval av autentiseringsmetod

För de tjänster som aktiverar fler än en autentiseringsmetod så kommer användarna vid autentisering att mötas av en dialog där de får välja vilken metod de vill använda. Säkerställ att e-tjänstens slutanvändare har erforderlig klient installerad, har fått lämpliga instruktioner i god tid före produktionsutrullning och  inte överraskas över denna dialog (samt eventuellt, lämplig mobil enhet, tillgänglig).

För slutanvändaren kan valet av autentiseringsmetod påverka det senare uppdragsvalet om ett sådant krävs. mTLS med Net iD kommer alltid föredra HSA-id-certifikat medans SITHS eID-autentiseringsmetoderna föredrar ett personnummer-certifikat om ett sådant finns. Beroende på vilka uppdrag som har kopplats i HSA för personnumret och HSA-id:t respektive kan SITHS eID-autentiseringsmetoderna resultera i att användaren får fler valbara alternativ i tjänste-id- och uppdragsvalet.

Nya autentiseringsmetoder

För detaljerad information kring de nya autentiseringsmetoderna och hur de fungerar i klienterna, se respektive användarhandbok

• Användarhandbok - SITHS eID Mobilklient
• Användarhandbok - SITHS eID Windowsklient

Val av tjänste-id/medarbetaruppdrag

Under inloggningsflödet kan användaren bli presenterad med en vy där användaren behöver göra ett uppdragsval. Uppdragsvalet innebär att användaren specifikt måste välja med vilket tjänste-id och hos vilken vårdgivare/vårdenhet användaren avser att logga in hos. För att slutföra inloggningen måste ett val göras, annars misslyckas inloggningen.

Uppdragsvalet visas när den anslutande tjänsten (SP:n) begär attribut som endast kan uppfyllas av att ett tjänste-id och/eller uppdrag väljs, annars skippas det här steget helt. Se Attributlistan över vilka attribut som kan trigga uppdragsval.

Om uppdragsvalet presenteras för användaren så varierar de listade alternativen beroende på hur de enskilda användarna är konfigurerade i HSA samt vilken autentiseringsmetod som valts. Autentiseringsmetodsvalet påverkar uppdragsvalet genom att inloggning med SITHS eID föredrar personnummer-certifikat om ett sådant finns medans inloggning med Net iD Enterprise alltid föredrar HSA-id-certifkat. En användares personnummer kan ha uppdrag kopplade till sig i HSA som inte också är kopplade på användarens HSA-id. Detta kan i sin tur resultera i att användaren får fler uppdragsval att välja mellan när SITHS eID används istället för Net iD.

När ett val behöver göras finns det ett flertal scenarion att förhålla sig till. Dessa finns specifierade här nedan.

Användaren har ett tjänste-id utan uppdrag

I detta fall kommer IdP:n automatiskt välja tjänste-id:t. I praktiken innebär det att användaren inte kommer bli presenterad med något val i webbläsaren.

Användaren har flera tjänste-id:n där inget tjänste-id har uppdrag

I det här fallet har inget av användarens tjänste-id:n några uppdrag kopplade till sig. När detta inträffar får användaren en vy presenterad för sig där endast ett tjänste-id kan väljas.

Användaren har ett tjänste-id med ett uppdrag

När detta fall inträffar väljer IdP:n automatiskt tjänste-id:t och det tillhörande uppdraget. I praktiken innebär det att användaren inte kommer bli presenterad med något val i webbläsaren.

Användaren har ett tjänste-id med flera uppdrag

I det här fallet kommer användaren få välja bland alla uppdrag som finns kopplade till användarens tjänste-id. Notera i bilden nedan hur HSA-id:t i kolumnen längst ut till höger är detsamma för alla uppdrag.

Användaren har flera tjänste-id:n med flera uppdrag

I detta fall kan användaren välja både mellan uppdrag och enskilda tjänsteid:n. Notera i bilden nedan hur det finns fyra olika tjänste-id:n att välja mellan där tjänste-id:n ...-10NG och ...-10NX har uppdrag medans ...-10NY och ...-10NZ saknar uppdrag. 

Filtrering av personnummer, HSA-id och organisationsnummer

IdP:n stödjer filtrering av attributen personalIdentityNumber, employeeHsaId samt organisationIdentifier. Denna funktionalitet är baseras på PrincipalSelection som främst nyttjas för signerings-syften för SAML. För IdP:n har funktionaliteten utökats att även stödja filtrering av dessa attribut för autentisering både för SAML och OIDC.

Med denna filtrering har anslutande system möjlighet att förhandsvälja exempelvis en användares HSA-id om denne har flera HSA-id:n att välja mellan så att valet av tjänste-id hoppas över. Liknande filtrering kan göras genom att ange filtrera ut ett specifikt organisationsnummer om en användare arbetar mot flera olika organisationer. Filtrering av personnummer är endast användbart för signering. Observera att idag stödjs endast dessa tre attribut för att göra filtreringar. 

SAML

För att kunna tillämpa denna filtrering med SAML används PrincipalSelection. Se dokumentationen hos DIGG över hur PrincipalSelection fungerar och hur det används. Mer läsvärd information hittas under artikeln för Attributstyrning SAML.

OIDC

När denna filtrering ska användas för OIDC görs det genom att ange de önskade värden i de claims som den anslutande tjänsten begär från IdP:n. Hur detta funkar i praktiken går att se under artikeln för Attributstyrning OIDC.

SSO-sessionens giltighetstid

Efter slutanvändarna har lyckats med sin inloggning tilldelas deras SSO-session en giltighetstid på 60 minuter. Det exakta värdet för giltighetstiden kan komma att ändras då detta konfigureras på IdP:ns sida.

I dagsläget kan SSO-sessionens giltighetstid utökas genom att göra HTTP-slagningar som kontrollerar ifall sessionen fortfarande är giltig. Ett sådant exempel är ifall användaren är inloggad i System A sen 59 minuter tillbaka och sedan väljer att öppna System B i samma webbläsare. IdP:n kommer att hitta den pågående sessionen och utöka den sessionens giltighetstid med 60 minuter så att användaren förblir inloggad i 60 minuter till. Detta kan upprepas oändligt många gånger i dagsläget men senast när användaren väljer att logga ut eller stänger ner webbläsaren försvinner sessionen.

OBS!: I en senare version av IdP:n kommer detta beteende försvinna. I och med denna ändring kommer IdP:n endast att erbjuda en fast satt giltighetstid på sessionen oavsett om användaren under giltighetstiden har gjort en HTTP-slagning där giltighetstiden kontrolleras eller inte. Ett liknande exempel som ovan är då ifall användaren är inloggad i System A sen 59 minuter tillbaka och sedan väljer att öppna System B i webbläsaren. Användaren blir inloggad i System B men sessionens giltighetstid har inte utökats. När användaren öppnar System C i webbläsaren efter 61 minuter kommer sanvändaren att behöva logga in igen. Precis som med dagens beteende så försvinner sessionen när användaren väljer att logga ut eller stänger ner webbläsaren.

Användarklienter

SITHS eID-klienter

Mobilklienterna laddas ner via App Store eller Google Play. Windowsklienten tillgängliggörs under SITHS eID-app för Windows och organisationer kan välja att distribuera den själva eller att dela länken med sina användare.

Se nedan för länkar till specifik information kring respektive applikation.

Windowsklienten

Mobilklienterna

Net iD Enterprise (mTLS-inloggning)

Övergripande information kring Net iD-klienten finns också på Ineras SITHS confluence space.

Tabellen nedan visar på verifierade kombinationer av komponenter.

Alla Net iD-versioner tidigare än 6.7 anses vara icke fungerande då en allvarlig sårbarhet upptäcktes relaterad till cache-tiden för PIN-koden. 

Version 6.7 av Net iD Enterprise finns inte i Ineras paketering eller tillgänglig att ladda ner på Secmakers hemsida.

Vid problem med Net iD Enterprise kan SecMakers supportsida konsulteras för att se vilka versioner som det har rapporterats problem. Idp förvaltningen har inte alltid senaste information kring vilka versioner av Net iD som slutat stödjas även om vi uppdaterar detta dokument i samband med nya Idp releaser.

Från SecMakers Windows 10 sida: https://service.secmaker.com/w10.aspx Uppdaterad senast 2020-09-23.

Cachning av PIN-kod

Användarupplevelsen med Net iD Enterprise kan variera beroende på hur klienten är konfigurerad lokalt. Det är bra att känna till att beteendet för cachning av PIN-koden påverkas av detta. Vid en ny inloggning kan vissa användare inte behöva slå in PIN-koden efter att de valt sitt certifikat även om det har gått lång tid sedan en tidigare inloggning. I andra fall kan PIN-koden dock krävas vid varje inloggning i de fallen där konfigurationen resulterar i en kort cachningstid.

Systemkrav

= Säkerställt

= Fungerar delvis

= Stöds ej

IdP kompatibilitet

Operativsystem	IE11	Chrome	Edge	Edge Chromium	Firefox
Windows 7 + 8	*, **, ***, **** Slutar supportas Juni 2022	***, ****	**, ***, ****	***	(ej mTLS)
Windows 10	*, ** Slutar supportas Juni 2022		**		(ej mTLS)
Android	Se Användarhandbok - SITHS eID Mobilklient#Plattformskrav för kompabilitet och kända begränsningar
iOS

Tabell över olika webbläsares kompatibilitet med IdP 2.0 (januari 2021)

*) Kompatibilitet för e-tjänster med s k uthoppslösningar kan behöva verifiera att inställningar för IE "Trusted Zones" på den tekniska stödsidan IdP med Edge och IE 11 och Trusted sites.
**) I och med att Microsoft har avslutat sitt stöd för och uppdateringar av IE11 samt legacy Edge är det svårare att få dessa webbläsare att fungera att fungera fullt ut, i alla tjänster, i alla användningsfall och konfigurationer på ett robust sätt. Uppdateras Microsoft OS och IE11/Edge med en ny och oprövad systemuppdatering garanteras det inte att det kommer att fungera initialt med alla kombinationer. 
***) I och med att Microsoft har avslutat sitt stöd för och uppdateringar av äldre Windowsversioner ges begränsad support för dessa.

****) Full funktionalitet kan ej garanteras med SITHS eID (OOB) klienter, se Användarhandbok - SITHS eID Windowsklient#Plattformskrav.