Fördjupning om SSO

Owned by Former user (Deleted)
Last updated: okt. 23, 2023
9 min read

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: 

  1. Användaren väljer att logga in i en e-tjänst 
  2. E-tjänsten skickar en autentiseringsbegäran till lämplig IdP-tjänst (legitimeringstjänst).  
  3. 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. 
  4. IdP-tjänsten utfärdar ett nytt identitetsintyg med begärda användaregenskaper som returneras till e-tjänsten. 
  5. 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.
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.  

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: 

  1. Användaren loggar först in i en e-tjänst ansluten till IdP A. Användaren autentiseras via Autentiseringstjänsten hos IdP B.
  2. SSO-session A och B etableras i respektive IdP-tjänst.
  3. Användaren loggar strax därpå in i e-tjänst ansluten till IdP B.
  4. 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.
  5. Användaren loggar strax därpå in i e-tjänst ansluten till IdP A
  6. 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.  
  7. 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:
  8. 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.  
  9. 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å: 

  1. Användaren loggar först in i en e-tjänst ansluten till IdP B. Användaren autentiseras via Autentiseringstjänsten hos IdP B.
  2. SSO-session B etableras i IdP B. 
  3. Användaren loggar strax därpå in i e-tjänst ansluten till IdP A.
  4. 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.  
  5. 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: 

  1. Användaren loggar först in i en e-tjänst ansluten till IdP B. Användaren autentiseras via Autentiseringstjänsten hos IdP B.
  2. SSO-session B etableras i IdP B. 
  3. Användaren loggar strax därpå in i e-tjänst ansluten till IdP A som även tillhandahåller lokala autentiseringsmetoder.
  4. IdP A kontrollerar om det finns en giltig SSO-session A för användaren, vilket det inte gör.  
  5. IdP A ställer autentiseringsfråga med Passiv SSO till bakomliggande IdP B, för kontroll om ev. giltig SSO-session i B.
  6. 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: 

  1. 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.
  2. SSO-session A etableras i IdP A. 
  3. Användaren loggar strax därpå in i e-tjänst ansluten till IdP B.
  4. 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.
  5. SSO-session B etableras i IdP B. 
  6. 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å äkta SSO. Respektive e-tjänsts behov av attribut kan dessutom leda till val av tjänste-id eller uppdragsval. 

Referenser

Referensarkitektur för Identitet och åtkomst ARK_0046

Att ansluta e-tjänster för autentisering med SITHS eID (till SITHS eID)

Anslutningsguide till IdP

Klientprogramvaror för SITHS eID

Säkerhetstjänster på Ineras hemsida

Identifieringstjänst SITHS på Ineras hemsida

Publik Information