Inledning

Ett underskriftsflöde resulterar i ett underskrivet dokument som sedan kan arkiveras i den egna organisationen eller skickas till någon annan organisation. I detta flöde måste användaren legitimera sig för underskrift. Den här artikeln vänder sig till dig som vill veta hur personidentiteter hanteras i ett underskriftsflöde vid denna legitimering i Ineras lösning. Specifikt svarar artikeln på vilka certfikat som används på SITHS eID men även hur attributhanteringen går till.

Elektronisk underskrift i Ineras lösning kan bara nyttjas via out-of-band metoder, därför finns ingen beskrivning av hur detta fungerar via mTLS.

Artikeln inleds med ett kapitel som sammanfattar lösningen men för att kunna ta del av denna artikel, förutsätts grundläggande kunskap om elektronisk underskrift, (på engelska: electronic signature). I slutet av artikeln finns referenser till dokument för den som vill fördjupa sig ytterligare i ämnet. I synnerhet är Referensarkitekturen för elektronisk underskrift och stämpel en bra källa för att förstå principer och terminologi.

Artikeln vänder sig till den som vill ha en fördjupad förståelse kring hur Underskriftstjänstens fungerar. För att ansluta till tjänsten innehåller Anslutning Underskriftstjänsten all nödvändig information. Allmänt om tjänsten finns också på Ineras hemsida.

Underskriftsflödet via fristående underskriftstjänst med out-of-band legitimering vid underskrift i Ineras lösning med SITHS eID

Samverkande komponenter i ett underskriftsflöde i Ineras lösning

För att nå slutmålet underskrivet dokument i Ineras lösning krävs ett underskriftsflöde med följande moment

Användaren loggar in i den e-tjänst som har de dokument som ska skrivas under, här via Ineras IdP och någon av out-of-band-metoderna Samma enhet eller Annan enhet. Val av tjänsteid eller uppdragsval sker här.
E-tjänsten skapar i sin tur en underskriftsbegäran med hjälp av komponenten Stödtjänster för underskrift
E-tjänsten använder underskriftsbegäran i anropet till den fristående Underskriftstjänsten
Den fristående underskriftstjänsten anropar samma IdP med begäran om legitimering för underskrift
IdP-tjänsten verifierar användarens identitet och attribut
Användaren godkänner och skriver under med sitt SITHS eID med samma metod som användes för inloggning som nu används för att legitimera för underskrift och utan uppdragsval eller val av tjänsteid.
IdP returnerar ett identitetsintyg till den fristående Underskriftstjänsten
Den fristående Underskriftstjänsten skapar den elektroniska signaturen och returnerar resultatet till e-tjänsten
E-tjänsten använder Stödtjänster för underskrift för att validera e-underskriften och sammanfoga den till dokumentet, målet är uppfyllt!

Det finns varianter av detta flöde. T ex behöver inte IdP för autentisering vara samma som den IdP som används för legitimering för underskrift, stödtjänsterna kan vara inbyggda i e-tjänsten, e-tjänsten kan vara en portal, inte ett verksamhetssystem. Principerna för hur en elektronisk underskrift går till är dock samma, oavsett dessa variationer. Inera erbjuder en möjlighet att använda en fristående e-tjänst som dessutom går att använda med andra e-legitimationer än SITHS eID. En beskrivning hur den tjänsten är uppbyggd finns i SAD - Underskriftstjänsten Webb och API.

Denna artikel fokuserar på vad som händer vid steg 4-6.

Hantering av personidentitet, attribut och certifikat vid legitimering för underskrift

De väsentligaste skillnaderna mellan autentisering och legitimering för underskrift

Autentisering svarar på frågan "vem är du", legitimering för underskrift syftar på att klargöra "är du den du utger dig för att vara" och begär dessutom av användaren en bekräftelse på att användaren är medveten om vad den gör. På grund av det sistnämnda finns aldrig SSO för legitimering av underskrift, då det alltid är tvingande för användaren att legitimera sig igen.
Vid autentisering så innehåller begäran till IdP:n en uppräkning av de attribut, inklusive identitet som IdP:n förväntas returnera. Vid legitimering för underskrift får IdP:n explicita värden att verifiera, t ex HSA-id och organisationsnummer.
Val av tjänsteid eller uppdragsval förekommer normalt inte vid legitimering för underskrift då IdP.n kan verifiera de angivna värdena utan användarinteraktion. Undantag kan finnas om organisationstillhörighet inte kan fastställas utan uppdragsval.
Specifkt för legitimering för underskrift får IdP:n ett underskriftsmeddelande som ska visas upp för användaren och vilken autentiseringsmetod som ska användas så att användaren inte ska behöva välja metod igen.
Hantering av personidentifierare vid autentisering ger mer detaljer om autentisering. Se Referenser.
Det finns också ett specialfall vid utgivning av SITHS eID där Ineras IdP har funktionalitet som bara ska användas vid elektronisk underskrift och utgivning, se SAD IdP elektronisk underskrift, Referenser.

Exempel på legitimering för underskrift

I detta exempel har e-tjänsten ett behov av att signera med HSA-id och organisationsnummer. Användaren har valt att autentisera sig med SITHS eID på kort, dvs Samma enhet, på en PC.

I steg 4 enligt figuren ovan så kommer IdP:n att få en begäran om legitimering för underskrift med användarens HSA-id och organisationsnummer samt den valda metoden Samma enhet. Användarens HSA-id och organisationstillhörighet har fastställts vid autentiseringen och skickas från den centrala underskriftstjänsten till IdP:n.

Funktionen att från en e-tjänst ange explicita värden för t ex organisation och identetet kallas för PrincipalSelection och beskrivs i Attributstyrning SAML. Detta kan mycket väl används även vid autentisering, om e-tjänsten vill avgränsa autentiseringen, t ex att bara gälla en viss organisation. För den som vill veta mer om PrincipalSelection generellt rekommenderar vi Principle Selection in SAML Authentication, en artikel från DIGG. Motsvarande funktion finns även för OIDC, hur Inera har realiserat det går att läsa i Attributstyrning OIDC. Observera att för elektronisk underskrift används uteslutande SAML, för autentisering kan även OIDC användas.

I steg 5 och 6 kommer IdP:n att verifiera att användarens HSA-id och organisation via Katalogtjänsten i samband med att användaren intygar underskriften, dvs legitimering för underskrift.

Då autentiseringsmetoden är känd så behöver användaren inte välja autentiseringsmetod men användaren måste ange PIN-kod, dvs det finns ingen SSO mellan autentisering och legitimering för underskrift.

Observera att det certifikat som används för legitimering för underskrift är samma som används för autentisering så det kommer att vara samma PIN-kod i bägge fallen.

Då personnummercertifkatet är prioriterat genom Autentiseringstjänsten kommer det certifikatet att användas. Personnummret kommer att användas för att göra ett uppslag mot katalogtjänsten för att verifiera t ex HSA-id och organisationsnummer för användaren.

Val av tjänste-id är inte aktuellt i denna situation.

Uppdragsval kan förekomma om inte organisationstillhörigheten kan fastställas. Det beror på att organisationstillhörighet är knutet till medarbetaruppdraget.

Sammanfattning

Personnummercertifikatet är prioriterat och kommer att användas i samband med legitimering för underskrift.
Val av tjänste-id och uppdragsval förekommer inte vid legitimering för underskrift. Undantaget är när organisationstillhörighet måste fastställas via uppdragsval.
Även om användaren har använt samma autentiseringsmetod för autentiserings och legitimering för underskrift måste användaren legitimera sig vid bägge tillfällena, dvs ingen SSO.
Vid legitimering för underskrift går det bara att använda autentiseringsmetoder baserat på out-of-band.