...
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 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.
...
- 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
...
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)
Klientprogramvaror för SITHS eID