Sidjämförelse

...

Innehållsförteckning

exclude	" "

Inledning

En viktig funktion som man vill uppnå i en säkerhetslösning är Single-Sign-On (SSO). I kort innebär denna funktion att det är möjligt återanvända en autentisering. Dvs för användaren räcker det med en autentisering för att komma åt flera e-tjänster.

Beroende på hur e-tjänsten är ansluten, varierar möjligheten till SSO. Denna sida beskriver dessa möjligheter. Observera att beskrivningarna bygger på att e-tjänsterna har samma krav på identitetsintyget. Om efterföljande e-tjänster har andra krav på attribut än den första, kan det behövas ytterligare autentiseringar.

IdP-tjänsten kan vara Ineras IdP men scenariorna är i många fall allmänt tillämpliga.

I kapitlet Referenser längst ner på denna sida finns mer information om hur man kan nyttja SITHS eID i sina e-tjänster.

SSO via

...

IdP

Inera Säkerhetstjänsters lösningar för e-legitimering bygger på Referensarkitektur för Identitet och åtkomst, http://rivta.se/documents/ARK_0046/se referenser längre ner på denna sida.
Enligt denna referensarkitektur möjliggörs Single-Sign-On (SSO) via funktionalitet hos den legitimeringstjänst (IdP) som användaren loggar in via. IdP-tjänsten etablerar en särskild SSO-session med användarens klient (user agent) i samband med första autentiseringsförsöket, och så länge denna är giltig (styrs via policy) kan IdP-tjänsten acceptera nya begäran om identitetsintyg från andra e-tjänster utan att avkräva att användaren autentiserar sig igen.

Image Added

Principiellt flöde vid Single-Sign-On (SSO) via IdP. IdP ansvarar för att användarautentisering utförs; i detta fall nyttjas en separat autentiseringstjänst, men principen gäller oavsett autentiseringsteknik.

...

SSO möjliggörs via en IdP med stöd av standardprotokoll enligt referensarkitekturen: OpenID Connect alternativt SAML2, i kombination med standardwebbteknik.
SSO fungerar oberoende av använd autentiseringsteknik och tillsammans med moderna webbläsare. Såväl out-of-band (OOB) och in-band-teknik1 kan stödjas.
SSO-sessionen avslutas genom att e-tjänsten anropar IdP-tjänsten när användaren loggar ut, och automatiskt efter en konfigurerad tid. Maximal sessionstid för SSO-funktionen konfigureras i IdP-tjänsten utifrån aktuella verksamhetskrav och säkerhetspolicys.
En e-tjänst kan välja att inte nyttja SSO eller endast vid behov genom att anropa IdP-tjänsten och tvinga fram en användarautentisering oavsett ev. giltig SSO-session.
En IdP-tjänst kan också ha funktionalitet för att konfigurera e-tjänster att ingå i olika separata SSO-grupper. En e-tjänst i en grupp nyttjar då inte SSO från e-tjänster i en annan grupp. Observera att för närvarande har inte Ineras IdP stöd för att e-tjänster kan ingå i olika SSO-grupper, det kan dock läggas till i en framtida utveckling.

Info

Observera att beroende på vilka användaregenskaper som e-tjänsten har valt att begära, kan användaren behöva göra antingen ett val av tjänste-id eller ett uppdragsval i Ineras IdP, inom ramen för samma SSO-session. Biljetten som IdP:n utfärdar är alltid specifik för varje e-tjänst, inga attribut kommer med automatiskt. Anslutningsguide till IdP beskriver mer om detta fenomen. Dokumentet finns bland kapitlet Referenser.

Specialfall då SSO inte är önskvärd

I situationer då SP:n är ett virtualiserat skrivbord, till exempel Citrix, och det är möjligt att få åtkomst till både skrivbordet och bakomliggande applikationer via en så kallad kioskdator, är inte SSO önskvärd. Rekommendationen är då att SP:n, det vill säga det virtualiserade skrivbordet, tvingar fram en användarautentisering. Standardprotokollen SAML2 och OIDC stödjer detta, med olika syntax.

Klientprogramvara som kan användas för SSO via IdP

Alla autentiseringsmetoder som IdP-tjänsten erbjuder kan användas i kombination med SSO via IdP. Till exempel kan alla SITHS eID-appar på datorer och mobiler användas för legitimering på samma eller annan enhet. Mer information återfinns på Programvaror och tillbehör för SITHS.

mTLS: SSO genom cachning av legitimeringskoden

Om autentiseringstekniken dubbelriktad TLS (Mutual TLS) används i kombination med en eID-bärare som stödjer tekniken, såsom ett SITHS-kort, kan användaren erhålla SSO via mellanlagring/återanvändning av legitimeringskoden (PIN) på användarens klientdator.

Image Added

SSO via dubbelriktad TLS och cachning av legitimeringskod.

...

Dessutom behöver användaren använda en klientapplikation som stödjer dubbelriktad TLS, till exempel en webbläsare, men det kan även vara en nativ klientprogramvara (app).

SSO via IdP - vid olika

...

anslutningssätt

Beroende på hur infrastrukturtjänsterna används och hur e-tjänster ansluts, kan SSO via IdP erhållas under delvis olika förutsättningar. Detta avsnitt belyser hur de olika sätten att ansluta e-tjänster till IdP-tjänster möjliggör SSO för användarna.

Notera igen att SSO via IdP kan åstadkommas oavsett autentiseringsteknik. I nedan bilder används en autentiseringstjänst med stöd för out-of-band-teknik där användarens eID-lösning kan finnas på samma eller annan enhet, men mönstren kan tillämpas även för andra eID-lösningar inklusive legitimering med dubbelriktad TLS.

E-tjänst ansluts till

...

Ineras IdP (eller annan IdP)

Image Added

I detta fall ansluts e-tjänsten direkt till IdP-tjänst som tillhandahåller autentisering via en autentiseringstjänst. Vi har därmed det grundläggande fallet för SSO via IdP enligt ovan.

SSO kan potentiellt erhållas för alla e-tjänster som är anslutna till samma IdP-tjänst. E-tjänsterna kan då betraktas som en ”SSO-grupp”. Till exempel applicerar detta på nationella och lokala e-tjänster som är direkt anslutna till Ineras IdP.

E-tjänst ansluts via en IdP-proxy

...

till Ineras IdP (eller annan IdP)

Ett annat anslutningssätt är att ansluta en lokal IdP (A) till en IdP (B) som i sin tur tillhandahåller önskad e-legitimering. Den lokala IdP-tjänsten agerar då proxy till den bakomliggande IdP-tjänsten.

Image Added

En lokal IdP agerar proxy mot en bakomliggande IdP.

...

Som i tidigare avsnitt kan användaren få SSO när hen loggar in i olika e-tjänster inom respektive SSO-grupp, men det finns även möjlighet att få SSO mellan dessa grupper.

SSO från både lokal och bakomliggande IdP

...

, t ex Ineras IdP

Användaren kan få SSO från båda IdP-tjänsterna i kombination under förutsättning att

...

Nedan följer två exempelscenarier där vi förutsätter att ovan gäller.

Exempel ett:

Användaren loggar först in i en e-tjänst ansluten till IdP A. Användaren autentiseras via Autentiseringstjänsten hos IdP B.

...

SSO-session A och B etableras i respektive IdP-tjänst.

...

Användaren loggar strax därpå in i e-tjänst ansluten till IdP B.
àIdP B kontrollerar om det finns en giltig SSO-session B för användaren, vilket det gör, och användaren loggas in via SSO.
Användaren loggar strax därpå in i e-tjänst ansluten till IdP A
àIdP A kontrollerar om det finns en giltig SSO-session A för användaren, vilket det gör, och användaren loggas in via SSO.
Användaren loggar långt senare, efter att SSO-sessionerna löpt ut, in i e-tjänst ansluten till IdP A. Detta leder till ett nytt försök att autentisera användaren: à
IdP A kontrollerar om det finns en giltig SSO-session för användaren, vilket det inte gör, och skickar vidare autentiseringsbegäran till bakomliggande IdP B.
àIdP B kontrollerar om det finns en giltig SSO-session för användaren, vilket det inte gör, och användaren autentiseras på nytt via Autentiseringstjänsten hos IdP B.

Exempel två:

Användaren loggar först in i en e-tjänst ansluten till IdP B. Användaren autentiseras via Autentiseringstjänsten hos IdP B. à
SSO-session B etableras i IdP B.
Användaren loggar strax därpå in i e-tjänst ansluten till IdP A.
àIdP A kontrollerar om det finns en giltig SSO-session för användaren, vilket det inte gör, och skickar vidare autentiseringsbegäran till bakomliggande IdP B. à
IdP B kontrollerar om det finns en giltig SSO-session för användaren, vilket det gör, och användaren loggas in via SSO.

...

Användaren loggar först in i en e-tjänst ansluten till IdP B. Användaren autentiseras via Autentiseringstjänsten hos IdP B. à
SSO-session B etableras i IdP B.
Användaren loggar strax därpå in i e-tjänst ansluten till IdP A som även tillhandahåller lokala autentiseringsmetoder.
àIdP A kontrollerar om det finns en giltig SSO-session A för användaren, vilket det inte gör.
àIdP A ställer autentiseringsfråga med Passiv SSO till bakomliggande IdP B, för kontroll om ev. giltig SSO-session i B.
àIdP B kontrollerar om det finns en giltig SSO-session för användaren, vilket det gör i detta fall. IdP B returnerar identitetsintyg och användaren loggas in via SSO.

...

Användaren loggar först in i en e-tjänst ansluten till IdP A. Användaren autentiseras via en lokal autentiseringsmetod hos IdP A. à
SSO-session A etableras i IdP A.
Användaren loggar strax därpå in i e-tjänst ansluten till IdP B.
àIdP B kontrollerar om det finns en giltig SSO-session B för användaren, vilket det inte gör, och användaren autentiseras på nytt via Autentiseringstjänsten hos IdP B. à
SSO-session B etableras i IdP B.
Användaren erhåller därefter SSO så länge SSO-sessionen gäller vid upprepade nya inloggningsförsök till e-tjänster anslutna till endera IdP A eller B.

SSO med olika teknik

...

parallellt

Om det tillämpas olika tekniker för SSO för olika e-tjänster för samma användargrupp, kan användaren få SSO som en sammantagen effekt av dessa tekniker.

Image Added

Blandad teknik för SSO används parallellt

...

För användaren kan upplevelsen bli SSO i båda fallen, trots att de tekniska lösningarna bakom är olika och åtskilda.

Observera att det inte går att blanda autentiseringstekniker i samma grupp för att uppnå äkta SSO. Respektive e-tjänsts behov av attribut kan dessutom leda till val av tjänste-id eller uppdragsval.