Tjänstespecifikation

Transkript

1 1(47) Tjänstespecifikation för Anvisningstjänst som del av Svensk e-legitimation

2 2(47) INNEHÅLLSFÖRTECKNING 1 INLEDNING Tjänsten i sitt sammanhang Syfte Mål Förväntade effekter Styrande förutsättningar Avgränsningar FUNKTIONELL BESKRIVNING Sammanfattning Arkitektur och ingående funktioner Central anvisning Lokalt integrerad anvisning Beskrivning av funktioner JavaScript för anvisning Anvisningsfeed Funktion för hantering av användarstatus Webbsida med gränssnitt för val av legitimeringstjänst BESKRIVNING AV GRÄNSSNITT Tekniska gränssnitt Standarder och profiler Gränssnitt för integration med Anvisningstjänsten JavaScript API Grafiska gränssnitt Gränssnitt vid visning av alla valbara legitimeringstjänster Gränssnitt med föreslaget förval Gränssnitt vid Single Sign On Hantering av tillitsnivåer och kategorier Informationsspridning FUNKTIONELLA KRAV Anvisningstjänstens funktioner Protokollstöd enligt IdpDisco JavaScript för anvisning Anvisningsfeed Hantering av användarstatus Anvisningstjänstens användargränssnitt ICKE FUNKTIONELLA KRAV Säkerhets- och tillgänglighetskrav Verifiering av metadata Krav på administration och kontroll Loggar Administration och konfigurering... 32

3 3(47) Krypterad kommunikation Tillförlitlig tid Tillgänglighet Integrationsdokumentation KRAV PÅ UTVECKLING Uppdateringar av funktionalitet och felrättningar Bakåtkompatibla uppdateringar Bakåtinkompatibla förändringar Framtida metoder för anvisning Account Chooser INFORMATIONSMODELL Legitimeringstjänster (Identity Providers) E-tjänster (Service Providers) ANVÄNDNINGSFALL OCH SEKVENSDIAGRAM Användare autentiseras mot e-tjänst Användare avbryter val av legitimeringstjänst Anvisningstjänstens roll vid Single Sign On Generell Single Sign On Single Sign On med passiv Anvisningstjänst E-tjänsten kräver autentisering av användaren Sömlös inloggning mellan e-tjänster REFERENSER Normativa referenser... 46

4 4(47) 1 INLEDNING 1.1 TJÄNSTEN I SITT SAMMANHANG En Anvisningstjänst, eller Discovery Service, har som sitt syfte att avlasta de enskilda e-tjänsterna (Service Providers, SP) inom federationen från att själva implementera stöd för hur användare väljer legitimeringstjänst (Identity Provider, IdP) för autentisering. Genom att en Anvisningstjänst finns tillgänglig inom federationen kan e-tjänster styra sina användare dit för val av legitimeringsmetod (eller legitimeringstjänst). Anvisningstjänsten interagerar med användaren som gör sitt val och användaren, tillsammans med dennes val, styrs tillbaka till e-tjänsten som nu vet till vilken legitimeringstjänst användaren ska skickas för legitimering. 1.2 SYFTE Syftet med Anvisningstjänsten är att tillhandahålla en enkel och robust infrastrukturkomponent för tillhandahållare av e-tjänster och dess slutanvändare för val av legitimeringstjänst vid inloggning mot e-tjänst. 1.3 MÅL Målet med Anvisningstjänsten är att den alltid är tillgänglig och att dess svarstider medverkar till en positiv användarupplevelse. Anvisningstjänsten är enkel att integrera emot för e-tjänster och den kräver lite administration. 1.4 FÖRVÄNTADE EFFEKTER Anvisningstjänsten skapar förutsättningar för att slutanvändaren får ett bättre stöd i valet av e-legitimation i e-tjänster och ger en säker kommunikation över Internet. Vidare bidrar tjänsten till en effektivare utveckling av e-tjänster. 1.5 STYRANDE FÖRUTSÄTTNINGAR Anvisningstjänsten läser från metadatatjänsten och extraherar relevant data. Fastställda format avseende metadata och en samverkan vid förändring krävs. Visuella gränssnitt som exponeras av Anvisningstjänsten för val av legitimeringsmetod skall utformas i samverkan med E-legitimationsnämnden. Centrala begrepp är användbarhet, tillgänglighet och enkelhet. För att underlätta för användare som utför val skall Anvisningstjänsten spara användares tidigare val av legitimeringsmetod genom skrivning av webbläsar-cookies, och därmed kunna erbjuda förenklade valsidor. Anvisningstjänsten skall betjäna användare som ansluter via såväl vanliga webbläsare som mobila enheter.

5 5(47) Anvisningstjänsten för Svensk e-legitimation är en vital punkt inom federationen då i princip alla e-legitimationsinloggningar som utförs behöver någon form av anvisning. Tjänsten skall dimensioneras och säkras därefter. Anvisningstjänstens arkitektur skall utformas på ett sådant sätt att e-tjänster inom federationen har möjlighet att använda komponenter från Anvisningstjänsten för att lokalt integrera anvisning i e-tjänsten (se 2.2.2, Lokalt integrerad anvisning ). 1.6 AVGRÄNSNINGAR Anvisningstjänsten innefattar inte komponenter och anpassningar som utförs hos e-tjänster för att implementera anvisning. Lokalt integrerad anvisning ingår därför inte i Anvisningstjänsten. Däremot ingår i Anvisningstjänsten att tillhandahålla centrala funktioner och gränssnitt för att möjliggöra lokalt integrerad anvisning. I detta dokument finns informativa avsnitt där lokalt integrerad anvisning hos e-tjänster beskrivs.

6 6(47) 2 FUNKTIONELL BESKRIVNING 2.1 SAMMANFATTNING Anvisningstjänsten betjänar federationens e-tjänster med ett centralt stöd för hur användare utför val av legitimeringstjänst. Nedanstående sekvensdiagram illustrerar det enkla protokoll som används för att åstadkomma anvisning. Användare (webbläsare) e-tjänst (SP) Anvisningstjänst (DS) Begäran om anvisning genom HTTP redirect till DS Användaren väljer legitimeringstjänst (IdP) Resultat av anvisning returneras till SP genom HTTP redirect Figur 1: Sekvensdiagram som illustrerar hur e-tjänst begär anvisning. Anvisningstjänsten ansvarar för att sammanställa en vy för användaren där alla valbara legitimeringstjänster visas. Denna information läses från federationens metadataregister och filtreras baserat på e-tjänstens krav på legitimering, användarens egenskaper och legitimeringstjänsternas egenskaper. Anvisningstjänsten skall hantera användarnas val över tid med syfte att underlätta valsituationen för användare, d.v.s., en användares tidigare val av legitimeringstjänst skall framhävas så att användaren endast behöver bekräfta sitt tidigare val. Anvisningstjänsten skall också hantera användares val av legitimeringstjänst inom en webbläsarsession för att understödja Single Sign On mellan federationens e-tjänster. Användandet av en central tjänst för anvisning innebär att federationens aktörer använder ett och samma gränssnitt då användare väljer legitimeringstjänst. Syftet är att användare alltid skall förstå att de utför en e-legitimationsinloggning och inte behöva lära sig flera olika sätt att autentisera sig mot offentliga e-tjänster. Det centrala gränssnittet ger också möjlighet att på ett

7 7(47) centralt ställe sammanställa information rörande användandet av e-legitimationer, något som i dagsläget är spritt hos alla e-tjänster som erbjuder e-legitimationsinloggning. En central tjänst introducerar en punkt i federationen, som om den inte fungerar korrekt påverkar möjligheter till inloggning mot alla e-tjänster som är beroende av anvisning. Det ställer ett antal icke-funktionella krav på Anvisningstjänsten vad gäller tillgänglighet och svarstider för att säkerställa den centrala tjänstens stabilitet inom federationen. Anvisningstjänsten skall konstrueras på ett sådant sätt att e-tjänster kan ärva in information från den centrala tjänsten för att utföra lokalt integrerad anvisning och därmed undvika ett beroende till en central tjänst. Detta beskrivs i kapitlet nedan. 2.2 ARKITEKTUR OCH INGÅENDE FUNKTIONER Inom federationen för Svensk e-legitimation kan e-tjänster åstadkomma anvisning på två olika sätt: Central anvisning En e-tjänst som använder central anvisning skickar sina användare till Anvisningstjänsten för val av legitimeringstjänst. Då användaren utfört sitt val returneras denna till e-tjänsten för fortsatt hantering av inloggningen. I detta fall används protokollet som beskrivs i [idp-disco]. Lokalt integrerad anvisning Genom integrering av funktioner från Anvisningstjänsten genererar e-tjänsten en lokal sida för anvisning med samma utseende och interna logik för anvisning som den centrala tjänsten. Skillnaden mot den centrala lösningen ligger främst i hur integrationen utförs (JavaScript-anrop istället för HTTP-redirect enligt [idp-disco]). För att kunna åstadkomma stöd för ovanstående metoder skall Anvisningstjänsten delas upp i delkomponenter som levererar funktioner som kan användas för både central och lokalt integrerad anvisning. Dessa funktioner är: JavaScript för anvisning En funktion som används i webbläsaren för att generera ett användargränssnitt för val av legitimeringstjänst. Funktionen har också som sin uppgift att, baserat på e-tjänsters och legitimeringstjänsters egenskaper, filtrera vallistan för användaren. Anvisningsfeed Funktion som läser data från federationens metadata, verifierar denna och gör den tillgänglig för Anvisningstjänstens logik. En eller flera speglingar av denna funktion skall göras tillgängliga för att säkerställa tillgängligheten för anvisning. Central funktion för hantering av användarstatus En central funktion där webbläsare/javascript kan spara och läsa användarstatus till/från användarnas webbläsare genom att styra dessa mot den centrala statusfunktionens domänadress. Användarstatus är användares förvalda och aktuella legitimeringstjänster. Webbsida med gränssnitt för val av legitimeringstjänst Den webbsida som användaren laddar hem till sin webbläsare som innefattar ett användargränssnitt för val

8 - + Anvisningstjänst för svensk e-legitimation Avbryt Även e-legitimationer från SEB och Skatteverket Hem Ange språk Hjälp Kontakt - + Välkommen till Myndigheten Logga in Leveransavtal 8(47) av legitimeringstjänst. Denna sida tillhör Anvisningstjänsten. E-tjänster som använder lokalt integrerad anvisning ansvarar själva för denna funktion 1. Givet dessa funktioner kan central och lokalt integrerad anvisning illustreras enligt nedan Central anvisning + e-tjänst Anvisningstjänsten för svensk e-legitimation Ange den e-legitimation du önskar använda för att legitimera dig Myndigheten + BankID Telia e-legitimation Informationssidan Här finns en massa information som inte kräver inloggning. Anvisningsfeed Mobilt BankID Hjälp mig ta reda på vilken e-legitimation jag har... Steria e-legitimation Allmän information där Myndigheten sprider sitt budskap. Logga in till Mina Sidor Kom ihåg mitt val Klicka på knappen för att logga in till mina sidor med din e-legitimation. JavaScript för Anvisning Vad är en e-legitimation? Har du tekniska problem med din e-legitimation? Skaffa en e-legitimation Tjänst för Användarstatus HTTP redirect till Anvisningstjänst enligt IdpDisco-protokollet. Användaren loggar in mot e-tjänsten. Anvisningstjänsten Figur 2: E-tjänst som använder central anvisning. Användare Bilden ovan illustrerar hur Anvisningstjänstens funktioner används för att bygga upp en central anvisning. Användaren loggar in mot e-tjänsten och styrs då till Anvisningstjänsten via en HTTP-redirect enligt protokollet beskrivet i [idp-disco]. I exemplet ovan exponerar Anvisningstjänsten URL:en som adress för central anvisning. Anvisningstjänsten bygger upp HTML-sidan som användaren utför sitt val från genom att ladda och anropa funktioner i JavaScript för Anvisning. Detta JavaScript anropar i sin tur Anvisningstjänstens funktioner för Anvisningsfeed för att kunna läsa metadata rörande e- tjänsten och de legitimeringstjänster som skall presenteras, samt funktionen för Användarstatus vilken används för att läsa och uppdatera användarens förvalda (och aktuella) legitimeringstjänst. All logik rörande vilka legitimeringstjänster som skall presenteras i gränssnittet utförs av JavaScript för Anvisning och exekveras sålunda i användarens webbläsare istället för på servern, vilket medför att Anvisningstjänsten kan betjäna anrop snabbare och med mindre processorkraft. 1 Dock är det möjligt för dessa e-tjänster att använda samma stildefinitioner (CSS:er) som används av Anvisningstjänsten.

9 - + Anvisningstjänst för svensk e-legitimation Avbryt Även e-legitimationer från SEB och Skatteverket Hem Ange språk Hjälp Kontakt - + Välkommen till Myndigheten Logga in Leveransavtal 9(47) Lokalt integrerad anvisning e-tjänst Anvisningstjänsten för svensk e-legitimation + Anvisningsfeed Proxy för Anvisningsfeed Ange den e-legitimation du önskar använda för att legitimera dig BankID Telia e-legitimation Myndigheten Informationssidan Här finns en massa information som inte kräver inloggning. Mobilt BankID Steria e-legitimation Allmän information där Myndigheten sprider sitt budskap. JavaScript för Anvisning Cachat JavaScript för Anvisning Hjälp mig ta reda på vilken e-legitimation jag har... Kom ihåg mitt val Vad är en e-legitimation? Skaffa en e-legitimation Har du tekniska problem med din e-legitimation? Logga in till Mina Sidor Klicka på knappen för att logga in till mina sidor med din e-legitimation. Logga in Tjänst för Användarstatus Anvisningstjänsten Styrs till lokalt genererad sida för anvisning. Användaren loggar in mot e-tjänsten. Spegling av Anvisningsfeed Figur 3: Anvisning genom lokal integration hos e-tjänst. Detta avsnitt illustrerar hur Anvisningstjänstens funktioner används för att åstadkomma lokalt integrerad anvisning. Detta är ett informativt avsnitt och omfattar inte krav på Anvisningstjänsten. En hos e-tjänsten lokalt integrerad anvisning innebär att användaren inte styrs till en central tjänst för anvisning utan att e-tjänsten själv ansvarar för att konstruera sidan vari användaren utför sitt val (i exemplet ovan på adressen För detta syfte använder e-tjänsten de funktioner som exponeras av Anvisningstjänsten ingen egen logik för anvisning implementeras. För att e-tjänsten skall kunna använda Anvisningstjänstens funktioner krävs följande: Vid lokalt integrerad anvisning använder e-tjänsten Anvisningstjänsten funktioner enligt följande: E-tjänsten konfigurerar en proxy för hämtning av anvisningsdata från Anvisningstjänstens funktion Anvisningsfeed. Data från Anvisningsfeed används av JavaScript för Anvisning då dess logik bygger upp valsidan. För att säkerställa att funktionen JavaScript för Anvisning alltid har tillgång till anvisningsdata kan e-tjänsten välja mellan följande metoder: - Konfigurera JavaScriptet att gå till en spegling av Anvisningstjänstens metadata om dess master inte är tillgänglig. Detta förfarande innebär att en mycket enkel proxy för hämtning av metadata kan användas, t.ex. Apache ProxyPass.

10 Hem Ange språk Hjälp Kontakt Leveransavtal 10(47) - Implementera en mer avancerad proxy som också har möjlighet att mellanlagra (cacha) nedladdat metadata. I detta fall kan e-tjänstens proxy-funktion leverera metadata även då den centrala funktionen för Anvisningsfeed inte är tillgänglig. E-tjänsten använder sig av samma JavaScript som Anvisningstjänsten det enda som skiljer är dess konfiguration. Detta JavaScript laddas ned periodiskt till e-tjänsten för att undvika ett direkt beroende till Anvisningstjänsten. E-tjänsten använder en egen webbsida som laddar JavaScript för Anvisning och tar hand om resultatet av användarens val. För detta kan e-tjänsten välja att skapa en fristående webbsida inom tjänstens webb och utför integrering genom att inkludera Anvisningstjänstens JavaScript på e-tjänstens sida, t.ex Anvisningstjänst för svensk e-legitimation + Anvisningstjänsten för svensk e-legitimation Ange den e-legitimation du önskar använda för att legitimera dig BankID Telia e-legitimation Även e-legitimationer från SEB och Skatteverket Mobilt BankID Steria e-legitimation Hjälp mig ta reda på vilken e-legitimation jag har... Avbryt Kom ihåg mitt val Vad är en e-legitimation? Skaffa en e-legitimation Har du tekniska problem med din e-legitimation? E-tjänsten kan också inkludera anvisning som en del av en av e-tjänstens sidor för att bättre integrera med e-tjänstens inloggningsflöde. - + Välkommen till Myndigheten + Myndigheten Logga in Ange den e-legitimation du önskar använda för att legitimera dig BankID Telia e-legitimation Även e-legitimationer från SEB och Skatteverket Mobilt BankID Steria e-legitimation Hjälp mig ta reda på vilken e-legitimation jag har... Avbryt Kom ihåg mitt val Det enda beroende till Anvisningstjänsten som kvarstår efter att e-tjänsten konstruerat sin miljö enligt ovan är beroendet till den centrala funktionen för hantering av användarstatus. Om denna funktion inte är tillgänglig kan e-tjänsten inte läsa eller uppdatera användarens förvalda legitimeringstjänst, men det innebär inte att användaren inte kan legitimera sig, bara

11 11(47) att användarens förval inte kan presenteras. Att funktionen för hantering av användarstatus inte kan exekvera lokalt beror på webbläsares krav på Same Origin Policy BESKRIVNING AV FUNKTIONER JavaScript för anvisning Anvisningstjänsten är en central tjänst inom federationen för Svensk e-legitimation och är inblandad i princip samtliga inloggningar som utförs med e-legitimationer till e-tjänster inom federationen. Detta innebär att Anvisningstjänsten skall kunna hantera många samtidiga anrop och dessutom ha korta svarstider. Ett sätt att dramatiskt minska bördan på tjänsten är att låta användarnas webbläsare göra en stor del av arbetet. Därför skall logiken för anvisning utföras av ett JavaScript som exekverar på klienten. En annan fördel med att placera Anvisningstjänstens logik i ett JavaScript är, som redan nämnts, att en sådan uppdelning medger att samma bakomliggande teknik kan användas av både en central tjänst och för lokalt integrerad anvisning hos e-tjänster. Detta JavaScript skall ombesörja följande: Hämta relevant metadata i JSON- eller XML-format från Anvisningsfeed. Hämta relevant information angående användares förvalda (och aktuella) val av legitimeringstjänster från webbläsaren med stöd av den centrala funktionen för hantering av användarstatus, eller med andra ord, läsa användarnas webbläsarcookies 3 för förval och aktuellt val. Utföra selektering (filtrering) av valbara legitimeringstjänster enligt de krav och egenskaper som gäller för e-tjänsten och legitimeringstjänsterna. Skapa grafiskt gränssnitt för val av legitimeringstjänst (generera HTML). Ta emot information om användarens val av legitimeringstjänst. Uppdatera användarstatus rörande utfört val av legitimeringstjänst med stöd av den centrala funktionen för hantering av användarstatus (skriva webbläsarcookies). Tillhandahålla information om användarens valda legitimeringstjänst. Detta JavaScript tillhandahåller alltså såväl grafiskt gränssnitt som funktioner för val av legitimeringstjänst när det infogas och aktiveras inom en webbsida (se 2.3.4, Webbsida med gränssnitt för val av legitimeringstjänst, nedan) Anvisningsfeed Metadatatjänstens funktion för publicering [spec-metadata] är källan till metadata för Anvisningstjänsten. Funktionen för Anvisningsfeed utför följande steg: 2 Same Origin Policy är en säkerhetspolicy som begränsar en webbläsare till att endast hämta data från samma domän som den webbsida, som hämtar information, själv hämtades från. En webbsida från example.com kan endast hämta data från example.com. 3 För webbläsare som stödjer funktionen Web Storage skall denna metod användas i stället för webbläsarcookies.

12 12(47) Läser metadata från metadatatjänstens funktion för publicering. Säkerställer metadatans autenticitet genom att verifiera dess signatur. Extraherar relevant data för anvisningstjänstens logik (se kapitel 7,

13 13(47) Informationsmodell ). Sammanställer dessa data i ett väldefinierat format och gör den tillgänglig för konsumering (av JavaScript för anvisning ). Ovanstående steg utförs periodiskt för att garantera att funktionen exponerar aktuell metadata för anvisning. De data som levereras från funktionen Anvisningsfeed läses endast av JavaScriptet som hanterar anvisningslogiken, vilket innebär att dess format inte behöver definieras och dokumenteras för extern konsumtion. Formatet skall vara anpassat så att det lämpar sig för HTTP cachning hos e-tjänster som integrerar anvisning lokalt (se 2.2.2, Lokalt integrerad anvisning ). Funktionen för Anvisningsfeed skall speglas i ytterligare minst en instans. Denna instans skall installeras på en domän separerad från Anvisningstjänsten. Detta möjliggör att e-tjänster som lokalt integrerar anvisning kan använda speglade instanser som fall-back och därmed undvika ett Single Point of Failure. Det skall också finnas en process/funktion för att forcera nedladdning av data från Metadatatjänsten vid akut ändring av metadata Funktion för hantering av användarstatus Anvisningstjänsten skall kunna spara och läsa användares förvalda och aktuella legitimeringstjänster. Med aktuell legitimeringstjänst avses den legitimeringstjänst som användaren använder i befintlig webbläsarsession, och denna funktion används av Anvisningstjänsten för att understödja Single Sign On mellan e-tjänster. Hantering av ovanstående implementeras med webbläsarcookies, eller med funktionen LocalStorage om webbläsaren stödjer denna funktion. Oavsett vilken e-tjänst användaren loggar in mot, och oavsett om en central eller en hos e-tjänsten integrerad anvisning används, skall anvisningslogiken hantera förvald och aktuell legitimeringstjänst. Denna funktion skall göras till en fristående komponent inom Anvisningstjänsten så att den kan användas av både Anvisningstjänsten och av de e-tjänster som integrerar anvisning lokalt. Funktionen för hantering av användarstatus används av funktionen JavaScript för anvisning i följande situationer: Då HTML för val av legitimeringstjänst genereras utför JavaScriptet anrop till funktionen för att först ta reda på om ett aktuellt val av legitimeringstjänst är lagrat i användarens webbläsare, d.v.s., om en legitimeringstjänst redan valts för aktuell webbläsarsession. Om inget aktuellt val existerar utför JavaScriptet ett nytt anrop till funktionen. Denna gång för att läsa användarens förvalda legitimeringstjänst(er).

14 14(47) Då användaren utför ett val av legitimeringstjänst och indikerar att detta val ska sparas som en förvald legitimeringstjänst sker följande: - Om inget tidigare förval existerar skapas ett förval genom ett anrop till funktionen för hantering av användarstatus. - Om ett tidigare förval existerade och det nya valet skiljer sig från detta uppdateras användarens förval genom ett anrop till funktionen för användarstatus. I alla fall då användaren utför ett val skrivs webbläsarcookien för aktuellt val genom ett anrop till funktionen för användarstatus. Anvisningstjänstens gränssnitt erbjuder användaren möjligheter att rensa tidigare förval (se kapitel 3.2.2, Gränssnitt med föreslaget förval ). Då detta sker utförs ett anrop till funktionen för hantering av användarstatus för att rensa användarens förval. Notera: För Anvisningstjänsten kan läsning och skrivning av förvalda och aktuella legitimeringstjänster hanteras direkt i JavaScriptet om funktionen för hantering av användarstatus exekverar på samma domän som Anvisningstjänsten. I detta fall kan sedvanliga funktioner för läsning och skrivning av webbläsar-cookies användas. För att undvika att Anvisningstjänsten och integrerade lösningar för anvisning hanterar användarstatus på olika sätt skall funktionen för hantering av användarstatus exponera JavaScript-funktioner för läsning och skrivning av status för användande av Anvisningstjänsten Webbsida med gränssnitt för val av legitimeringstjänst Den webbsida med gränssnitt för val av legitimeringstjänst som presenteras för användarna ska alltid se likadan ut, och detta utseende styrs av den HTML-kod som Anvisningstjänstens JavaScript genererar. Dock skiljer sig infogandet av JavaScript/HTML beroende på om anvisning utförs av Anvisningstjänsten eller om den integreras lokalt hos en e-tjänst. Sättet användare dirigeras för anvisning och hur resultat av val hanteras skiljer sig också åt mellan de två varianterna. Detta beskrivs i detalj i kapitel 3.1, Tekniska gränssnitt, nedan. Webbsidan har sitt eget JavaScript för att aktivera anvisning via ett anrop till en funktion i JavaScript för anvisning och att hantera dess returnerade val. Webbsidans funktion är att: Skapa sidans grundläggande gränssnittsstruktur: - Övrig information och länkar på sidan som inte tillhandahålls av JavaScriptet som genererar HTML-kod för anvisning. - Färg och stil (CSS). - Placering på sidan för användargränssnittet för val av legitimeringstjänst. Aktivera användargränssnittet som tillhandahålls av JavaScriptet. Tillhandahålla en resultatfunktion som tar emot information om vald e- legitimation och använder denna för att antingen returnera informationen inom ramen för Discovery-protokollet (central anvisning), eller för att vidarebefordra användaren till relevant inloggningstjänst (lokalt integrerad anvisning).

15 15(47) 3 BESKRIVNING AV GRÄNSSNITT 3.1 TEKNISKA GRÄNSSNITT Detta avsnitt behandlar de gränssnitt som exponeras av Anvisningstjänsten Standarder och profiler Anvisningstjänsten tillämpar ett antal standarder och profiler. För fullständiga referenser se kapitel 9. Protokoll och profil för anvisning enligt en http-redirect modell, [idp-disco], utgör basen för integration med Anvisningstjänsten. Standard för SAML metadata [saml-metadata] utgör basstandard för all metadata. Denna information konsumeras av Anvisningstjänsten. SAML extension standard för användargränssnittsdata [saml-meta-mdui] specificerar en extension för lagring av användargränssnittsdata i SAML metadata. Denna information konsumeras av anvisningslogiken då användargränssnitt konstrueras. Interoperabilitetsprofil e-gov 2.0 [saml-egov20] är en SAML interoperabilitetsprofil från Kantara. Denna profil är tillämplig i alla delar som rör anvisning. Interoperabel Web SSO profil [saml2-int] specificerar en SAML deployment profil som är tillämplig för denna tjänstespecifikation i alla delar som rör anvisning. The Entity Category SAML Entity Metadata Attribute Type [entity-category] specificerar ett SAML attribut för Entity Category. Denna information konsumeras av anvisningslogiken då filtrering av legitimeringstjänster utförs Gränssnitt för integration med Anvisningstjänsten Gränssnittet för integration med Anvisningstjänsten specificeras i [idp-disco]. Protokollet för anvisning används för att en Service Provider (e-tjänst) skall kunna associera en användare med en Identity Provider (legitimeringstjänst) för legitimering. Anvisningsprotokollet innefattar tre steg och två normativa meddelandeutbyten. 1. E-tjänsten dirigerar (HTTP-redirect) användarens webbläsare till Anvisningstjänsten. I denna begäran skickas också styrande parametrar med. 2. Anvisningstjänsten interagerar med användaren för att etablera ett val av legitimeringstjänst. 3. Anvisningstjänsten dirigerar användarens webbläsare tillbaka till e-tjänsten med en parameter innehållande en identifierare för den valda legitimeringstjänsten. Om parametern utelämnas gjordes inget val.

16 16(47) Användare (webbläsare) e-tjänst (SP) Anvisningstjänst (DS) Begäran om anvisning genom HTTP redirect till DS Användaren väljer legitimeringstjänst (IdP) Resultat av anvisning returneras till SP genom HTTP redirect Figur 4: Illustration av anvisningsprotokoll enligt [idp-disco] HTTP-begäran till Anvisningstjänsten Protokollets första steg innebär att e-tjänsten dirigerar användarens webbläsare till Anvisningstjänsten med en HTTP GET-begäran. Följande parameter SKALL skickas med i query-strängen (URL-kodad): entityid Den unika identifieraren för den e-tjänst hos vilken användaren autentiserar sig. Denne identifierare är e-tjänstens entityid i federationens metadata. Följande parametrar är inte obligatoriska men kan skickas i begäran: return policy returnidparam ispassive En URL som specificerar den adress till vilken Anvisningstjänsten ska styra tillbaka webbläsaren efter det att användaren utfört sitt val. Om denna URL inte anges används elementet <idpdisc:discoveryresponse> från e-tjänstens egenskaper i federationens metadata. En parameter som anges av anropande e-tjänst för att ange enligt vilken policy Anvisningstjänsten ska utföra anvisning. Om ingen policy anges antas värdet urn:oasis:names:tc:saml:profiles:sso:idp-discoveryprotocol:single. I nuläget finns inga andra policy-värden definierade, men Anvisningstjänsten skall vara förberedd för att hantera även andra värden. Anger parameternamnet på den parameter som skall innehålla returvärdet innehållande den valda legitimeringstjänsten. Om inget värde anges används parameternamnet entityid. Anger om Anvisningstjänsten tillåts visa ett grafiskt gränssnitt för val av legitimeringstjänst, eller om tjänsten skall försöka härleda

17 17(47) filter legitimeringstjänst utan att kräva ett val av användaren. Om inget värde anges antas värdet false vilket innebär att Anvisningstjänsten tillåts interagera med användaren via det grafiska gränssnittet. Parametern filter utökar protokollet som beskrivs i [idp-disco] med funktionalitet för att påverka hur filtrering av legitimeringstjänster sker. Om denna parameter specificeras anger dess värde kriterier för att göra legitimeringstjänster valbara i gränssnittet. Till exempel kan en viss tillitsnivå specificeras vilket innebär att endast legitimeringstjänster som uppfyller denna nivå (eller högre) får visas som valbara legitimeringstjänster. Notera: Formatet för värden till parametern filter kommer att definieras i dokumentet [sv-eidprof] Dirigering tillbaka till e-tjänst Efter att användaren utfört sitt val av legitimeringstjänst skall webbläsaren dirigeras tillbaka till e-tjänsten. Anvisningstjänsten dirigerar webbläsaren till den URL som angavs som värde till return-parametern (se ovan), eller om detta värde inte angavs i begäran till den URL som anges som e-tjänstens standard-url i federationens metadata. Den legitimeringstjänst som valdes av användaren representeras med en unik identifierare (som anges i federationens metadata) och skickas tillbaka som värde till parametern entityid. Om returnidparam angavs i e-tjänstens begäran om anvisning används istället värdet av denna parameter som parameternamn. Om användaren inte utför ett val, eller om Anvisningstjänsten av någon annan anledning inte kan returnera ett val, skall Anvisningstjänsten styra tillbaka användarens webbläsare till e-tjänsten utan parameter för vald legitimeringstjänst JavaScript API Då lokalt integrerad anvisning implementeras av e-tjänsten används inte det protokoll som beskrivs i [idp-disco] utan integrering sker genom ett anrop till nedanstående funktion som exponeras från JavaScript för anvisning. Då funktionen anropas genereras HTML-kod för anvisning som inkluderas på angiven plats på e-tjänstens webbsida. Användarens valda legitimeringstjänst överförs till e-tjänsten via ett anrop till den angivna callback-funktionen. function dodiscovery(discoverysettings) Följande namn-värde-par ingår i objektet DiscoverySettings: entityid Den unika identifieraren för e-tjänsten vilken integrerar anvisningen. Denna identifierare är e-tjänstens entityid i federationens metadata. Denna parameter har samma innebörd som anges i protokollet som

18 18(47) includediv dsproxies uiconfig resultcallback beskrivs i [idp-disco]. Detta värde måste anges. Pekare till ett HTML div-element inom vilket gränssnittet för val av legitimeringstjänst skall placeras på e-tjänstens webbsida. Detta värde måste anges utom i de fall då ispassive=true tilldelas uiconfig (se nedan). En array av en eller flera adresser till e-tjänstens instanser av Proxy för anvisningsdata (se 2.2.2, Lokalt integrerad anvisning ). Detta värde måste anges. Ett objekt av namn-värde par som används för att styra hur gränssnittet för anvisning utformas. Om detta värde inte anges används standardinställningar. Se nedan för möjliga värden. En JavaScript-funktion som tar emot identifieraren för vald legitimeringstjänst (entityid) och använder detta för att legitimera användaren. Om inget val utfördes anropas funktionen med ett nullvärde. Detta värde måste anges. Möjliga namn-värde properties kan tillkomma. Eventuella tillägg ska godkännas av E-legitimationsnämnden. Möjliga namn-värde-par som kan ingå i objektet som tilldelas uiconfig ovan är: ispassive Anger om dodiscovery skall generera HTML-kod för ett grafiskt gränssnitt för val av legitimeringstjänst, eller om funktionen skall försöka härleda legitimeringstjänst utan att kräva ett val av användaren. Motsvarar parametern med samma namn i [idp-disco]. Om inget värde anges antas false. filter Motsvarar parametern med samma namn som beskrivs i Fler namn-värde-par för uiconfig kan komma att definieras Felhantering Felaktigt utförda anrop, eller misslyckad exekvering, kan leda till att dodiscovery kastar ett JavaScript-exception. Kapitel specificerar vid vilka tillfällen fel kan, och får, rapporteras. Grundkriteriet är att inga aktiviteter som användaren utför får leda till att en exception kastas från funktionen, endast felaktiga anrop eller underliggande systemfel får rapporteras. Exceptions som kastas från dodiscovery skall vara ett JavaScript-objekt innehållande följande namn-värde-par. errorcode description En numerisk felkod. En textuell beskrivning av felet. Denna text skall inte visas för slutanvändaren utan kan användas för intern felrapportering och felsökning.

19 19(47) De felkoder som definieras skall dokumenteras i Anvisningstjänstens API-dokumentation. 3.2 GRAFISKA GRÄNSSNITT Anvisningstjänstens gränssnitt skall utformas enligt följande kriterier: Det ska tydligt framgå att användaren dirigerats till en tjänst som är en del av federationen för Svensk e-legitimation. Gränssnittet skall vara enkelt och snabbt att använda, både för erfarna användare av e-legitimationer och användare som kan behöva förklaringar och hjälp för att utföra sina val. Gränssnittet skall utformas baserat på en användares status och tidigare val. Anvisningstjänsten skall hantera enheter såsom datorer, läsplattor och mobiltelefoner, och måste därför kunna detektera vilken webbläsare och operativsystem en användare använder. Detta kapitel visar ett antal exempel på hur Anvisningstjänstens gränssnitt kan utformas vid olika typfall. Dessa typfall styrs av användarens tidigare val, om användaren redan legitimerat sig under sessionen och utifrån de tillitsnivåer som uppfylls av olika e-legitimationer. Utformningen av användargränssnitt för Anvisningstjänsten skall göras i samverkan med gränssnittsexperter och E-legitimationsnämnden. Terminologi och begrepp som används i gränssnittet skall utformas i enlighet med E-legitimationsnämndens anvisningar. Den information för val av legitimeringslösning som presenteras av Anvisningstjänsten kan aldrig mellanlagras ( cachas ) i webbläsaren då den aldrig är statisk utan är beroende av användarens status och anropande tjänsts krav. I de exempel som illustrerar Anvisningstjänstens grafiska gränssnitt uppmanas användarna välja e-legitimation istället för legitimeringstjänst, vilket vore det korrekta. Detta är ett exempel på att Anvisningstjänstens grafiska gränssnitt skall anpassas så att detta är pedagogiskt för slutanvändarna Gränssnitt vid visning av alla valbara legitimeringstjänster Första gången en användare styrs till Anvisningstjänsten skall samtliga legitimeringstjänster/e-legitimationer som uppfyller e-tjänstens krav 4 vara valbara. I dessa fall har användarens webbläsare inte skickat med cookies som innehåller förvalda eller redan använda e-legitimationer. Bilden nedan illustrerar vilken information som skall exponeras för användaren. Användaren ska tydligt uppfatta att denne dirigerats till Anvisningstjänsten för Svensk e-legitimation. 4 E-tjänstens krav på val av legitimeringstjänst anges i metadata där bland annat begärda tillitsnivåer och kategorier anges.

20 20(47) En lista över tillgängliga e-legitimationer (eller legitimeringstjänster) ska presenteras. Också med ikoner och beskrivningar (vilket läses från federationens metadata). För användare som är osäkra finns stöd. I exemplet nedan kan användaren klicka på Hjälp mig ta reda på vilken e-legitimation jag har. En sådan sida kan söka assistera användaren, till exempel via frågor eller försök att ladda olika insticksprogram för webbläsaren. I de fall där användaren inte önskar fortsätta sin legitimering finns en Avbryt-knapp. I detta fall utförs inget val utan användaren skall skickas tillbaks till e-tjänsten utan vald legitimeringstjänst. I de allra flesta fall önskar förmodligen användaren att valet som görs ska kommas ihåg av Anvisningstjänsten. I de fall där så inte är fallet (t.ex., vid en lånad dator) kan användaren avmarkera att valet ska sparas. Anvisningstjänsten bör också erbjuda ytterligare information kring e-legitimationer (kapitel 3.2.5, Informationsspridning ). - + Anvisningstjänst för Svensk e-legitimation + Hem Ange språk Hjälp Kontakt Anvisningstjänsten för Svensk e-legitimation Ange den e-legitimation du önskar använda för att legitimera dig BankID Telia e-legitimation Även e-legitimationer från SEB och Skatteverket Mobilt BankID Steria e-legitimation Hjälp mig ta reda på vilken e-legitimation jag har... Avbryt Kom ihåg mitt val Vad är en e-legitimation? Skaffa en e-legitimation Har du tekniska problem med din e-legitimation? Figur 5: Exempel på gränssnitt som visar val av samtliga möjliga legitimeringstjänster. En motsvarande sida anpassad för en för en mobil enhet skulle kunna se ut enligt bilden nedan.

21 21(47) Figur 6: Exempel på hur Anvisningstjänstens valsida kan se ut på en mobil enhet. Notera att vissa legitimeringstjänster inte är valbara för mobila enheter, medan andra legitimeringsmetoder enbart existerar för mobila enheter Gränssnitt med föreslaget förval Då en användare en gång gjort ett val av e-legitimation/legitimeringstjänst sparas detta val i en s.k. förvals-cookie (alternativt via Web Storage). Denna information läses av Anvisningstjänsten då denna bygger upp ett gränssnitt. Bilden nedan illustrerar ett scenario där användaren vid ett tidigare tillfälle valt BankID som legitimeringstjänst. Den enda legitimeringstjänst som är direkt synlig för användaren är i detta fall BankID, och om användaren av någon anledning inte önskar använda denna metod kan denne klicka på Gör annat val -knappen och sidan med alla möjliga legitimeringstjänster visas (se kapitel 3.2.1, Gränssnitt vid visning av alla valbara legitimeringstjänster, ovan). Användaren erbjuds också möjligheten att rensa sitt förval genom att klicka på Radera förval -knappen. Detta kan t.ex. vara aktuellt då användaren av misstag valt fel legitimeringstjänst vid ett tidigare tillfälle, eller då denne bytt typ av e-legitimation. Syftet med denna typ av sida är att förenkla, och snabba upp, användarens val av legitimeringstjänst. Eftersom endast ett val visas behöver användaren inte fundera utan kan omedelbart klicka på dess ikon.

22 22(47) - + Anvisningstjänst för Svensk e-legitimation + Hem Ange språk Hjälp Kontakt Anvisningstjänsten för Svensk e-legitimation Förvald e-legitimation BankID Här visas den e-legitimation du tidigare använt. Ändra Radera förval... Gör annat val... För att radera eller ändra ditt förval använd knapparna ovan. Avbryt Vad är en e-legitimation? Skaffa en e-legitimation Har du tekniska problem med din e-legitimation? Figur 7: Gränssnitt som visar tidigare förvald e-legitimation/legitimeringstjänst. En användare kan också ha flera legitimeringsmetoder i sin förvalslista. Detta fall kan uppstå när flera användare delar samma webbläsare. - + Anvisningstjänst för Svensk e-legitimation + Hem Ange språk Hjälp Kontakt Anvisningstjänsten för Svensk e-legitimation Förvalda e-legitimationer BankID Telia e-legitimation Även e-legitimationer från SEB och Skatteverket Här visas de e-legitimationer du tidigare använt. Ändra Radera förval... Gör annat val... Figur 8: Gränssnitt som visar flera förvalda e-legitimationer/legitimeringstjänster. I detta fall måste användaren veta vilken legitimeringstjänst som ska användas, men gränssnittet är ändå förenklat jämfört med en komplett lista som i framtiden kan innehålla ett stort antal legitimeringstjänster.

23 23(47) Gränssnitt vid Single Sign On Det kommer finnas fall då användaren först besöker en e-tjänst och loggar in till denna, för att sedan besöka en annan e-tjänst för att logga in också där. Eftersom varje legitimeringstjänst inom federationen för Svensk e-legitimation erbjuder möjligheter för Single Sign On (SSO) innebär det att användaren inte behöver legitimera sig den andra gången användaren styrs till legitimeringstjänsten (inom samma session). Dock finns inget sätt för den e-tjänst som användaren besöker efter att ha besökt den första att lista ut vilken legitimeringstjänst användaren önskar använda på annat sätt än att styra användaren till Anvisningstjänsten 5. Ovan beskrivna scenario beskrivs i detalj i kapitel 8.2.1, Generell Single Sign On. Varje gång användaren gör ett val hos Anvisningstjänsten sparas detta i en sessions-cookie som har till syfte att tala om för Anvisningstjänsten vilken metod som är aktuell och hjälper till att bygga upp ett gränssnitt som upplyser användaren om att legitimeringstjänsten kan återanvändas. Bilden nedan illustrerar hur ett sådant gränssnitt kan utformas Utom i de fall då den första e-tjänsten förser användaren med en länk till den andra e-tjänsten. I detta fall kan också den första e-tjänsten skicka med legitimeringssättet till den andra som då slipper skicka användaren till Anvisningstjänsten. Detta beskrivs detaljerat i kapitel 8.2.3, E-tjänsten kräver autentisering av användaren Detta avsnitt berör inte Anvisningstjänstens funktion utan är medtaget som en information rörande Single Sign On. Single Sign On mellan e-tjänster inom en federation kan åstadkommas eftersom användaren legitimerar sig hos en legitimeringstjänst (Identity Provider) som betjänar e-tjänsterna med intyg. Respektive e-tjänst vet egentligen inte om en användare har utfört en legitimering eller om en tidigare legitimering återanvändes i samband med att intyget ställdes ut. För de e-tjänster som vill säkerställa att en legitimering utförs i samband med att användaren styrs till legitimeringstjänsten kan SAML-attributet ForceAuthn sättas i autentiseringsbegäran som skickas till legitimeringstjänsten (se [saml2-core]). Förekomsten av detta attribut i begäran talar om för legitimeringstjänsten att den ska kräva en ny legitimering av användaren, oavsett om en giltig SSO-cookie presenteras. Sömlös inloggning mellan e-tjänster.

24 24(47) - + Anvisningstjänst för Svensk e-legitimation + Hem Ange språk Hjälp Kontakt Anvisningstjänsten för Svensk e-legitimation Aktuell e-legitimation BankID Fortsätt Här visas den e-legitimation du redan legitimerat dig med. För att återanvända denna legitimering klicka på "Fortsätt". Legitimera dig med annan e-legitimation För att legitimera dig med en annan e-legitimation än den aktuella, klicka på "Välj annan". Välj annan... Vad är en e-legitimation? Har du tekniska problem med din e-legitimation? Skaffa en e-legitimation Vad är Single Sign On? Figur 9: Gränssnitt när användaren tidigare gjort ett val i samma session. Gränssnittet upplyser användaren om att dennes aktuella legitimeringstjänst är BankID, och har fokus på en Fortsätt -knapp som innebär fortsatt användande av denna metod. Användaren kan också välja att använda en annan e-legitimation genom att välja Välj annan. I detta fall kommer användaren tvingas autentisera sig på nytt eftersom denne hamnar hos en ny legitimeringstjänst Hantering av tillitsnivåer och kategorier Inom federationen för Svensk e-legitimation används olika tillitsnivåer. En e-tjänst kan i federationens metadata ange att den kräver en viss tillitsnivå för legitimeringstjänster som levererar intyg. I federationens metadata anges också av vilken tillitsnivå legitimeringstjänster levererar intyg. Utöver tillitsnivåer kan också legitimeringstjänster tillhöra en eller flera entitetskategorier (EntityCategory), och en e-tjänst kan i sin metadatapost ange att legitimeringstjänster av en viss kategori krävs. De fall som hittills beskrivits berör inte hur Anvisningstjänsten utformar gränssnittet då olika tillitsnivåer och kategorier beaktas. Följande förutsättningar gäller: Från federationens metadata ska Anvisningstjänsten hämta information om respektive legitimeringstjänsts tillitsnivå och entitetskategorier. Information rörande alla e-tjänster inom federationen finns också angiven i federationens metadata. För respektive e-tjänst finns lagrat vilken tillitsnivå och/eller kategori som denna e-tjänst kräver. Också denna information är tillgänglig för Anvisningstjänsten.

25 25(47) Då en användare dirigeras till Anvisningstjänsten indikeras vilken e-tjänst som utfört detta genom en parameter i anropet. Anvisningstjänsten vet alltså vilken e-tjänst den betjänar. Detta innebär följande för Anvisningstjänstens gränssnitt vid de olika typfallen: Vid visning av alla möjliga legitimeringsmetoder filtreras de e-legitimationer/legitimeringstjänster som inte uppfyller anropande e-tjänsts begärda tillitsnivå/kategori bort från listan. Användaren kan alltså bara välja mellan de legitimeringstjänster som är möjliga att använda för aktuell e-tjänst. Vid visning av gränssnittet där användaren har en förvald e-legitimation så kan situationen bli så att den förvalda e-legitimationen inte uppfyller den tillitsnivå/kategori som krävs av anropande e-tjänst. I detta fall måste användaren upplysas om att förvalet inte går att använda och att ett annat val måste göras. Se bild nedan. Analogt med förvalsfallet så kan en e-legitimation som redan använts under sessionen inte vara tillräcklig då användaren försöker autentisera sig mot en annan e-tjänst. Också här bör användaren upplysas om att det aktuella valet inte går att använda och uppmanas välja en annan. - + Anvisningstjänst för svensk e-legitimation + Hem Ange språk Hjälp Kontakt Anvisningstjänsten för svensk e-legitimation Förvald e-legitimation BankID Din förvalda e-legitimation uppfyller inte den tillitsnivå som krävs av den e-tjänst du försöker logga in mot. Var god välj en e-legitimation nedan. Ange den e-legitimation du önskar använda för att legitimera dig Telia e-legitimation Även e-legitimationer från SEB och Skatteverket Steria e-leg Kom ihåg mitt val Avbryt Vad är en e-legitimation? Har du tekniska problem med din e-legitimation? Skaffa en e-legitimation Information om tillitsnivåer Figur 10: Illustration över hur Anvisningstjänsten informerar om icke-användbart förval. Rent generellt bör användare aldrig hamna i situationer där de undrar varför deras e-legitimation inte förekommer i listan av valbara metoder. Att gråa ut ej valbara e-legitimationer kan vara en lösning kring detta problem. Dock skall användbarhetsexperter vara delaktiga i utformandet av gränssnitt.

26 26(47) Informationsspridning Anvisningstjänstens gränssnitt skall också kunna innehålla länkar till information rörande e-legitimationer och dess användande.

27 27(47) 4 FUNKTIONELLA KRAV Anvisningstjänsten skall tillhandahålla de funktioner som beskrivs i kapitel 2, samt implementera de gränssnitt som beskrivs i kapitel 3, med de tillägg och preciseringar som specificeras i detta kapitel. 4.1 ANVISNINGSTJÄNSTENS FUNKTIONER Protokollstöd enligt IdpDisco Uppfyllnad av standard Anvisningstjänsten skall implementera alla delar av [idp-disco] med följande begränsning: Kapitel i [idp-disco] innehåller följande text: If instead an identity provider was not determined, or the discovery service cannot or will not answer, then the discovery service MAY halt processing by displaying an error to the user agent or MAY redirect the user agent back to the requesting service provider. Detta ändras till: Om en legitimeringstjänst inte kan fastställas för användarens val, eller om användaren avbryter sitt val, SKALL användarens webbläsare styras tillbaka till anropande Service Provider utan en vald legitimeringstjänst. Anvisningstjänsten skall alltså inte visa ett felmeddelande i detta fall utan överlåta hanteringen till anropande e-tjänst Stöd för begäran för anvisning utan visning av gränssnitt Då request-parametern ispassive specificeras skall Anvisningstjänsten endast returnera en vald legitimeringstjänst om funktionen för Användarstatus indikerar att användaren har ett aktuellt val för sessionen och att detta val kommer att accepteras av e-tjänsten (baserat på dess krav på tillitsnivåer och kategorier). I alla andra fall skall Anvisningstjänsten returnera ett tomt val. Detta gäller vid både vid anvisning enligt IdPDisco-protokollet och via anvisning som utförs genom anrop till JavaScript för anvisning JavaScript för anvisning Filtrering av valbara legitimeringstjänster Då listan av valbara legitimeringstjänster sammanställs skall alla legitimeringstjänster som uppfyller de kriterier som e-tjänsten ställer presenteras. Filtrering skall ske baserat på e-tjänstens egenskaper från metadata, begärda tillitsnivå och kategorier och matchas mot legitimeringstjänsternas egenskaper från metadata (se vidare kapitel 7,

28 28(47) Informationsmodell ). Logiken för filtrering skall även använda värden som anges med filter-parametern (se Gränssnitt för integration med Anvisningstjänst3.1.2 och 3.1.3). Utöver denna filtrering skall också Anvisningstjänsten kunna hantera filtrering baserat på användaregenskaper såsom typ av webbläsare (t.ex. en mobil enhet) och operativsystem Bakåtkompatibilitet mellan versioner Då förändringar såsom felrättningar och funktionsutökningar utförs i funktionen JavaScript för anvisning skall bakåtkompatibilitet säkerställas. Med bakåtkompatibilitet avses att inga förändringar till API-funktioners utformning genomförs. Det kan också innebära att inga krav får ställas på att en viss version av Anvisningsfeed används med andra ord får JavaScript för anvisning inte förutsätta att dataformatet från Anvisningsfeed är av en viss version. Vid lokalt integrerad anvisning kan en äldre version av data från Anvisningsfeed vara cachad lokalt. Se kapitel 6.1, Uppdateringar av funktionalitet och felrättningar, för vidare krav angående kompatibilitet mellan versioner shantering JavaScript för anvisning skall versionshanteras och tilldelas ett treställigt versionsnummer enligt formatet major.minor.fix, där de olika delarna har följande betydelse: major Huvudversionen. Uppdateras vid större förändringar som gör att bakåtkompatibilitet inte längre gäller. I dessa fall skall också filnamnet på JavaScript för anvisning uppdateras, t.ex. anvisning.js blir anvisningv2.js. minor beskrivande funktion. Uppdateras vid funktionella förändringar som inte bryter bakåtkompatibiliteten. fix Uppdateras vid felrättningar av befintlig funktionalitet. Följande funktion skall exponeras från JavaScript för anvisning: function get() Denna version returnerar en sträng innehållande JavaScriptets versionsnummer enligt ovan beskrivna format Felhantering JavaScript för anvisning skall aldrig kasta JavaScript-exceptions vid aktiviteter som användaren initierar. Den är endast tillåten att rapportera fel genom att kasta exceptions vid följande tillfällen: Felaktigt anrop till dodiscovery, t.ex. att en obligatorisk parameter saknas. Om underliggande Anvisningsfeed inte kan nås. Om anropande e-tjänst saknar obligatoriska element i dess metadata-post.

29 29(47) Anvisningsfeed Format Formatet för de data som exponeras av funktionen för Anvisningsfeed är internt för Anvisningstjänstens funktioner. Dock skall följande gälla: Formatet får inte förändras på ett sådant sätt att befintliga JavaScript för anvisning inte längre kan konsumera anvisningsdata, m.a.o. formatet/definitioner får endast utökas och bakåtkompatibilitet skall gälla. Anvisningsdata skall alltid inkludera en tidsstämpel som talar om när data genererades. Denna tid skall motsvara den tidpunkt när nedladdningen från metadatatjänsten utfördes. Anvisningsdata skall innehålla en versionssträng som avser vilken version av format/schema som gäller för just denna instans. ssträngen skall vara utformad i enlighet med kapitel Formatet skall lämpa sig för HTTP cachning Hämtning och validering av metadata Funktionen för Anvisningsfeed skall periodiskt hämta data från Metadatatjänsten. Denna period skall vara konfigurerbar. Funktionen för Anvisningsfeed skall validera den data som laddas ned från Metadatatjänstens funktion för publicering med avseende på autenticitet. Om en signaturvalidering misslyckas skall funktionen vägra att acceptera dessa data. I detta fall skall loggar produceras och notifieringar ske. Funktionen för Anvisningsfeed skall också validera nedladdat metadata med avseende på dess innehåll. Följande skall kontrolleras: Att alla erforderliga element för legitimeringstjänster och e-tjänster förekommer. Kan alla konsumerade kategorier (Entity Category) tolkas, d.v.s., känner funktionen till hur dessa ska tolkas. Vid valideringsfel rörande innehållet skall loggar produceras och notifieringar ske Hantering av användarstatus Innehåll av användarstatus Följande informationsmängder skall hanteras av funktionen för användarstatus. Förval Aktuellt val Skall innehålla information om användarens förvalda legitimeringstjänst, eller legitimeringstjänster. Detta val gäller mellan sessioner och skall ha en konfigurerbar giltighetstid (t.ex. tre månader). Innehåller information om den legitimeringstjänst som användaren valt i aktuell webbläsarsession. Detta val skall endast vara giltigt så länge sessionen är giltig.

30 30(47) Informationen lagrad för förval och aktuellt val är internt för Anvisningstjänsten eftersom endast JavaScript för anvisning läser och uppdaterar denna information. Formatet får dock inte förändras så att äldre versioner av JavaScriptet inte kan konsumera informationen Skydd mot otillbörlig åtkomst av användarstatus Funktionen för hantering av användarstatus skall konstrueras så att otillbörlig åtkomst av en användares förval och aktuella val hindras. Det ska med andra ord inte vara möjligt för en webbtjänst, som inte förekommer i federationens metadata, att styra användarens webbläsare till funktionen för hantering av användarstatus i syfte att läsa eller uppdatera användarens inställningar Användande av webbläsar-cookies och HTML 5 Web Storage I de fall där användarens webbläsare har stöd för funktionen Web Storage skall denna användas i stället för webbläsar-cookies. I de fall där Webbläsar-cookies används skall dessa märkas som secure och httponly, samt knytas till domännamnet för funktionen för användarstatus. 4.2 ANVISNINGSTJÄNSTENS ANVÄNDARGRÄNSSNITT Anvisningstjänstens skall innefatta grafiska gränssnitt. Utformningen av det grafiska gränssnittet får stor betydelse för förståelsen av vad som förväntas av den som använder Anvisningstjänsten. Utformningen av användargränssnitt för Anvisningstjänsten skall göras enligt E-legitimationsnämndens anvisningar och i samverkan med gränssnittsexperter och E- legitimationsnämnden.

31 31(47) 5 ICKE FUNKTIONELLA KRAV 5.1 SÄKERHETS- OCH TILLGÄNGLIGHETSKRAV Detta avsnitt behandlar specifika säkerhets- och tillgänglighetskrav för Anvisningstjänstens funktioner. Generella säkerhetskrav framgår av bilaga Säkerhetskrav Verifiering av metadata Funktionen för Anvisningsfeed skall använda det certifikat som publiceras av federationens Metadatatjänst för verifiering av den signatur som är applicerad de metadata som laddas ned från Metadatatjänsten. Nedladdning och installation av detta certifikat skall ske som en manuell process vilken inkluderar säkerställande av certifikatets signatur. Denna verifiering skall också inbegripa en kontroll av certifikatets hash-summa vilken finns anslagen på Metadatatjänstens administrativa hemsida Krav på administration och kontroll Anvisningstjänsten ska kunna administreras. Administration av tjänsten skall endast ske av personligt autentiserade administratörer som agerar i enlighet med definierade roller och behörigheter. Roller och dess behörigheter skall dokumenteras Loggar Samtliga säkerhetskänsliga händelser och administrativa åtgärder skall loggas. Särskild behörighet skall krävas för att administrera loggar. Som säkerhetskänsliga händelser räknas bl.a. Uppdatering av JavaScript för anvisning. Installation av certifikat för verifiering av metadata. Förändringar i systemets konfiguration och policyer. Utöver säkerhetskänsliga händelser skall Anvisningstjänstens funktioner logga åtkomst och nedladdningar av anvisningsdata, JavaScript och den centrala tjänstens webbsida för anvisning. Dessa loggar skall innehålla: Tidpunkt, IP-adress, HTTP Referrer, t.ex. e-tjänsts URL.

32 32(47) CSRF, XSS och injektionsbaserade attacker Anvisningstjänsten skall vara skyddad mot CSRF-attacker (Cross Site Request Forgery), XSS (Cross Site Scripting) och injektionsbaserade attacker Verifiering av signerad data Signerad data från extern källa skall verifieras innan den används. Data som signerats hanteras i allmänhet i känsligare kodstycken än icke-signerat data och måste därför verifieras med avseende på ursprung och integritet innan det används Sessions-cookies och local storage Sessions-cookies samt data som lagras i webbläsarens local storage skall inte innehålla några personliga data om användaren som är av integritetskänslig natur. Cookies skall deklareras secure och httponly i den mån det är möjligt. Detta gör att de inte får skickas över osäkra kommunikationskanaler och inte är åtkomliga från exempelvis flash eller JavaScript Administration och konfigurering Konfigureringsmöjligheter ska finnas för att kunna upprätthållas tjänstens funktioner enligt denna tjänstespecifikation. Bland annat ska följande saker kunna konfigureras av administratör: Vilket JavaScript för anvisning som finns tillgängligt för nedladdning. Inställningar för nedladdning av metadata från federationens Metadatatjänst. Dessa inställningar kan bland annat inbegripa periodicitet av nedladdning och byte av certifikat för verifiering av signatur på metadata. Manuell nedladdning av metadata. Behörighetshantering för systemets administratörer. Det ska också vara möjligt att forcera nedladdning av data från Metadatatjänsten. Detta kan vara aktuellt i de fall då felaktig metadata spridits och akuta åtgärder krävs för att rätta till felet. I största möjliga mån skall konfigurering av tjänsten kunna göras utan att det krävs uppdatering av programvara. Detta ställer alltså krav på att tjänsten är konfigurerbar och att inga antaganden om värden och adresser byggs in i JavaScriptet Krypterad kommunikation Kommunikation med Anvisningstjänsten över publika nätverk skall skyddas med kryptering enligt SSL version 3 eller TLS standarden version 1.0 eller högre Tillförlitlig tid Tid i Anvisningstjänsten skall vara baserad på tillförlitlig tid från extern tidskälla. Tidskällan som förser anvisningstjänsten med tid skall vara synkroniserad med UTC via NTP (Network Time Protocol, RFC 5905 [RFC5905]).

33 33(47) Tillgänglighet Anvisningstjänsten skall konstrueras så att dess tillgänglighet motsvarar behoven som ställs för en central tjänst som ska betjäna alla inloggningar som utförs inom federationen för Svensk e-legitimation. 5.2 INTEGRATIONSDOKUMENTATION Leverantören ska ta fram och upprätthålla dokumentation för integration mot Anvisningstjänst. Denna dokumentation ska på ett tydligt sätt redogöra för hur en aktör ska integrera sin tjänst med Anvisningstjänsten. Denna dokumentation skall bland annat omfatta: Allmän beskrivning av Anvisningstjänstens funktion och syfte. Integration enligt [idp-disco]. Integration enligt modellen för lokalt integrerad anvisning. - JavaScript API. - Felhantering. - Exempel på webbsida för anvisning (vilken anropar JavaScript). Generell information om felhantering och felkoder. Exempel och referenskod för anvisning.

34 34(47) 6 KRAV PÅ UTVECKLING 6.1 UPPDATERINGAR AV FUNKTIONALITET OCH FELRÄTTNINGAR Anvisningstjänstens funktionalitet kan komma att förändras på grund av nya eller ändrade krav, till exempel ändrade metadatadefinitioner. Felrättningar skall dokumenteras samt innebära att den tredje delen av versionsnumret ökas (major.minor.fix blir då major.minor.fix+1) Bakåtkompatibla uppdateringar En funktionsuppdatering som bibehåller bakåtkompatibilitet innebär att andra delen av versionsnumret ökas samt att tredje delen nollställs (major.minor.fix blir då major.minor+1.0). Notera att om en uppdatering av en funktion utförs som använder funktionalitet från en annan komponent som i sin tur är bakåtinkompatibel så innebär det att också funktionens uppdatering är bakåtinkompatibel. Ett exempel kan vara att JavaScript för anvisning uppdateras till att läsa ett nytt (icke bakåtkompatibelt) format för Anvisningsfeed Bakåtinkompatibla förändringar Då nya krav på Anvisningstjänstens funktionalitet innebär att bakåtkompatibiliteten inte längre kan upprätthållas skall den centrala tjänsten fortsätta att exponera ut de äldre versionerna av berörda funktionskomponenterna. Detta garanterar att e-tjänster som implementerar lokalt integrerad anvisning kan uppdatera sin integration enligt en planering som stämmer överens med e-tjänstens driftssättningsscheman. En funktionsuppdatering som inte är bakåtkompatibel innebär att första delen av versionsnumret ökas samt övriga delar nollställs (major.minor.fix blir då major+1.0.0). Bilden nedan illustrerar hur flera versioner av Anvisningstjänstens funktioner kan exponeras.

35 35(47) Anvisningsfeed version Anvisningsfeed JavaScript för Anvisning JavaScript för Anvisning Tjänst för Användarstatus Figur 11: Illustration över hur Anvisningstjänsten exponerar ut äldre versioner av funktioner. 6.2 FRAMTIDA METODER FÖR ANVISNING De två metoder för anvisning som specificeras i detta dokument kan komma att utökas med metoder för anvisning som bidrar till en förbättrad användarupplevelse eller som motsvarar nya krav för federationen för Svensk e-legitimation. Grundkriteriet vid introducering av nya metoder för anvisning skall vara att de ska kunna samverka med befintliga metoder, och att ingen e-tjänst skall tvingas till en uppdatering Account Chooser En intressant teknik som studerats av E-legitimationsnämnden är Account Chooser ( I samband med att de funktioner som specificeras i detta dokument designas och implementeras skall tekniker bakom Account Chooser studeras för att möjliggöra en framtida introduktion av Account Chooser som en metod för anvisning för Svensk e-legitimation.

36 36(47) 7 INFORMATIONSMODELL Anvisningstjänsten baseras på de data som publiceras i federationens metadatatjänst. Dokumentet [spec-meta] beskriver federationens metadata i detalj och detta kapitel syftar endast till att förtydliga vilka element som används av Anvisningstjänsten. Då Anvisningstjänsten bygger upp en valsida av möjliga legitimeringstjänster skall denna endast visa de val som användaren kan använda för att autentiseras för den e-tjänst som dirigerat användaren till Anvisningstjänsten. Det är alltså en form av filtrering som sker, och baserat på e-tjänstens behov listas de legitimeringstjänster som matchar dessa krav. En sådan filtrering kan ske på följande kriterier: Den av e-tjänsten begärda/krävda tillitsnivån. E-tjänstens krav på attribut som ska levereras från legitimeringstjänsten. Vilken kategori (EntityCategory) en e-tjänst tillhör. Vilka egenskaper användaren bär på. Dessa kan vara typ av webbläsare, operativsystem, mobil enhet, etc. För att Anvisningstjänsten skall kunna utföra denna filtrering måste den ha tillgång till legitimeringstjänsters och e-tjänsters egenskaper. Dessa egenskaper läser Anvisningstjänsten från federationens metadata. Nedan följer en redogörelse över hur Anvisningstjänsten tolkar respektive metadata-element. 7.1 LEGITIMERINGSTJÄNSTER (IDENTITY PROVIDERS) Som illustrerats i kapitlet 3.2, Grafiska gränssnitt, skall Anvisningstjänsten exponera en lista av legitimeringstjänster från vilken användarna utför sina val. Varje legitimeringstjänst skall listas med ett namn, en logotype och en beskrivning. Alla entiteter inom federationen representeras i metadatat med ett s.k. EntityDescriptorelement. Legitimeringstjänster representeras med en rollbeskrivning (RoleDescriptor) av typen IDPSSODescriptor. Följande information från metadata-representationen av legitimeringstjänsten är av intresse för Anvisningstjänsten: entityid Den unika identiteten för en legitimeringstjänst (IdP). Detta värde är detsamma som skickas till e-tjänsten då användaren valt IdP hos Anvisningstjänsten. Presentationsnamn för tjänsten (DisplayName) Detta namn används i Anvisningstjänstens gränssnitt då valsidor byggs upp. Grafiska element såsom logotyper som används i Anvisningstjänstens gränssnitt. Tillitsnivåer Information om vilka tillitsnivåer som legitimeringstjänsten godkänts för. Denna information används av Anvisningstjänsten då denne skapar vallistor av IdP:er baserat på anropande e-tjänsts begärda nivå.

37 37(47) EntityCategory En entitetskategori är egentligen endast en extension med en unik identifierare. Men innehavet av en kategori har en definierad betydelse. Exempel på hur en kategori kan användas för en identitetsutfärdare är: - Samla ett antal attribut under en profil. Innehav av en sådan kategori innebär att legitimeringstjänsten levererar dessa attribut. - Identifiering av användningsområde. En viss legitimeringstjänst kanske bara stödjer mobila enheter, eller kanske är anpassat för en viss typ av identifiering (legitimering i tjänsten). Anvisningstjänsten använder alltså två olika typer av information från metadatat, information för presentation och egenskaper för legitimeringstjänster för att kunna presentera matchande IdP:er för den e-tjänst som begär anvisning. Med matchande IdP:er avses att endast de IdP:er som motsvarar de krav som e-tjänsten ställer på identifieringen. 7.2 E-TJÄNSTER (SERVICE PROVIDERS) De aktörer inom federationen som är brukare av Anvisningstjänsten är alla e-tjänster (Service Providers), vilka dirigerar sina användare till Anvisningstjänsten för att utföra val av önskad legitimeringstjänst. Anvisningstjänstens uppgift är att baserat på e-tjänstens krav erbjuda användaren en lista av legitimeringstjänster som motsvarar e-tjänstens krav. De krav som e- tjänster specificerar återfinns i federationens metadata. Följande information från metadata-representationen av legitimeringstjänster är av intresse för Anvisningstjänsten: entityid Den unika identiteten för en e-tjänst (Service Provider). Detta värde är detsamma som skickas i anropet till Anvisningstjänsten då e-tjänsten styr användaren dit. RequestedAttributes En lista över de attribut en e-tjänst önskar kunna konsumera från identitetsintyget som ställs ut från den av användaren valda legitimeringstjänsten. EntityCategory Entitetskategorier används av e-tjänster för att identifiera att en tjänst tillhör en kategori av tjänster med samma krav. Dessa krav kan utgöras av gemensamma krav på attribut och/eller tillitsnivåer. DiscoveryResponse En eller fler adresser som definierar godkända returadresser för e-tjänsten då anvisning enligt [idp-disco] utförs. Då Anvisningstjänsten sammanställer en lista över valbara legitimeringstjänster för inloggning mot en e-tjänst söker den matcha de krav som är angivna i e-tjänstens metadata mot de egenskaper som listas för federationens legitimeringstjänster.

38 38(47) 8 ANVÄNDNINGSFALL OCH SEKVENSDIAGRAM Detta kapitel syftar till att visa Anvisningstjänstens roll inom federationen för Svensk e- legitimation. För tydlighetens skull illustrerar vissa av sekvensdiagrammen fullständiga flöden. 8.1 ANVÄNDARE AUTENTISERAS MOT E-TJÄNST Att en användare loggar in mot en e-tjänst utan att tidigare autentiserats under sessionen får antas vara det mest förekommande fallet. I detta fall öppnar användaren sin webbläsare, anger adressen till önskad e-tjänst och loggar sedan in mot denna e-tjänst (till exempel går in på Mina sidor ). Sekvensdiagrammet börjar efter användaren klickat på Logga in.

39 39(47) Användare (webbläsare) e-tjänst (SP) Legitimeringstjänst Identitetsutfärdare (IdP) Anvisningstjänst (DS) 1 Begäran om anvisning genom HTTP redirect till DS 2 3 Användaren väljer e-legitimation (IdP) DS skriver DS-SSO-cookie innehållande vald e-legitimation/idp för sessionen samt eventuell skapande/uppdatering av förvals-cookie Resultat av anvisning returneras till SP genom HTTP redirect 4 HTTP redirect till angiven IdP för autentisering (AuthnRequest) 5 6 Användaren autentiseras med given e-legitmation 7 IdP skriver IdP-specifik SSO-cookie HTTP POST meddelande innehållande Response-meddelande för autentiseringen (Identitetsintyg) 8 e-tjänsten loggar in användaren 9 Figur 12: Sekvensdiagram som beskriver ett flöde där användaren loggar in mot en e-tjänst för första gången under sessionen. 1. Det första steget för en e-tjänst vidtar då en användare ska loggas in är att styra denne till Anvisningstjänsten så att användaren kan ange med vilken e-legitimation denne önskar autentisera sig med, eller mer korrekt, hos vilken legitimeringstjänst användaren önskar legitimera sig. 2. Anvisningstjänsten genererar ett gränssnitt för val av legitimeringstjänst. Hur detta gränssnitt genereras är beroende av användarens status (om ett förval existerar) och e-tjänstens krav. Ur detta gränssnitt utför användaren sitt val. 3. Innan Anvisningstjänsten dirigerar tillbaka användaren till anropande e-tjänst lagras användarens val i webbläsaren. Två typer av status kan lagras; det aktuella valet och det eventuella förval användaren gjorde. 4. Anvisningstjänsten dirigerar tillbaka användaren till e-tjänsten. Detta anrop innehåller den valda legitimeringstjänsten (IdP). Adressen som Anvisningstjänsten ska använda då omdirigeringen sker läses från federationens metadata, eller från en

40 40(47) parameter (return) som skickas med i anropet till Anvisningstjänsten (se kapitel i [idp-disco]). 5. I detta läge har e-tjänsten fått vetskap om vilken legitimeringstjänst (IdP) som ska hantera legitimeringen och utställandet av identitetsintyget för användaren och användaren dirigeras därmed till denna tjänst. Notera att e-tjänsten då den mottagit användarens val av IdP sparar denna i användarens session hos e-tjänsten för möjligt senare användande. 6. Användaren interagerar med legitimeringstjänsten och legitimerar sig enligt den metod som stöds av den aktuella tjänsten. 7. Vid lyckad autentisering skriver legitimeringstjänsten en SSO-cookie specifik för den aktuella tjänsten. Denna cookie (som har en begränsad livslängd) talar om att användaren har autentiserats hos tjänsten och är ett verktyg för att åstadkomma SSO (om användaren skickas till samma identitetsutfärdare flera gånger under denna webbsession). 8. Legitimeringstjänsten ställer samman ett identitetsintyg (Assertion) gällande användaren och postar detta tillbaka till e-tjänsten. 9. Då e-tjänsten mottar identitetsintyget och har verifierat dess äkthet kan slutligen användaren loggas in till Mina sidor hos e-tjänsten Användare avbryter val av legitimeringstjänst En användare som styrs till anvisningstjänsten kommer alltid att ha möjligheten att avbryta val av legitimeringstjänst. Detta kan bero på att användaren innehar en e-legitimation som går att använda eller helt enkelt att användaren önskar avbryta sin pågående inloggning. För alla situationer där inget val kan utföras, även felfall, styrs användaren tillbaks till e-tjänsten utan parametern som indikerar vald legitimeringstjänst. E-tjänsten känner alltså inte till anledningen till att inget val utfördes utan bör visa en generell informations- eller feltext. Användare (webbläsare) e-tjänst (SP) Anvisningstjänst (DS) 1 Användaren loggar in mot e-tjänsten. 2 Begäran om anvisning genom HTTP redirect till DS. 3 4 DS visar gränssnitt för användaren. Användaren avbryter valet. 5 DS styr tillbaka användaren, men utan vald IdP. 6 E-tjänsten visar felmeddelande. Figur 13: Sekvensdiagram som beskriver ett flöde där användaren avbryter anvisning. 1. Användaren loggar in mot e-tjänsten.

41 41(47) 2. E-tjänsten styr användaren till Anvisningstjänsten för val av legitimeringstjänst. 3. Anvisningstjänsten genererar ett gränssnitt för val av legitimeringstjänst baserat på e- tjänstens krav och användarens status (förval och aktuellt val). 4. Användaren avbryter valet genom att klicka på Avbryt. 5. Anvisningstjänsten styr användaren tillbaka till e-tjänsten. Denna HTTP redirect innehåller ingen parameter för vald legitimeringstjänst. 6. E-tjänsten tar emot anropet och eftersom vald legitimeringstjänst saknas avbryts inloggningen och ett felmeddelande visas. Notera: I detta fall modifierar Anvisningstjänsten inte användarens status avseende förval eller aktuellt val. 8.2 ANVISNINGSTJÄNSTENS ROLL VID SINGLE SIGN ON Då en användare legitimerar sig lyckosamt hos en legitimeringstjänst, ställer legitimeringstjänsten ut ett identitetsintyg gällande användaren åt anropande e-tjänst. Utöver detta intyg skrivs också en tidsbegränsad sessionsbaserad Single Sign On-cookie 6 till webbläsaren som bevisar att användaren utfört en lyckosam legitimering vid en given tidpunkt. Denna information kan användas senare i sessionen för Single Sign On-inloggningar till andra e-tjänster inom federationen. Detta stycke beskriver Anvisningstjänstens roll vid Single Sign On Generell Single Sign On Detta användningsfall tar vid efter att användaren lyckosamt autentiserat sig och loggat in mot en e-tjänst (se 8.1, Användare autentiseras mot e-tjänst ). Inom samma webbläsarsession besöker användaren nu en ny e-tjänst som också är del av federationen för Svensk e- legitimation. 6 Alternativt används Web Storage i stället för webbläsar-cookies.

42 42(47) Användare (webbläsare) e-tjänst (SP) Legitimeringstjänst (IdP) Anvisningstjänst (DS) 1 Begäran av åtkomst (inloggning) 2 Begäran om anvisning genom HTTP redirect till Anvisningstjänsten. Innehåller sessions-cookie. 3 Användaren bekräftar tidigare val av e-legitimation (IdP) 4 Resultat av anvisning returneras till SP genom HTTP redirect 5 HTTP redirect till angiven IdP för autentisering (AuthnRequest). SSO-cookie tidigare utställd av IdP:n skickas med. Ingen autentisering sker - SSO! 6 HTTP POST meddelande innehållande Identitetsintyg e-tjänsten loggar in användaren 7 Figur 14: Sekvensdiagram vid Single Sign On-inloggning. 1. Användaren begär åtkomst (loggar in) mot e-tjänsten. I detta skede har användaren redan autentiserats och är, eller har varit, inloggad mot en annan e-tjänst inom federationen. 2. E-tjänsten styr användaren till Anvisningstjänsten för val av legitimeringstjänst. I detta anrop skickas den cookie som innehåller användarens aktuella val (alternativt läser Anvisningstjänsten från webbläsarens Local Storage). 3. Användaren bekräftar det val som visas och upplyses också om att e-legitimationen återanvänds, se kapitel 3.2.3, Gränssnitt vid Single Sign On. 4. Anvisningstjänsten dirigerar tillbaka användaren till e-tjänsten. Detta anrop innehåller den valda legitimeringstjänsten (IdP). 5. Då e-tjänsten fått vetskap om vilken legitimeringstjänst som ska hantera legitimeringen och utställandet av identitetsintyget för användaren dirigeras användaren till denna tjänst. I detta anrop skickas också den SSO-cookie som ställdes ut av legitimeringstjänsten i samband med att användaren autentiserades (alternativt används Local Storage). 6. Eftersom användaren presenterar en giltig SSO-cookie kräver inte legitimeringstjänsten att användaren autentiserar sig utan ett intyg skapas och postas till e-tjänsten.

43 43(47) 7. E-tjänsten validerar nu intyget och loggar in användaren. Ovanstående sekvensdiagram illustrerar hur Anvisningstjänstens genererar ett gränssnitt även då användaren redan utfört ett val för aktuell session. Detta kan tyckas onödigt, men beakta följande: Vi kan inte anta att användaren verkligen önskar återanvända sin redan valda e-legitimation. Det är möjligt att användaren har olika e-legitimationer som denne använder för olika typer av tjänster. E-tjänsten till vilken användaren loggar in mot kanske inte tillåter Single Sign Oninloggningar. Av pedagogiska och användbarhetsmässiga skäl vill man informera användaren om att denna återanvänder sin valda e-legitimation (och i förlängningen också, återanvänder den redan utförda autentiseringen). Anta att användaren i ett första skede väljer en legitimeringstjänst vilken användaren inte kan använda, t.ex. ett felval eller en missuppfattning. Om Anvisningstjänsten nästa gång användaren uppmanades göra ett val gjorde ett automatval åt användaren skulle användaren vara fast i sitt felaktiga val, och den enda möjligheten att upphäva detta vore att stänga hela webbläsaren. Dock finns möjligheter för e-tjänster som önskar erbjuda en Single Sign On-inloggning utan Anvisningstjänstens (visuella) inblandning. Detta beskrivs i kapitlen och nedan Single Sign On med passiv Anvisningstjänst En e-tjänst som vill erbjuda Single Sign On utan Anvisningstjänstens inblandning kan åstadkomma detta genom att tilldela parametern ispassive värdet true (se ) då användarens webbläsare styrs till Anvisningstjänsten. Denna parameter talar om för Anvisningstjänsten att den skall försöka härleda vilken legitimeringstjänst användaren skall använda utan att visa ett visuellt gränssnitt. I fallet då användaren har ett aktuellt val för sessionen säger de funktionella krav som ställs på Anvisningstjänsten ( ) att detta val kan returneras till e-tjänsten utan att användaren utför ett val.

44 44(47) Användare (webbläsare) e-tjänst (SP) Legitimeringstjänst (IdP) Anvisningstjänst (DS) 1 Begäran av åtkomst (inloggning) 2 Begäran om anvisning genom HTTP redirect till Anvisningstjänsten. Parametern ispassive är satt. Innehåller sessions-cookie. Anvisningstjänsten läser aktuellt val. 3 Aktuellt val returneras till SP genom HTTP redirect 4 HTTP redirect till angiven IdP för autentisering (AuthnRequest). SSO-cookie tidigare utställd av IdP:n skickas med. Ingen autentisering sker - SSO! 5 HTTP POST meddelande innehållande Identitetsintyg 6 e-tjänsten loggar in användaren Figur 15: Sekvensdiagram för anvisning vid SSO då Anvisningstjänsten är passiv. Ovanstående sekvensdiagram är detsamma som i det generella SSO-fallet med skillnaden att Anvisningstjänsten inte exponerar ett gränssnitt för användaren eftersom e-tjänsten specificerar ispassive. Notera: E-tjänster som använder sig av ispassive-flaggan skall vara medvetna om att responsen från Anvisningstjänsten kommer att vara tom i de fall då användaren inte har ett aktuellt val. I dessa fall skall användaren styras till Anvisningstjänsten igen, och denna gång utan ispassive-flaggan satt E-tjänsten kräver autentisering av användaren Detta avsnitt berör inte Anvisningstjänstens funktion utan är medtaget som en information rörande Single Sign On. Single Sign On mellan e-tjänster inom en federation kan åstadkommas eftersom användaren legitimerar sig hos en legitimeringstjänst (Identity Provider) som betjänar e-tjänsterna med intyg. Respektive e-tjänst vet egentligen inte om en användare har utfört en legitimering eller om en tidigare legitimering återanvändes i samband med att intyget ställdes ut. För de e-tjänster som vill säkerställa att en legitimering utförs i samband med att användaren styrs till

45 45(47) legitimeringstjänsten kan SAML-attributet ForceAuthn sättas i autentiseringsbegäran som skickas till legitimeringstjänsten (se [saml2-core]). Förekomsten av detta attribut i begäran talar om för legitimeringstjänsten att den ska kräva en ny legitimering av användaren, oavsett om en giltig SSO-cookie presenteras Sömlös inloggning mellan e-tjänster Detta avsnitt berör inte Anvisningstjänstens funktion utan är medtaget som en information rörande Single Sign On. Ett annat sätt för e-tjänster att undvika Anvisningstjänstens inblandning är att implementera en s.k. sömlös inloggning sinsemellan. Grundtanken med sömlös inloggning är att en e-tjänst erbjuder en länk till en annan e-tjänst. I denna länk bakas information angående den valda legitimeringsmetoden in vilket gör att den mottagande e-tjänsten kan extrahera användarens valda legitimeringstjänst från parametrarna ur anropet, och behöver därmed inte styra användaren till Anvisningstjänsten.

46 46(47) 9 REFERENSER 9.1 NORMATIVA REFERENSER Normativa referenser innehåller information som utgör krav för att kunna uppfylla specificerade krav i tjänstespecifikationen. Kraven i denna tjänstespecifikation styr vilka delar i dessa normativa dokument som måste tillämpas. Om ett krav i denna tjänstespecifikation i något avseende avviker från något av nedanstående normativa dokument, är kravet i denna tjänstespecifikation överordnat. Referens [saml2-prof] [idp-disco] [saml-metadata] [saml-meta-mdui] [saml-egov20] [saml2-int] [saml2-core] [entity-category] [RFC5905] Dokument Oasis Standard, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, March 2005, ( OASIS Committee Specification, Identity Provider Discovery Service Protocol and Profile, March 2008, ( OASIS Standard, Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, March 2005, ( OASIS Draft, SAML V2.0 Metadata Extensions for Login and Discovery User Interface 1.0, September 2010, ( Kantara Initiative egovernment Implementation Profile of SAML 2.0, 2.0, June 11, 2010, ( 355/kantara-report-egov-saml2-profile-2.0.pdf) Kantara Initiative, SAML 2.0 INT SSO Deployment Profile, version 0.1, ( 836/FIWG_SAML2.0_INT_SSO+Deployment+Profile_v0.1.pdf) OASIS Standard, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, March 2005, ( The Entity Category SAML Entity Metadata Attribute Type, March 2012, ( Internet Engineering Task Force (IETF) RFC, Network Time Protocol 4: Protocol and Algorithms Specification, (

47 47(47) [sv-eid-prof] Deployment Profile for the Swedish eid Framework (under utveckling)