Sidjämförelse

Innehållsförteckning

exclude	" "

Inledning

En viktig funktion som efterfrågas är 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 för flera e-tjänster. Dvs för användaren betyder räcker det att man inte behöver legitmera sig för varje e-tjänst som användaren vill komma åtmed 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 artikel sida beskriver detta fenomendessa 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 i denna artikel kan vara Ineras IdP men beskrivningarn scenariorna är i många fall allmänt tillämpliga.För närvarande är det inte möjligt att ingå i olika SSO-grupper om man använder Ineras IdP, det kan dock läggas till i e framtida utveckling

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.

...

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.

...

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.

...

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.

...

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.