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, 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.
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 uppnås här via en IdP-tjänst enligt följande grundläggande mönster:
- Användaren väljer att logga in i en e-tjänst
- E-tjänsten skickar en autentiseringsbegäran till lämplig IdP-tjänst (legitimeringstjänst).
- Om IdP-tjänsten har en giltig SSO-session med användarens klient, avkrävs ingen ny autentisering av användaren. Saknas giltig SSO-session sker ny autentisering av användaren.
- IdP-tjänsten utfärdar ett nytt identitetsintyg med begärda användaregenskaper som returneras till e-tjänsten.
- E-tjänsten verifierar intygets giltighet, och om användaren är behörig att använda e-tjänsten blir användaren inloggad.
Ovan mönster kan sedan upprepas om användaren väljer att logga in i andra e-tjänster under arbetspasset, och SSO fås om detta sker inom den sessionstid som konfigurerats.
För SSO enligt detta mönster gäller
- 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.
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.
SSO via dubbelriktad TLS och cachning av legitimeringskod.
För SSO enligt detta mönster gäller
- SSO kräver en klientprogramvara på datorn som hanterar gränssnittet mot användare/eID-bäraren samt mellanlagringen (cachning) av legitimeringskoden.
- SSO-sessionen avslutas lokalt på användarens klientdator2; det finns begränsade möjligheter att styra SSO-sessionen från e-tjänsten eller IdP-tjänsten.
- SSO fungerar bara med autentiseringstekniken dubbelriktad TLS och eID-bäraren måste vara fysiskt kopplad till samma enhet som användaren arbetar i (in-band-teknik). För SITHS innebär det enbart kort och kortläsare.
- Varken e-tjänsten eller IdP kan styra om SSO ska nyttjas eller inte vid ett givet tillfälle, det styrs av klientprogramvaran. Förnyad e-legitimering kan således inte tvingas fram vid behov pga. den mellanlagrade legitimeringskoden.
Klientprogramvara som kan användas för SSO via cachad legitimeringskod
SITHS eID-app i paketering ”MD” (Minidriver) samt Net iD Enterprise stödjer dubbelriktad TLS med ett SITHS-kort och kortläsare i datorn samt denna form av SSO. Mer information återfinns på Programvaror och tillbehör för SITHS.
Notera att denna SSO-teknik inte kan tillämpas på Mobilt SITHS eller andra out-of-band-lösningar.
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)
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.
En lokal IdP agerar proxy mot en bakomliggande IdP.
Tekniskt sett agerar lokal IdP (A) som en Service Provider (SP) i förhållande till bakomliggande IdP (B), precis som e-tjänsterna lokalt gör gentemot lokal IdP. Detta anslutningssätt kan ge alla e-tjänster anslutna till en lokal IdP tillgång till autentiseringsmetoden genom endast en teknisk anslutning från den lokala IdP-tjänsten.
I figuren ovan har vi för enkelhets skull kallat e-tjänster anslutna till lokal IdP ”SSO-grupp A” och e-tjänster anslutna till bakomliggande IdP ”SSO-grupp B”. Även IdP A tillhör tekniskt sätt ”SSO-grupp B” då den är ansluten som en SP till IdP B.
Notera att en e-tjänst mycket väl kan erbjuda inloggning via flera IdP-tjänster (t.ex. både A och B), men för att förenkla resonemangen något antar vi att SSO-grupperna är separata.
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
- Användaren använder samma klient (user agent) i interaktionen med IdP-tjänsterna.
- Lokal IdP skickar vidare alla autentiseringsbegäran till bakomliggande IdP.
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.
Lokala autentiseringsmetoder och SSO
Men vad händer om inte all användarautentisering hanteras av den bakomliggande IdP-tjänsten B? Antag att IdP A också tillhandahåller lokala autentiseringsmetoder till användarna, dvs. IdP A hanterar autentisering för dessa metoder utan stöd av IdP B. Kan användaren ändå få SSO?
Villkoret för att få SSO från IdP B är att IdP A skickar vidare alla autentiseringsbegäran till IdP B. För att kunna nyttja SSO-session B även när lokala autentiseringsmetoder nyttjas, kan IdP A skicka en extra autentiseringsfråga till IdP B med s.k. ”Passiv SSO”3. Passiv SSO innebär att bakomliggande IdP B endast kontrollerar om det finns en giltig SSO-session och returnerar i så fall ett identitetsintyg.
Låt oss åter titta på ett exempel, men vi lägger till att lokal IdP också tillhandahåller lokala autentiseringsmetoder och önskemålet är att möjliggöra SSO från IdP B även i detta fall.
Exempel:
- 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.
Notera dock att när mönstret IdP-proxy används, konfigureras den lokala IdP-tjänsten A att lita på den bakomliggande IdP-tjänsten B, inklusive dess autentiseringstjänster och SSO-sessioner. Det innebär också att nyttjande av eventuella lokala autentiseringstjänster hos IdP A inte påverkar IdP B och dess SSO-session. För att få SSO från IdP B måste alltså först autentisering ske via IdP B genom inloggning i en e-tjänst ansluten till endera IdP A eller B.
Följande exempel illustrerar detta:
Exempel:
- 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.
Blandad teknik för SSO används parallellt
Låt oss anta att en grupp e-tjänster använder SSO via IdP och stödjer ett antal olika autentiseringsmetoder, till exempel SITHS eID på kort och mobil.
En annan grupp e-tjänster stödjer enbart dubbelriktad TLS samt SITHS eID på kort. För att användarna ska få SSO även för dessa system så antar vi att SITHS eID-app i paketering ”MD” (med Minidriver) används för cachning av legitimeringskoden på klientdatorerna. Paketeringen kan även användas för inloggning till Windows-dator med SITHS-kort.
Vilken teknik för SSO som i det enskilda fallet kommer att användas, beror på vilken e-tjänst som användaren försöker logga in i.
För en e-tjänst som är ansluten via en IdP för autentisering av användaren, kommer tekniken ”SSO via IdP” att användas. IdP-tjänsten kommer att kontrollera om det finns en giltig SSO-session sedan tidigare, och SSO fås enligt vad vi beskrivit ovan.
För en e-tjänst som i stället använder autentisering direkt med SITHS-kort och dubbelriktad TLS, kommer tekniken med cachning av legitimeringskoden att kunna nyttjas för SSO.
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å SSO.
Referenser
Referensarkitektur för Identitet och åtkomst ARK_0046
Att ansluta e-tjänster (till SITHS eID)
Klientprogramvaror för SITHS eID