Frågor och svar

Det är Diggs e-legitimeringsavtal som styr vem som kan ansluta till Sweden Connect för att nyttja de funktioner som finns i identitetsfederationen. Både offentliga och privata aktörer kan ansluta sina e-tjänster till Sweden Connect för att erbjuda inloggning med utländska e-legitimationer enligt eIDAS. Denna anslutning är kostnadsfri för offentliga aktörer, medan privata aktörer får betala en avgift. För nationell e-legitimering kan i nuläget endast offentliga aktörer teckna avtal och ansluta.

Skaffa lösningar för inloggning med e-legitimationer (digg.se) Länk till annan webbplats.

Vi rekommenderar att man som tjänsteägare ställer krav på att de system som upphandlas är anslutna till Sweden Connect. Detta krav innebär att du kan vara säker på följande:

• Din tjänst kommer fungera ihop med Sweden Connect fullt ut och därmed också med eIDAS.
• Integratörens platform blir verifierat mot de funktionella kraven i tekniskt ramverk.

Genom att ställa krav på anslutning till Sweden Connect är man alltså både säker på att tekniskt ramverk är uppfyllt men även att kravuppfyllelse är baserat på mer än löften från en leverantör utan även på tester och verifiering som genomförs i samband med anslutningen till Sweden Connect.

Tekniskt ramverk

Normalt ska metadata genereras av mjukvaran (SP och IdP).

Dock kan det i vissa fall vara bra att ha en förlaga att jämföra med. Vi rekommenderar att du vid behov tittar på den metadata som publicerats för vår test-SP och referens-IdP:

• https://test.swedenconnect.se/sp (test-SP i produktion)
• https://qa.test.swedenconnect.se/sp (test-SP i QA)
• http://qa.test.swedenconnect.se/idp (referens-IdP i QA).

I Tekniskt ramverk för Sweden Connect finns viktiga kommentarer i ändringar och tillägg som gjorts i förhållande till SAML-standarden.

Tekniskt ramverk för Sweden Connect Länk till annan webbplats.

Tänk på att göra följande:

• Skapa unik metadata för din tjänst. Metadata innehåller bland annat nycklar som är unika för varje SP/IdP. Du kan därför inte kopiera någon annans metadata.
• Validera alltid din metadata med hjälp av metadatavalidatorn.

Sweden Connects metadatavalidator Länk till annan webbplats.

Nej, vi tillåter inte att samma tjänst används i både QA- och produktionsmiljön. Vi rekommenderar istället att du sätter upp en separat testversion av tjänsten som ansluts till QA-miljön, eller i förekommande fall ansluter tjänsten endast till produktionsmiljön.

Tekniskt finns det inget hinder för att använda samma tjänst i båda miljöerna, men det finns allvarliga risker för läckage av persondata och identitetsstöld. I QA-miljön finns testländer anslutna till eIDAS-connectorn som tillåter att man antar godtyckliga identiteter (personnummer) i en inloggning. Om dessa inloggningar når en produktionstjänst som inte verifierar vilken entityID som är utställare av intyget så kan i värsta fall riktiga personer påverkas.

Vi rekommenderar också att loggning i en produktionstjänst sker mycket restriktivt så att personuppgifter inte riskerar hamna i loggar som eventuellt kan komma på drift.

Har du erfarenhet av att använda SAML 2.0 i så kallade SaaS eller enterprise-tjänster så behöver du vara medveten om några viktiga skillnader:

• Er programvara måste kunna hantera alla krav i tekniskt ramverk.
• Er programvara måste kunna använda metadata som innehåller mer än en IdP.
• Connector-tjänsten hos Sweden Connect fungerar som en IdP.
• Er programvara måste kunna hantera uppdatering av metadata kontinuerligt och utan att kräva omstarter.

Vi rekommenderar att man utgår ifrån en färdig SP-implementation för SAML 2.0 som kan anpassas för att uppfylla kraven i tekniskt ramverk. Vi avråder starkt ifrån att försöka implementera en SP endast med utgångspunkt från ett SAML-bibliotek (tex i Java eller .Net). Skillnaden mellan ett SAML-bibliotek och en SP-implementation motsvarar en stor arbetsinsats och representerar i de flesta fall mycket kunskap om hur SAML fungerar i federationer. Att avkoda SAML-meddelanden (vilket är vad ett SAML-bibliotek gör) och att ha en fungerande SP är två skilda saker.

Visst kan ni bygga er SP-lösning på öppen källkod. Det finns implementationer av SAML 2.0 som är släppta som öppen källkod. En utgångspunkt kan vara denna sammanställning. Men det är viktigt att ni väljer en lösning som fullt ut har stöd för Tekniskt ramverk eller som enkelt kan anpassas.

Många programvaror som påstår sig stödja SAML 2.0 saknar viktiga funktioner till exempel möjligheten att använda mer än en IdP. För att använda en sådan programvara kommer du i praktiken att bli tvungen att placera en proxy som har komplett SAML-stöd mellan Sweden Connect och din SP, vilket också ökar komplexiteten i din implementation. En bra programvara som är släppt som öppen källkod och uppfyller det flesta kraven i tekniskt ramverk är Shibboleth.

Shibboleth Länk till annan webbplats.

Men kom ihåg att oavsett vilken programvaran ni väljer så kommer den att behöva anpassas. Har ni inte god teknisk kompetens så bör ni ta hjälp av någon integratör som hjälper er. Tycker ni att det blir för svårt så finns så finns det flera kommersiella leverantörer vars SAML-servrar kan anpassas till tekniskt ramverk. Tänk på att alltid ställa krav på att Tekniskt ramverk ska uppfyllas i en eventuell upphandling.

Vi avråder från att försöka programmera en egen SP endast med utgångspunkt från ett SAML-bibliotek. Använd hellre någon av de bra fria SAML SP som finns och gör en anpassning.

Använd en SP-implementation som har stöd för tekniskt ramverk eller som enkelt kan anpassas. Vi avråder från att försöka programmera en egen SP endast med utgångspunkt från ett SAML-bibliotek. Använd hellre någon av de bra fria SAML-SP:ar som finns och gör en anpassning.

Det finns bra fri programvara som uppfyller det flesta kraven i tekniskt ramverk, som till exempel Shibboleth.

Shibboleth Länk till annan webbplats.

Många programvaror som påstår sig stödja SAML 2.0 saknar viktiga funktioner till exempel möjligheten att använda mer än en IdP. För att använda en sådan programvara kommer du i praktiken att bli tvungen att placera en proxy som har komplett SAML-stöd mellan Sweden Connect och din SP vilket också ökar komplexiteten i din implementation.

Det finns flera kommersiella leverantörer vars SAML-servrar kan anpassas till tekniskt ramverk. Tänk på att alltid ställa krav på att tekniskt ramverk ska uppfyllas i en eventuell upphandling!

Tekniskt ramverk för Sweden Connect Länk till annan webbplats.

Börja med att vänta lite

När din metadata validerats och signerats tar det upp till 10 minuter innan den ingår i metadataströmmen och ytterligare 10-20 minuter innan alla IdP:er har plockat upp ändringen. Detta gäller även eIDAS-connectorn. Vänta därför med att felanmäla problem i ca 30 minuter för att vara säker på att allt hunnit uppdateras.

Om du begärt att få metadata publicerad i QA eller produktion kan det ta ännu längre tid eftersom det sker manuella kontroller av din tjänst innan metadata godkänns.

I test/utvecklingsmiljön (sandbox.swedenconnect.se) finns det ett självservicegränssnitt. Där bör din metadata dyka upp inom några minuter om den är korrekt formaterad.

Testa din metadata i metadatavalidatorn

För att minska risken för problem ska du alltid använda validatorn för att se till att ditt metadata är korrekt. Validatorn fångar de allra flesta problem vi känner till och om du inte har några fel eller varningar där bör ditt metadata dyka upp inom 10 minuter från att du har fått en bekräftelse på att det blivit mottaget och godkänt för publicering.

Observera att för produktion måste du ha ett giltigt avtal med Sweden Connect för att ditt metadata ska godkännas för publicering.

Observera också att det inte sker någon automatiskt uppdatering av ditt metadata - om du ändrar på något måste du skicka en ny version.

Sweden Connects metadatavalidator Länk till annan webbplats.

Sannolikt saknas en annonsering av vilka identitetsattribut som önskas av e-tjänsten i dess metadata. Du kan läsa mer i tekniskt ramverk för Sweden Connect, och på sidan Entitetskategorier och tillitsnivåer.

Tekniskt ramverk för Sweden Connect Länk till annan webbplats.

Entitetskategorier och tillitsnivåer

Börja med att verifiera att inloggningen fungerar via dessa tjänster:

• Produktion: test.swedenconnect.se Länk till annan webbplats.
• QA: qa.test.swedenconnect.se Länk till annan webbplats..

Om din inloggning fungerar mot dessa tjänster (beroende på om din tjänst finns i QA eller produktion) så är det sannolikt något problem med din tjänst.

Om inloggningen inte fungerar i dessa test-SP:s så kan det vara fel på antingen e-legitimationsutfärdarens system (IdPn) eller på anslutningen av SP:n eller IdP:n till Sweden Connect. Kontakta då oss för vidare support.

Kontakta oss

De svarskoder som kan komma från systemet finns listade i avsnitt 3.2.2.2 Element <StatusCode> i dokumentet "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" som utgör standarden för SAML2,

Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0 Länk till annan webbplats.

Dessutom tillkommer 3 felkoder som beskrivs i avsnitt "6.4 Error responses" i tekniskt ramverk.

Tekniskt ramverk för Sweden Connect Länk till annan webbplats.

Deklaration av xs prefix:

Metadata validatorn testar att alla XML name space prefix är deklarerade. Name space prefix är valda referens-identifierare som på ett läsbart sätt förmedlar information om var olika element, attribut och i vissa fall parametrar är definierade.

När man inspekterar metadata för andra tjänster i metadatavalidatorn så visas deklarationer av name space prefix så som exempelvis:

xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"

Dock visas sällan deklaration av name space prefix ”xs” som används för att deklarera bland annat strängvärden ”xs:string” där xs skall deklareras som:

xmlns:xs="http://www.w3.org/2001/XMLSchema"

Det finns flera skäl till detta: xs:string är en deklaration som förekommer som ett attributvärde typ xsi:type="xs:string". Det gör att dess deklaration inte skrivs ut till skillnad mot deklaration av element- och attributnamn. Deklarationen av xs görs oftast i rot elementet i en metadata fil och inte i enskilda tjänsters metadata. Resultatet är att det är lätt att missa just deklarationen av xs i ”xs:string”.

Lösningen på problemet, om metadata validatorn ger felmeddelandet at xs ej är definierat, är att lägga in följande deklaration i metadatas rotelement (EntityDescriptor):

xmlns:xs="http://www.w3.org/2001/XMLSchema"

eIDAS är en EU-förordning som gäller som lag. eIDAS innehåller regler för gränsöverskridande elektronisk identifiering (e-legitimering) och betrodda tjänster.

Enligt eIDAS behöver varje medlemsland tillhandahålla en så kallad landsnod, en anslutningspunkt där e-legitimationstrafiken kontrolleras och ”översätts” till respektive lands identitetsmetod. I Sverige är landsnoden ansluten till Sweden Connect.

Syftet med eIDAS är att stödja den digitala inre marknaden inom EU. Exempel på användningsområden är att:

• en svensk medborgare som är bosatt utomlands ska kunna använda landets e-legitimation för att komma åt svenska myndigheters e-tjänster.
• en svensk medborgare ska kunna använda en svensk e-legitimation för att komma åt e-tjänster i ett annat EU-land.
• en medborgare i annat EU-land ska kunna komma åt vissa svenska myndigheters t-tjänster utan att behöva skaffa en svensk e-legitimation.

eIDAS står för Electronic Identification, Authentication and Trust Services.

EU-förordningen eIDAS (EU) 910/2014 (europa.eu) Länk till annan webbplats.

Det enda som eIDAS hanterar idag är identifiering av fysiska personer. Roller och behörigheter måste hanteras i tjänsten.

Ett PRID är en identifierare för en person som loggar in via eIDAS. I vissa fall kan PRID användas som ersättare till personnummer. Som följd av hur olika länder hanterar personliga identifierare har Sweden Connect valt att klassificera PRID efter hur permanent och unikt ett PRID är:

• A = Persistent motsvarande personnummer - vanligt inom till exempel Norden.
• B = Nytt PRID kan erhållas om man gifter sig eller flyttar inom landet (till exempel Tyskland),
• C = Varje eID har evt ett separat PRID (till eempel England)

Alla PRID är unika i meningen att det inte kan tilldelas annan person.

Tänk på att unik (ett givet PRID hör till en och endast en person) och persistent (samma person har alltid exakt ett och samma PRID) är två olika egenskaper hos ett PRID. En e-tjänst som bara är beroende av ett unikt ID kan fungera med alla former av PRID. I Sverige är vi vana vid personliga identifierare som är både (någorlunda) persistenta och unika men genom att analysera de verkliga behoven av en e-tjänst kan man göra integrationen med eIDAS enklare.

eIDAS reglerar medlemsländernas skyldighet att i rättsliga processer acceptera elektroniska underlag samt elektroniska underskrifter. Grundregeln är att dessa ska accepteras om det inte i nationell lag finns särskilda regler som förhindrar det. Samma regler gäller i hela EU om elektroniska underskrifter (och övriga så kallade betrodda tjänster). Därmed är en elektronisk underskrift som godkänts för användning i ett land godkänd att använda i alla EU-länder.

I Sverige är det vanligt att användaren skriver under uppgifter med hjälp av sin e-legitimation, till exempel sitt BankID. Det förfarandet är inte lika vanligt i andra länder. Tekniskt finns inte stöd för de underskriftsstransaktioner som svenska e-tjänster är utformade för att hantera i eIDAS-förordningen och den tekniska infrastruktur som byggts upp utifrån förordningen. E-tjänsterna måste därför bygga om så att de sköter underskriften via underskriftstjänster som fristående från e-legitimationsutfärdaren skapar underskriften efter det att användaren legitimerat sig mot underskriftstjänsten.