sou · H9B362 · 2021-06-29 00:00:00 — En myndighet som vill erbjuda möjligheten att logga in med e- legitimation kan anskaffa tjänster för elektronisk identifiering på olika sätt, exempelvis egen upphandling eller avrop från ramavtal. I Kammarkollegiets ramavtalsområden inom Programvaror och Tjänster finns t.ex. krav på att tjänster inom elektronisk identifiering ska kunna levereras.27 Avtal kan ingås direkt med e-legitimationsutfärdare eller ingås med en aktör som fungerar som mellanhand och erbjuder en tjänst som gör det möjligt för användarna att logga in med e-legitimationer från olika utfärdare (se mer om detta i avsnitt 3.12). Ett annat alternativ för aktörer inom förvaltningen är att använda sig av valfrihetssystem för e-legitimationer. Förfarandet regleras i lagen (2013:311) om valfrihetssystem i fråga om tjänster för elektronisk identifiering. Enligt 2 § avses med valfrihetssystem ett förfarande där den enskilde har rätt att välja den leverantör som ska utföra tjänsten och som en upphandlande myndighet har godkänt och tecknat avtal med. Det finns två valfrihetssystem för e-legitimationer: Valfrihetssystem 2017 respektive 2018. Dessa administreras av DIGG som också tillhandahåller anslutningsavtal mellan leverantör av elektronisk identifiering direkt kopplad till vald e-legitimation och förlitande part. En myndighet som vill erbjuda sina användare att använda olika e-legitimationer är förlitande part och kan ansluta sig till valfrihetssystemen genom att ingå respektive avtal. 27Kammarkollegiet, Vägledning för avrop av tjänster för elektronisk identifiering och elektronisk underskrift från ramavtalsområden inom Programvaror och Tjänster 2019 (Version 2.0), , s. 4. 52 aktörer ansluta till ett eller båda valfrihetssystemen i egenskap av förlitande parter.28 I en nyligen lämnad promemoria föreslås att valfrihetssystemen ska ersättas av ett auktorisationssystem.29 I promemorian föreslås också att statliga myndigheter som har behov av tjänster för elektronisk identifiering ska använda de tjänster som tillhandahålls genom auktorisationssystemet. Konsekvensen av det är enligt promemorian att statliga myndigheter inte kan välja andra anskaffningsformer, exempelvis egen upphandling av tjänsterna eller avrop på ramavtal.30 6.6Federationer för identifiering och behörigheter Vad som avses med en identitetsfederation framgår av avsnitt 3.12. Syftet med federationerna är att de förlitande parter som tillhandahåller e-tjänster ska kunna lita på identiteten och i förekommande fall behörigheten hos användaren av en tjänst. Det finns en generell federation samt flera sektorsvisa och privata federationer i . Den generella federationen är Connect medan sektorspecifika är t.ex. Sambi, SWAMID och Skolfederation.31 och är exempel på organisationer som har egna federationer och det förefaller bli vanligare med egna organisations- eller koncerngemensamma federationer. En identitetsfederation består av flera delar. Utöver att någon ska ansvara för själva federationen behövs det identitetsintygsutfärdare med tillgång till legitimeringsfunktion som sköter databaser med användaruppgifter och låter användare identifiera sig. Det behövs även förlitande parter som tillhandahåller e-tjänster (se figur 6.1). Det krävs därtill en anvisningstjänst för att hantera flera olika identitetsleverantörer och hjälpa användaren att hitta sin e-legitimation via leverantören eller sin organisation. 28www.digg.se/digital-identitet/e-legitimering/offentlig-aktor/nationell-e- legitimering#anslutna_organisationer (hämtad ). 29Promemoria, Auktorisationssystem för elektronisk identifiering och för digital post. Namnet anges därför inte i bestämd form. Figur 6.1 Generaliserad översikt av en federationslösning Regelverk: Policys, tillsyn, incidenthantering m.m. Källa: , Förstudierapport och behörighetsfederation för eHälsa, . Reglerna i en federation omfattar vanligen kraven på identifiering men även tekniska- och organisatoriska säkerhetsåtgärder som deltagare behöver vidta. Normalt finns olika tillitsnivåer som ställer olika långtgående krav på en identitetsintygsutfärdare. Identitetsfederationer baseras vanligtvis på internationella standarder och används i universitetsvärlden och inom det svenska skolväsendet men även för privata e-legitimationer. Det finns även i en federation överenskommelser eller avtal mellan identitetsleverantörer och förlitande parter om vad som ska skickas med i identitetsintyget och i förekommande fall andra attribut. I metadataregistret för federationen finns uppgifter om de olika identitetsintygsutgivare som finns inom federationen och uppgifter om bl.a. de servercertifikat och stämplar de använder för att skydda överföringen och stämpla identitetsintygen. Det medför att en förlitande part kan känna igen tillhandahållaren av identitetsintyget och vice versa. Connect är statens nationella identitetsfederation för elektronisk identifiering och inkluderar även landsnod för gränsöverskridande åtkomst med stöd av eIDAS-förordningen (se mer om detta i avsnitt 4.2). DIGG ansvarar för och driver identitetsfederationen. Connect består av: •Ett tekniskt ramverk. •Metadata och kontaktinformation om alla anslutna aktörer. •Avtal som knyter ihop förlitande parter med e-legitimations- utfärdare och den svenska eIDAS-noden. En offentlig aktör som tillhandahåller en e-tjänst kan använda Connect både för uppkoppling mot svenska och utländska e-legiti- mationer. Det sker genom att denne tecknar avtal om Connect med DIGG och eventuellt även valfrihetssystem 2017 E-legitimering. Det tekniska ramverket för Connect omfattar specifikationer för hur metadata ska användas och hur identitetsintyg ska begäras och levereras. Det tekniska ramverket utgår bl.a. från . Sambi (Samverkan för behörighet och identitet inom hälsa, vård och omsorg) är tänkt att fungera som en nationell mötesplats för säker e- hälsa och länka samman e-tjänster och användarorganisationer.32 Sambi drivs av och är öppen för alla aktörer inom vård-, hälso- och omsorgssektorn. ansvarar för tillitsregler, tillitsgranskning, anslutningsavtal, tekniska krav, metadataregiser och hantering av s.k. Sambiombud. Sambi används för inloggning över organisationsgränser av personal inom vård, omsorg och apotek. Sambi består av gemensamma regler och avtal och bygger på att deltagande organisationers säkerhetsarbete har granskats. Sambi hänvisar till de e-legitimationer som har godkänts av DIGG. Det är obligatoriskt att ange e-legitimationens tillitsnivå från den identifiering av användaren som närmast föregått användarorganisationen (vårdgivarens) utställande av identitetsintyg.33 Inom Sambi ställs krav på användarorganisationer gällande deras säkerhetsarbete som ska vara anpassat efter risker och säkerhetsbehov. Sambi erbjuder olika sätt för mindre aktörer att ansluta sig till federationen, t.ex. genom Sambiombud som paketerar teknik och administration i 32www.sambi.se (hämtad ). 33www.sambi.se/wp-content/uploads/2018/12/Sambi-Bilaga-2-Tekniska-krav-v1.52.pdf (hämtad ). en tjänst som underlättar för användare att leva upp till kraven i tillitsramverket.34 () är en identitetsfederation där de flesta lärosätena, forskningsnära och utbildningsnära myndigheter samt statliga muséer i ingår.35 SWAMID drivs av Sunet36. I SWAMID finns kvalitetssäkrad inloggning av anställda, studenter och andra associerade i medlemsorganisationerna i . Det är också möjligt för en tjänsteägare att tillgängliggöra tjänsten även utanför genom interfederationen eduGAIN, t.ex. i resten av , , och . Syftet med identitetsfederationen är att sänka kostnaden för att hantera digitala identiteter inom och mellan organisationer. SWAMID:s policy och teknologi används för att etablera säkra och kontrollerbara associationer och transaktioner mellan identiteter och system. Medlemskap krävs för identitetsutfärdare och sådana organisationer som har användare som ska logga in i tjänster. För att bli godkänd ska organisationen visa att den uppfyller god praxis när det gäller identitetshantering. SWAMID använder tre olika tillitsnivåer med definierade krav avseende profilen och granskningen av de olika nivåerna:37 –SWAMID Identity Level 1 – för personer och kallas för obekräftad användare. Användaren själv uppger informationen och ansvarar för denna. –SWAMID Identity Level 2 – medlemsorganisationen vet vem det är och kallas för bekräftad användare. Lärosätet vet vem personen är och lärosätet ansvarar för kontot. SWAMID granskar tillitsdeklarationen. 34www.sambi.se/sambiombud/ (hämtad ). 35https://wiki.sunet.se/display/SWAMID (hämtad ). 36www.sunet.se/services/identifiering/swamid (hämtad ). 37https://wiki.sunet.se/display/SWAMID/SWAMID+Policy#SWAMIDPolicy- Tillitsprofiler (hämtad ). –SWAMID Identity Level 3 – högre krav på att lärosätet vet vem personen är, kallas även verifierad användare. All inloggning sker som flerfaktorsautentisering. SWAMID granskar tillitsdeklarationen med hjälp av ett granskningsprotokoll. Syftet med är att underlätta svensk utbildningssektors användning av digitala tjänster och läromedel. Det görs genom att tillhandahålla en infrastruktur för inloggning som underlättar åtkomst till tjänster för elever och lärare ute på skolor runtom i landet. Tjänsten är en identitetsfederation, där förlitande parter litar på skolhuvudmäns användaridentifiering. Med får elever och lärare en standardiserad inloggningslösning och kan nå alla tjänsterna i skolmiljön, både de som finns i skolan och de som skolan abonnerar på via internet. Inom ramen för erbjuds också en lösning för att skapa, ändra och ta bort skolans användare hos federationens tjänsteleverantörer på ett standardiserat vis, s.k. federerad provisionering. är federationsoperatör för och för standarder har inom ramen för TK 450/AG 4 tagit fram de attribut som skickas i identitetsintygen. är öppen för: •Skolhuvudman för någon av de skolformer som räknas upp i skollagen (2010:800) och som genom det allmänna eller det privata anordnar utbildning, eller •utbildningsanordnare som bedriver utbildningar vid vilka studiestöd kan lämnas enligt studiestödsförordningen (2000:655) och dess tillhörande bilaga. •En svensk myndighet som arbetar med skolan. •En leverantör av e-tjänster som har rekommenderats av en skolhuvudman att bli medlem i . tillämpas tillitsnivåerna ”Bas” och ”2FA” inom . Målsättningen är att alla medlemmar ska kunna hantera en tillitsnivå motsvarande 2FA. –Bas – godkänd medlem i : Bas medför inga andra krav än de som följer med medlemskapet i . –2FA – tvåfaktorsautentisering: Den skyddsklass för e-legitima- tioner och utställande av identitetsintyg vars grad av skydd motsvarar IMY:s krav på stark autentisering, då it-systemet är tillgängligt via internet och innehåller integritetskänsliga uppgifter. Ingen granskning av kravets efterlevnad görs av , utan detta åvilar skolhuvudmannen. Valet av tillitsnivå styrs av e-tjänstens krav och baseras på de risker och skada som en felaktig identifiering kan medföra avseende användarens säkerhet, obehag eller oro samt tjänsteleverantörens renommé och rykte. Även ekonomisk skada och legala krav beaktas. En interfederation är en överenskommelse mellan två eller flera federationsoperatörer som ingår i ett sammansluta federationerna. äger rum när en användare från en federation får åtkomst till en tjänst som är registrerad i en annan federation.38 har tagit fram interfederationen FIDUS, som ansluter och , främst för användning i samband med digitala nationella prov. Fler federationer kan anslutas . hantering, Utbildning och Skola.39 38Enligt ordlista från konferensen tekniksnack om digitala nationella prov, /download/18.6b138470170af6ce9141f6/1583847378476/Ordlista%20Sko lverkets%20tekniksnack.pdf (hämtad ). Men även ”hos utbildning och skola” förekommer, /nyhetsbrev/2018_04/ (hämtad ). 39www.skolverket.se/download/18.7f8c152b177d982455e1d17/1617176591317/VT2020- Fragestund-for-tekniker.pdf (hämtad ). 6.6.7Tekniska lösningar för federerade identiteter och behörigheter Det finns flera olika standarder som kan användas i identitetsfederationer. Användningen baseras dock på någon form av identitetsintyg från identitetsintygsutfärdare40. Standarderna har likartade byggstenar men är formaterade på olika sätt och använder olika tekniska lösningar. Security Assertion Markup Language (SAML) är en öppen standard för federerad autentisering.41 SAML version 2.0 används bl.a. av Connect, , Sambi och SWAMID. Det sker genom att skicka identitetsintyg från identitetsintygsutfärdare (förkortas IdP inom SAML) till förlitande parter (förkortas SP inom SAML). Det möjliggör säker kommunikation mellan användare och e-tjänster. SAML använder XML för kommunikationen mellan IdP och SP.42 Det sker genom s.k. SAML assertions (identitetsintyg), en sorts XML-dokument som skickas till förlitande part. SAML är en standard som inte reglerar implementationen av aktuella identitetsfederationer på detaljnivå. För att kunna federera med SAML på ett effektivt sätt behöver ett antal vägval göras och dokumenteras. Den tekniska dokumentationen utgörs av dessa vägval och närmare reglering av hur standarden används, exempelvis i det tekniska ramverket för Connect.43 Identitetsfederering via SAML är baserat på att identitetsintygsgivare och förlitande parter litar på varandra och därmed kan verifiera de underskrifter och stämplar som används i SAML-kommu- nikationen. Rent tekniskt baseras denna tillit på att respektive parter litar på varandras URL:er och tillhörande servercertifikat. Tillitsprocessen automatiseras via användning av SAML metadata. Specifikationen av metadata är framtagen av OASIS för att underlätta administration av större federationer. Federationen definieras då av 40Även kallade IdP eller identity provider i SAML och OpenID provider i OPenIDconnect. 41Standardiserad av OASIS (for the Advancement of Structured Information Standards). 42Förkortningen XML står för Extensible Markup Language. XML är en teknisk standard för strukturmärkning av textbaserade elektroniska dokument. 43https:///tekniskt-ramverk.html (hämtad ). ett register i XML-format som är stämplat med federationsoperatörens certifikat. Filen innehåller information om identitetsfederationens medlemmar inklusive deras servercertifikat. Eftersom metadatafilen är stämplad av federationsoperatören räcker det med att jämföra ett servercertifikat med dess motsvarighet i metadatat. En infrastruktur baserad på ett centralt federationsregister förutsätter att registret uppdateras kontinuerligt samt att federationsmedlemmarna alltid använder den senaste versionen av filen. För att kunna använda metadata krävs en central aggregator som kontinuerligt hämtar lokal metadata från federationsdeltagarna och uppdaterar och stämplar federationsregistret. I identitetsfederationer har e-tjänster och motsvarande förlitande parter rollen som SP medan legitimeringstjänster som utfärdar identitetsintyg intar rollen som IdP och därmed är den som autentiserar användaren, oavsett mot vilken e-tjänst som användaren legitimerar sig. För de fall där e-tjänsten behöver mer information om användaren t ex. uppgift om behörighet, kan en fråga ställas till en attributtjänst (Attribute Authority [AA]), inom federationen, om sådan relevant attributtjänst finns, eller annars med stöd av OAuth 2.0 utanför federationen. Genom en attributsförfrågan kan e-tjänsten erhålla nödvändig kompletterande information för att kunna auktorisera användaren och ge tillgång till e-tjänsten eller motsvarande. OAuth 2.0 är ett standardiserat protokoll för auktorisation. Protokollet utvecklas och förvaltas av en arbetsgrupp inom IETF.44 Syftet med protokollet är att underlätta användningen av behörighetsinformation för tredje part, dvs. användare i mobilappar, system m.m. OAuth 2.0 är ett ramverk som kontrollerar auktorisation till skyddade resurser. Protokollet kan använda resurser från en server för användarens räkning utan att användaren behöver autentisera sig. Protokollet gör det genom att tillåta att identitetsintygsutfärdare skickar vidare attributsintyg till tredje part när användaren godtar det. Det används bl.a. i mobilappar som t.ex. Facebook när appen frågar om tillstånd att använda mobiltelefonens kontakter för att ansluta till de 44Av , IETF, ramverket i RFC 6749. av kontakterna som har Facebook. Det finns fyra roller enligt OAuth 2.0: Resursägaren är användaren som tillåter att en applikation får tillgång till dennes uppgifter. Klienten är applikationen som vill använda användarens uppgifter, t.ex. en e-tjänst. Innan den gör det måste den auktoriseras av användaren och auktorisationen ska valideras via ett API. Resursservern lagrar användarens konto och auktorisationsservern verifierar användarens identitet. OpenID Connect är ett identitetslager på OAuth 2.0-protokollet.45 OpenID Connect började som proprietära lösningar från bl.a. Google som sedan har blivit industristandard.46 Det är den standard som används när inloggning via exempelvis Google, Microsoft eller Facebook används för att identifiera sig mot en annan aktörs tjänst, t.ex. forum eller e-handelswebbplats. OpenID Connect bygger på OAuth 2.0 för att tillhandahålla identifieringstjänster. OpenID Connect har ett antal tillägg till OAuth 2.0-protokollet genom ett ID-token, vilket är ett säkerhetstoken i formen av ett JSON Web Token (JWT), som gör att klienten kan verifiera användarens identitet. ID-token hämtar även användarens grundläggande profil där ett API returnerar information om användaren. Det pågår arbete med att skapa en OpenID Connect-profil för Connect, utöver de SAML-pro- filer som används, och för att DIGG ska kunna ge federativt stöd för OpenID Connect . 45https://(hämtad ). 46OpenID Connect kontrolleras av . Det är svårt men viktigt, inte minst ur ett informationssäkerhetsperspektiv, att underhålla behörighetsregister. Det ställs även i dataskyddsförordningen47 rättsliga krav på att myndigheter har behörighetsstyrning och, för de aktörer som omfattas, krav genom MSB:s föreskrifter om informationssäkerhet för statliga myndigheter48 samt MSB:s föreskrifter om säkerhetsåtgärder i informationssystem för statliga myndigheter49. Det finns flera möjliga lösningar på att tillhandahålla attribut. Det kan vara nationella register eller tjänster, det kan också ske lokalt hos e-tjänsten eller hos arbets- eller uppdragsgivaren. Det är vanligt att den som tillhandahåller en e-tjänst som personer från andra organisationer använder har ett behörighetsregister. Antingen direkt i tjänsten eller genom att en eller ett par personer från de organisationer som använder e-tjänsten administrerar konton för de egna användarna. Det finns också exempel på nationella centrala register med attribut som t.ex. inom hälso- och sjukvården. Det gör att om en person slutar eller av andra skäl inte längre ska ha rätt att hantera ett förfarande för sin organisation behöver organisationen inte bara ändra i sina egna register utan även i alla externa e-tjänster där personen har behörighet. Ett annat sätt att hantera det är att användarorganisationen själva tillhandahåller den behörighetsinformation som behövs. Det möjliggör dessutom att det för en organisation bara är ett register som behöver uppdateras och underhållas även om detta kan innefatta att kontroller behöver ske mot andra centrala register, exempelvis mot registret över legitimerad hälso- och sjukvårdspersonal (HOSP) för att hämta eller validera uppgifter om en anställd. På motsvarande sätt som identitetsintyg som tillhandahålls av en identitetsintygsutfärdare kan en offentlig aktör vara, själv eller via en extern part, attributtjänst och tillhandahålla attributsintyg med aktuell behörighetsinformation om sina anställda. För de fall där e-tjänsten behöver mer information om användaren som loggar in, exempelvis uppgift om behörighet kan en fråga ställas till en attributtjänst som genom en s.k. attributbegäran (”attribute query”) kan erhålla nöd- 47Exempelvis för att förhindra en personuppgiftsincident såsom t.ex. obehörigt röjande eller obehörig åtkomst. vändig kompletterande information. Härvid kan teoretiskt sett alla typer av e-legitimationer, även de som inte innehåller några specifika personuppgifter, såsom koddosor för generering av engångslösenord, användas för inloggning mot en myndighet som kräver såväl personnummer som ytterligare information om behörighet. Där de identifieringsuppgifter som behövs överförs i identitetsintyget och de attribut som krävs kan överföras i ett attributsintyg. Det finns få attributstjänster på det svenska e-legitimationsområdet. Inom ramen för de olika federationerna finns det profiler eller format för identitetsintyg. Vissa federationer, och Sambi har dessutom tagit fram attributsprofiler.50 Sambi:s attributsprofil förvaltas av Inera. Vad gäller har attributsprofilen tagits fram av SIS.51 Det finns exempel på länder som har försökt arbeta med stora centrala behörighetsregister för att lösa problemen med att ge behörigheter till användare. Centrala register skulle inte lösa problemet med att underhålla aktuell behörighetsinformation på en plats. Det skulle vidare samla uppgifter som kan vara mycket känsliga ur ett säkerhets- och dataskyddsperspektiv. Det finns även länder och organisationer som arbetar med att lagra behörighetsinformationen i egna certifikat på t.ex. smarta kort, men detta leder till en problematisk underhållssituation eftersom roller och behörigheter ofta ändras, vilket då kräver att nya certifikat utfärdas. tillsammans med andra myndigheter arbetar, inom ramen för uppdraget om förvaltningsgemensam digital infrastruktur för informationsutbyte, med en nationell infrastruktur för standardiserad digital fullmaktshantering.52 Infrastrukturen är tänkt att göra det möjligt att kunna agera med hjälp av fullmakter eller skapa fullmakter även i egna digitala tjänster och API:er finns för det syftet. Möjligheten att kunna hålla fullmaktsregister åt de som inte har egen kapacitet undersöks också. Anslutna organisationer ges åtkomst till ett administrativt gränssnitt för att konfigurera sina fullmaktsmallar. De får även behörigheter för fullmakter som gäller hos dem. Följande API:er erbjuds: 50www.sambi.se/wp-content/uploads/2019/05/Sambi_Attributspecifikation_1.5.pdf (hämtad ). content/uploads/2018/10/_Attributprofil_4_1.pdf (hämtad ). 52Gode män och förvaltare – en översyn. (SOU 2021:36), s. 434 f. •API för firmateckningstjänsten – Används för att se vilka och i vilken kombination firmatecknare kan signera en fullmakt. •API:er för digital fullmaktsförmedlare () – Används för att skapa fullmakt, hämta fullmaktsmall, ta bort, använda och visa fullmakt. tidigare avsnitten beskrivs de olika delarna av e-legitimations- området i . Förenklat uttryckt är de mest grundläggande förhållandena inom e-legitimationsområdet de som existerar mellan e-legi- timationsutfärdare, användaren av e-legitimationer (eller användarorganisationer om det rör sig om e-tjänstelegitimationer) samt förlitande parter med e-tjänster som kräver autentisering med e-legitimationer. Figur 6.2 Grundläggande förhållanden inom e-legitimationsområdet Det är inte alltid tre separata aktörer som innehar dessa roller och vad gäller e-tjänstelegitimationer kan arbetsgivaren i vissa fall även vara e-legitimationsutfärdaren. E-legitimationsutfärdaren är inte heller alltid identitetsintygsutfärdaren. Till detta finns även andra tekniska komponenter som inte framgår av figuren, exempelvis attributregister. till området som helhet är det emellertid viktigt att utgå från dessa tre roller för att förstå hur de olika delarna hänger samman. En grundläggande förutsättning för att systemet ska fungera är därtill att det både finns en teknisk infrastruktur samt att det finns tillit mellan de aktörer som har respektive roll. Figur 6.3 Grundläggande förhållanden samt stödstrukturer För att åstadkomma tillit och den tekniska infrastruktur som behövs krävs ytterligare aktörer och stödstrukturer. Systemet är inte beroende av ett tillitsramverk för att fungera.