2.4 Anslutningsguide till IdP

 Visa revisionshistorik

Version

Datum

Författare

Kommentar

0.1

 

  • Kopierat från IdP 2.3
  • Lagt till information om rullande omdirigeringar när autentiseringsmetoden för mTLS används
  • Tagit bort dokumentation kring val av medarbetaruppdrag som gällde valen av HSA-ID:n utan kopplade medarbetaruppdrag
  • Ändrade namn på autentiseringsmetoder
0.2

 

Förtydliganden under avsnittet för Autentiseringsmetoder.
0.3

 

Förtydliganden under SSO-sessionens giltighetstid och vad som krävs för en fullständig utloggning
0.4

 

Lade till information om att flera subdomäner för mTLS inte kommer aktiveras förrän Q3-2023.

Rättade fel begrepp på autentiseringsmetoder under rubrik 9. Val av tjänste-id/medarbetaruppdrag

1.0

 

Godkänd av förvaltning

1.01

 

Bytt ut SITHS eID Windowsklient och Mobilklient, samt orden klient mot SITHS eID-app för Windows, SITHS eID-app för Mobilt SITHS respektive "appen".

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 /wiki/spaces/UST/pages/3475212609.

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

Exempel på e-tjänsts anslutning till Ineras IdP som Service Provider

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.

Validering av SAML metadata

För att säkerställa att metadata uppfyller kraven för att kunna läsas in i IdP:n bör ett eller flera valideringsverktyg användas. Använd gärna verktygen i listan nedan för att säkerställa att metadatat valideras korrekt innan det förmedlas till förvaltningen för inläsning till IdP:n.

I de fallen då ADFS metadata är tänkt att läsas in ska inte Sambi Metadata validatorn användas. I de fallen bör endast IdP Public tools användas.

Förmedling av SAML metadata

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

Programvara som användaren behöver

En eller flera klientapplikationer/klientprogramvaror 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


Observera att Ineras lokala IdP inte kan agera proxy IdP


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.

SAML AttributnamnOIDC Attributnamn
urn:sambi:names:attribute:authnMethod

amr

urn:sambi:names:attribute:x509IssuerName

http://www.w3.org/2000/09/xmldsig#X509IssuerName

x509IssuerName

http://www.w3.org/2000/09/xmldsig#X509SubjectName

x509SubjectName
urn:sambi:names:attribute:levelOfAssuranceacr
urn:credential:givenNamecredentialGivenName
urn:credential:surnamecredentialSurname
urn:credential:personalIdentityNumbercredentialPersonalIdentityNumber
urn:credential:displayNamecredentialDisplayName
urn:credential:organizationNamecredentialOrganizationName
urn:credential:certificatePoliciescredentialCertificatePolicies


Vill man i den anslutande lokala IdP:n även få med HSA-id för användaren går det också bra, men om det finns flera HSA-id för samma användare så leder det till ett uppdragsval eller tjänsteidval. Vill man undivika det så kan man ta med alla HSA-id för användaren .

SAML AttributnamnOIDC Attributnamn
http://sambi.se/attributes/1/employeeHsaIdemployeeHsaId
urn:allEmployeeHsaIdsallEmployeeHsaIds


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

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å annan enhet
  • SITHS eID på denna enhet
  • SITHS-kort på denna enhet


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.

Om metoden SITHS-kort på denna enhet är vald, kommer metoden att synas på mobila enheter. Autentiseringslösningen baserar sig dock på dubbelriktad TLS (mTLS), vilket inte fungerar tillsammans med SITHS. Om man vill försäkra sig om att detta inte händer bör man definiera en egen SP-ingång som uteslutande visar SITHS eID-metoderna och som man hänvisar användare av Mobila enheter till.

Aktivering av ny autentiseringsmetod som använder SITHS eID-apparna 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-appen (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 appar/mobila enheter samt
  4. distribuera appar, (inklusive att över tid säkerställa förmåga till robust testning och uppdatering)

För mer detaljerad information om autentiseringsmetoderna för "SITHS eID på denna respektive annan enhet" 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 klientprogramvara 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.

  • SITHS-kort på denna enhet kommer alltid föredra HSA-id-certifikat
  • SITHS eID på denna/annan enhet föredrar ett personnummer-certifikat om ett sådant finns. Beroende på vilka uppdrag som har kopplats i HSA för personnumret jämfört med vad som är kopplat till HSA-id:t kan SITHS eID på denna/annan enhet resultera i att användaren får fler valbara alternativ i tjänste-id- och uppdragsvalet.

SITHS-kort på denna enhet - Dubbelriktad TLS/Mutual TLS (mTLS)

Autentiseringslösningen baseras på teknik och standard för dubbelriktad TLS/Mutual TLS (mTLS). Webbläsaren utmanar användaren om att presentera ett giltigt klientcertifikat som servern litar på. Certifikaten importeras från SITHS-kortet till datorns operativsystem med hjälp av någon av klientprogramvarorna nedan. Integrationen sker alltså egentligen mot operativsystemet/webbläsaren snarare än mot klientprogramvaran.

Förutsätter att användaren har någon av klientprogramvarorna nedan och ett SITHS-kort:

  • SITHS eID-app för Windows MD (där SAC minidriver tekniskt sätt hanterar stödet för autentiseringsmetoden)
  • Net iD Enterprise

Flera subdomäner ger användaren fler försök att välja certifikat

Denna funktion aktiveras först under Q3-2023

I väntan på att den aktiveras får användaren bara ett försök att välja sitt klientcertifikat per webbläsarsession. Om SITHS-kortet inte sitter i läsaren, är för fel miljö eller om importen av certifikaten till operativsystemet inte fungerar måste användaren starta om webbläsaren för att kunna göra ett nytt försök att välja klientcertifikat. Detta beror på att det är den logiken som gäller för marknadens olika webbläsare.

 Visa information om flera subdomäner för SITHS-kort på denna enhet (mTLS)

För att säkerställa att användaren måste välja ett certifikat när SITHS-kort på denna enhet används dirigerar IdP:n användaren om till olika subdomäner vid varje inloggningsförsök i den pågående webbläsarsessionen.

OM användaren inte valde något certifikat, t ex. inte hade sitt SITHS-kort i kortläsaren, visas denna dialog och användaren får ett nytt försök genom att välja Försök igen.

image-2023-2-21_15-21-29.png

OM användaren har kommit till maxvärdet för antalet inloggningsförsök innan webbläsaren måste startas om (i skrivande stund 25 försök för IdP som driftas av Inera) visas denna dialog och användaren måste starta om webbläsaren för att starta om antalet försök.

image-2023-2-21_15-21-11.png

OBS!

Logiken med att användaren alltid får 25 inloggningsförsök är beroende av att användarens webbläsare INTE har inställningen för att öppna flikar från föregående session aktiverad (se exempel nedan). Inställningen gör att räknaren i cookien för vilken endpoint/domännamn användaren ska hamna på inte nollställs korrekt. Användaren kommer såldes att fortsätta på det värde som webbläsaren senast hade och nollställas först när den når maxvärdet (25) och användaren då startar om webbläsaren. Rent praktiskt innebär det att användaren istället för 25st nya försök kommer ha färre försök på sig innan meddelandet ovan  om För många inloggningsförsök via dubbelriktad TLS presenteras.

SITHS eID på denna/annan enhet - Out-of-band authentication (OOB)

Förutsätter att användaren har någon eller båda av:

  • SITHS eID-app för Mobil och ett nedladdat Mobilt SITHS eller
  • SITHS eID-app för Windows och ett SITHS-kort.

För detaljerad information kring de nya autentiseringsmetoderna och dess klientprogramvaror, dvs. apparna, fungerar se respektive Användarhandbok

Test av autentiseringsmetoder

På följande länkar kan samtliga autentiseringsmetoder testas för att försäkra sig om att autentisering mot IDP är möjlig

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 på denna/annan enhet föredrar personnummer-certifikat om ett sådant finns
    • 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 på för denna autentiseringsmetod.
  • Inloggning med SITHS-kort på denna enhet alltid föredrar HSA-id-certifikat

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

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 medarbetaruppdrag

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 medarbetaruppdrag

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.

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.

Visningsnamn under legitimerings- och signeringsflödet

Under legitimerings- och signeringsflödet visar IdP:n ett namn på organisationen som användaren är på väg att logga in i eller utföra en signatur för. Samma namn visas också i SITHS eID-appen om en av SITHS eID autentiseringsmetoderna har valts.

Namnet som visas kan väljas själv av den anslutande organisationen och anges i förstudien. Gäller det en anslutning med SAML som protokoll ska namnet även finnas i SAML metadatat. Som del av förstudien ska både ett namn på systemet och ett namn på organisationen anges. I praktiken kommer dock endast namnet på organisationen visas för slutanvändaren.

SAML

Vid anslutningsförfarandet hämtas organisationsnamnet som visas under legitimerings- och signeringsflödet från SAML metadatat. IdP:n letar efter ett OrganizationDisplayName under Organization-taggen (se SAML-Profil för konkreta exempel). Namnet som finns angetts under OrganizationDisplayName ska matcha med det som angetts i förstudien under Organisationens visningsnamn. Systemets visningsnamn ska inte vara definierat i SAML metadatat utom ska endast återfinnas i förstudien.

OIDC

Vid anslutningsförfarandet anges organisationens och systemets visningsnamn endast i förstudien. Dessa värden läses sedan in manuellt till IdP:n.

OBS! Vid uppgraderingen till IdP 2.3 är visningsnamnet för OIDC-anslutningarna initialt systemets visningsnamn. IdP saknar information kring vilken den anslutande organisationen är i tidigare versioner av IdP:n och kommer behöva kompletteras allt eftersom.

IdP SSO-sessionens giltighetstid

Efter slutanvändarna har lyckats med sin inloggning tilldelar IdP:n deras SSO-session en fast giltighetstid på 60 minuter oavsett om användaren under giltighetstiden har gjort en HTTP-slagning där giltighetstiden kontrolleras eller inte. Det exakta värdet för giltighetstiden kan komma att ändras i framtiden då detta konfigureras på IdP:ns sida.

Exempel: Användaren är inloggad i System A sen 59 minuter tillbaka och väljer att öppna System B i webbläsaren. Användaren blir inloggad i System B men SSO-sessionens giltighetstid utökas inte. När användaren öppnar System C i webbläsaren efter 61 minuter kommer användaren behöva logga in igen. När användaren väljer att logga ut eller stänger ner webbläsaren försvinner SSO-sessionen.

Cachning av PIN-kod (PIN-cache, PIN-SSO)

Cachning av pin-koden har historiskt också kallats för/använts som SSO. Detta är dock en form av SSO som hanteras nere på operativsystemet tillsammans med den mjukvara som används dom drivrutin för att läsa SITHS-kortet. Dvs Net iD Enterprise eller SITHS eID-appen för Windows MD (med SAC minidriver).

Därav kan användarupplevelsen variera beroende på hur appen är konfigurerad lokalt. Som standard är PIN-SSO aktiverad, vilket medför att användare vid en ny inloggning inte alltid behöver slå in PIN-koden efter att de valt sitt certifikat. Även om IdP:ns SSO-session har avslutats.

OM organisationen valt att inaktivera eller ställa in en kort tid för PIN-SSO kan användaren behöva uppge sin pin-kod vid varje inloggning.

PIN-SSO avslutas annars som regel när:

  • Användaren avlägsnar sitt kort från kortläsaren eller
  • Datorn startas om
  • Timeout för PIN-SSO inträffar

Utloggning

För att fullständigt logga ut från en e-tjänst behöver följande ske

  1. Användaren använder tjänstens egen funktion för utloggning

  2. Att tjänsten vidareförmedlar utloggningsbegäran till IdP för att avsluta IdP-SSO

  3. Användaren avlägsnar SITHS-kortet från kortläsaren för att avsluta PIN-SSO

  4. Tjänsten bör komplettera med en egen inaktivitetstimeout för att avsluta applikations-sessioner från inaktiva användare

    1. Denna hjälper dock inte om användare glömmer att avlägsna sitt SITHS-kort.

Kompatibilitetsinformation

För att få tillgång till rättningar krävs att supporterad hårdvara och mjukvara enligt listorna nedan används.

IdP

Ineras IdP följer vedertagna standards för utfärdande av identitetsintyg (SAMLv2/OIDC). Användning av dessa standards medför att IdP fungerar på merparten av alla operativsystem och webbläsare. De e-legitimationer som stöds av Ineras IdP (SITHS) är dock beroende av Klientprogramvaror som har kompatibilitetskrav för den plattform och hårdvara de installeras och används på.

Windows - Operativsystemsversioner

Tester sker primärt utifrån kraven i eKlients kravbibliotek gällande vilka versioner av Windows som ska stödjas. När Microsoft släpper en ny release är målet att ha testat stödet för denna inom 6 månader.

OBS! Vi supporterar endast de versioner av Windows som Microsoft själva supporterar. Nedan följer länkar till Microsofts livscykelplaner för Windows:

Operativsystem (endast 64-bitar)

Autentiseringsmetod
SITHS eID på denna/annan enhet (out-of-band)SITHS-kort på denna enhet (mTLS)

Windows 11 upp till 22H2

XX

Windows 10 upp till 22H2

XX

Windows - Webbläsare

Följande webbläsare supporteras så länge den version som används också supporteras av tillverkaren av respektive webbläsare:

  • Chrome
  • Edge
  • Inbäddad Internet Explorer 11 och Internet Explorer 11-läge i Microsoft Edge (EOL)
  • Firefox

Stödet för Internet Explorer 11 är under avveckling.

Stödet blir allt svårare att vidmakthålla och risken för upptäckt av allvarliga säkerhetsbrister gör att vi kan behöva avveckla stödet med kort varsel.

Microsoft slutade supportera fristående Internet Explorer 11 i maj 2022.

Uthoppslösningar

Kompatibilitet för e-tjänster med s k uthoppslösningar kan behöva verifiera att inställningar för "Trusted Zones" på den tekniska stödsidan IdP med Edge och IE 11 och Trusted sites.

Inbäddade webbläsare

Inbäddade webbläsare samt ev. andra webbläsare kan behöva anpassningar för att stödja anpassade browser-scheman som används för att autostarta appen. För SITHS eID-appen används siths://.

Se mer information här: SITHS eID Appväxling - Exempel för inbäddade webbläsare

Klientprogramvaror

SITHS eID-app för Windows

Laddas ner via Ladda ner SITHS eID-app för Windows


 SITHS eID-app för Windows - Visa kompatiblitetsinformation

Fel vid återgivning av makro 'excerpt-include' : User 'null' does not have permission to view the page '2.0.8481 Användarhandbok - SITHS eID-app för Windows'.

SITHS eID-app för Mobila enheter

Laddas ner via App Store eller Google Play.

För att hämta Mobilt SITHS kan du antingen använda ett befintligt Mobilt SITHS eller så måste du använda SITHS eID-app för Windows, läs mer på SITHS eID-app för Windows.

 SITHS eID-app för mobila enheter - Visa kompatibilitetsinformation

2.2.5 Användarhandbok - SITHS eID-app för Mobilt SITHS

Under detta avsnitt listas:

  • supporterade versioner SITHS eID-appen för mobila enheter
  • samt versioner för den plattform och hårdvara på vilken appen ska fungera.

För att få tillgång till rättningar krävs att supporterad hårdvara och mjukvara enligt listorna nedan används. Om det hittas enheter som ej fungerar trots att de täcks av rubriken Hårdvara och operativsystem för mobila enheter förbehåller sig Inera komplettera listan med Ej kompatibla enheter.

Versioner av SITHS eID-appen för mobila enheter

Inera supporterar den senaste versionen av SITHS eID-appen för mobila enheter

Vid felanmälan kan Inera komma att kräva att felet återskapas i någon av följande versioner:

AppversionOperativsystemUtgivningsdatumSista datum för support
2.2.5Android

2022-08-31


Ej planerat
2.2.5iOS2022-08-31Ej planerat

Hårdvara och operativsystem för mobila enheter

Appen fungerar endast på vissa kombinationer av hårdvara och mobila operativsystem.

 Visa avsnittet hårdvara och operativsystem för mobila enheter

Apple

Lägsta hårdvarukravLägsta supporterade hårdvaraLägsta OS-versionLägsta supporterade OS-versionWebbläsare

Enheten behöver ha Secure Enclave hårdvarukryptering

Modeller:

  • iPhone 6s eller senare
  • iPad mini gen5 (A2133)
  • iPad gen5 (A1823)

Samma som lägsta hårdvarukrav

iOS 12

iOS 12Safari rekommenderas för bästa användarupplevelse, men även andra webbläsare ska fungera

Apple - Biometri

Lägsta hårdvarukravLägsta supporterade hårdvaraLägsta supporterade OS-versionHögsta supporterade OS-versionBiometri som stöds

Enheten ska stödja skapande av en asymmetrisk kryptonyckel i enhetens säkra hårdvaruutrymme (Secure Enclave) med krav på biometrisk autentisering för dess användande.

Modeller:

  • iPhone 6s eller senare
  • iPad mini gen5 (A2133)
  • iPad gen5 (A1823)
Samma som lägsta hårdvarukraviOS 12Ingen högsta version definieradFace ID eller Touch ID beroende på vad som finns tillgängligt på enheten.

Android

Lägsta hårdvarukravLägsta supporterade hårdvaraLägsta OS-versionLägsta supporterade OS-versionHögsta supporterade OS-versionWebbläsare

Enheten behöver ha CPU (Qualcomm) med Trust Zone (motsvarar TPM) Keystore Trusted Execution Environment (TEE)

Enheten behöver finnas med på någon av följande listor

Android 7.1.1

Android 9

Android 11

From. 1 november 2023 går denna version av appen inte längre gå att installera på nyare versioner än Android 11.

OBS! Redan existerande installationer av appen påverkas inte.

Vi rekommenderar användning av enhetens standardwebbläsare för bäst användarupplevelse, men även andra webbläsare ska fungera.

Android - Biometri

Lägsta hårdvarukravLägsta supporterade hårdvaraLägsta supporterade OS-versionHögsta supporterade OS-versionBiometri som stöds
Vid aktivering av biometri skapas en asymmetrisk kryptonyckel i enhetens säkra hårdvaruutrymme (TEE) med krav på biometrisk autentisering uppfyllande “Class 3” (tidigare benämnd “Strong”)Samma som lägsta hårdvarukravAndroid 9 (API-nivå 28)Android 10 (API-nivå 29)Endast fingeravtrycksläsare
Android 11 (API-nivå 30)Ingen högsta version definieradAlla biometriska läsare som uppfyller "Class 3" enligt Androids API för kontroll av biometrisk hårdvara.

Ej kompatibla enheter

Lista över enheter som inte fungerar trots att de matchar ovan plattformskrav

OperativsystemEnhetsmodell (Tillverkare - modellnamn)OS-version
Inga kända för närvarande

Ej kompatibla enheter - Biometri

OperativsystemEnhetsmodell (Tillverkare - modellnamn)OS-version
Inga kända för närvarande

Webbläsare

Beroende på om inloggningen sker på den mobila enheten eller om Mobilt SITHS används för att logga in i en applikation på en dator finns olika förutsättningar.

För inloggning med Mobilt SITHS på en dator fungerar de flesta förekommande webbläsare som också supporteras av respektive operativsystem

För inloggning med Mobilt SITHS på den mobila enheten gäller att webbläsaren som används ska vara markerad som standardwebbläsare OCH att webbläsaren också supporteras av tillverkaren av respektive webbläsare.

Följande webbläsare supporteras på Android

  • Chrome
  • Edge
  • Samsung Internet

Följande webbläsare supporteras på iOS

  • Chrome
  • Safari

Inbäddade webbläsare samt ev. andra webbläsare kan behöva anpassningar för att stödja anpassade browser-scheman som används för att autostarta appen. För SITHS eID-appen används siths://.

Se mer information här: SITHS eID Appväxling - Exempel för inbäddade webbläsare

Net iD Enterprise

Information om kompatibilitet och support för Net iD Enterprise finns på sidan Programvaror och tillbehör för SITHS.


Publik Information