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.
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:
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
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.
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
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).
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.
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.
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.
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:
Exempel två:
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:
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:
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å äkta SSO. Respektive e-tjänsts behov av attribut kan dessutom leda till val av tjänste-id eller uppdragsval.
Referensarkitektur för Identitet och åtkomst ARK_0046
Att ansluta e-tjänster för autentisering med SITHS eID (till SITHS eID)
Klientprogramvaror för SITHS eID
Säkerhetstjänster på Ineras hemsida
Identifieringstjänst SITHS på Ineras hemsida