1. Innehåll

2. Introduktion

Denna artikel beskriver olika sätt som din organistion kan nyttja Ineras underskriftstjänst. Efter att du har läst detta, ska du kunna avgöra vilket sätt som passar bäst för din organisations behov.

Artikeln beskriver skillnaderna mellan de tre artiklarna Underskriftstjänsten - Bas, Underskriftstjänsten - API och Underskriftstjänsten - Webb, som representerar olika sätt att ansluta till tjänsten. Sist finns det referenser för mera läsning och förståelse. För mera detaljer om exakt vad som behöver göras för respektive anslutningstyp  rekommenderar vi Anslutningsgudie till Ineras underskrifttjänst. På Ineras hemsida finns all information om hur du beställer tjänsten.

3. Principiella skillnader mellan olika integrationsmönster för olika artiklar

Målet med att nyttja Underskriftstjänsten från Inera är att få en elektronisk signatur på sitt dokument. För användaren innebär det alltid att använda en e-tjänst. Realiseringen av detta innebär att ett antal komponenter samverkar med e-tjänsten, bl a en koppling till en central underskriftstjänst. Denna samverkan kallar vi för underskriftsflöde.  Mer om detta finns att läsa i l Hantering av personidentiteter vid signering i ett underskriftsflöde, se Referenser. Graden av komplexitet för den anslutande organisationen avgörs mycket av hur mycket av underskriftsflödet organisationen vill ta på sig. Med ökad komplexitet följer också ökade möjligheter till flexibilitet och egen utformning av användarupplevelsen.                                                               .

4. Underskriftstjänsten - Bas

4.1. Översikt

                                                                         Underskriftstjänsten - Bas: djupintegration med eget ansvar för underskriftsflödet

I Underskriftstjänsten - Bas måste användarorganisationen realisera underskriftsflödet i den egna e-tjänsten. Det innebär en hel del integrationsarbete men också stor flexibilitet vad gäller utformning av t ex användardialoger.

4.2. Verksamhetens ansvar

Underskriftstjänsten - Bas från Inera i kombination med Stödtjänsten och Ineras IdP ger sammantaget dig som kund en bra teknisk utgångspunkt för en lyckad integration. Trots det är det en hel del utveckling som ska göras i den anslutna e-tjänsten. Det finns också ett juridiskt ansvar för dig som kund, som du kan läsa i den juridiska vägledningen från eSAM. Inera rekommenderar dig som kund att betrakta detta som ett projekt, då det är ett relativt omfattande arbete att inför digitala signaturer i din organisation.

Detta är en sammanfattning av vad du som kund behöver göra tekniskt för att ansluta till tjänsten i normalfallet

• Installera Stödtjänsten från Inera eller motsvarande från någon annan leverantör i den egna miljön
• Utveckla e-tjänsten för att
  • Anropa Stödtjänsten för att skapa kontrollsumma, foga ihop dokument med signatur, validera det signerade dokumentet
  • Anropa den centrala Underskriftstjänsten för att skapa signaturen
  • Ansluta e-tjänsten till Ineras IdP för autentisering (valbart)
  • Hantera dokumentet i underskriftsflödet och för arkivering eller annan hantering

4.3. Anslutning till Stödtjänsten och IdP från Inera 

Det är lämpligt att de eller de e-tjänster i din organisation som ska anslutas till Underskriftstjänsten även ansluter till Ineras IdP för autentisering av användarna. Det är inget krav, det går att använda en lokal IdP för autentiseringen, eller någon annan lösning som din organisation finner lämpligt att använda. Dock är det ur flera aspekter viktigt att fastställa användarens identitet. En är att hantera behörigheten till de dokument som ska signeras, en annan är att kunna skicka undertecknarens identitet till Underskriftstjänsten som ska fastställa den genom att avkräva legitimering av användaren. Eftersom Underskriftstjänsten från Inera använder Ineras IdP för detta, underlättar det om e-tjänsten använder samma IdP för autentisering.

Inera tillhandahåller även ett applikationspaket Stödtjänsten som underlättar integrationen med Underskriftstjänsten om e-tjänsten integreras mot den tjänsten. Stödtjänsten hanteras i din organisations miljö.

Nedan en bild som översiktligt hur e-tjänsten integreras i underskriftsflödet när din organisation väljer att nyttja hela Ineras erbjudande, där anslutningen till Ineras IdP för autentisering är valbar (den streckade pilen). När det gäller legitimering för underskrift, använder lösningen alltid Ineras IdP.

                                                                                 Kundens e-tjänst är ansluten till Underskriftstjänsten, Ineras IdP och Stödtjänsten

4.4. Kundens lokala IdP med Underskriftstjänsten utan stödtjänst

Ett alternativ är att ansluta kundens lokala IdP som en IdP-proxy till Ineras IdP för att på så sätt undvika att realisera både hanteringen av SITHS eID och integrationen med Underskriftstjänsten. Den lösningen ger möjligheten att kunna hämta användarinformation från den lokala katalogtjänsten och ge SSO, Single Sign-On, vid autentisering. Detta är analogt med att använda en lokal IdP som IdP-proxy för autentisering. IdP-proxy:n uppträder som en IdP gentemot de anslutna e-tjänsterna och som en SP gentemot Ineras IdP. Att notera är att även i det fallet är det Ineras IdP som är integrerad mot Underskriftstjänsten, inte kundens IdP.

Bilden nedan illustrerar också möjligheten att bygga in Stödtjänstens funktionalitet i den egna e-tjänsten. Det betyder en mindre komponent att hålla reda på i den egna driftsmiljön. Dock tappar man möjligheten att nyttja Stödtjänsten för flera e-tjänster som ska integreras mot den centrala underskriftstjänsten. Det går givetvis att använda Stödtjänsten, även i fallet med en egen IdP.

                                                                                                                                     Kundens IdP ansluten till Ineras IdP som IdP-proxy

5. Underskriftstjänsten - API

5.1. Översikt

                                                            Underskriftstjänsten - API: integration  med  färdigt underskriftsflöde

Kundens e-tjänst integreras mot ett färdigt underskriftsflöde via ett API. Vid anropet så skickar kundens e-tjänst information om vilka som ska skriva under med vilken underskriftsprofil och vilka dokument som ska signeras. De underskrivna dokumenten leverereras tillbaka till kundens e-tjänst. 

5.2. Verksamhetens ansvar

Underskriftstjänsten - API från Inera  ger dig som kund en bra teknisk utgångspunkt för en lyckad integration. Utvecklingsinsatsen i den anslutna e-tjänsten begränsas till anrop av REST-tjänster. Det finns ett juridiskt ansvar för dig som kund, som du kan läsa i den juridiska vägledningen från eSAM. Inera rekommenderar dig som kund att betrakta detta som ett projekt, då det är ett relativt omfattande arbete att inför digitala signaturer i din organisation.

Användaren av systemet är antingen adminstratör och kan lägga upp signeringsuppdrag eller signatär, den som signerar. Administratören måste autentisera sig med SITHS eID,  signatären kan signera med SITHS eID eller annan e-legitimation. Se www.inera.se/underskriftstjansten för vilka e-legitimationer som är möjliga att använda för legitimering för underskrift. 

Efter att administratören lagt upp en begäran om signering av en eller flera signatärer via sin e-tjänst så kommer signatärerna notifieras via email. När alla har signerat, notifieras administratören.

Detta är en sammanfattning av vad du som kund behöver göra tekniskt för att ansluta till tjänsten

• Utveckla e-tjänsten för att
  
  • Anropa Underskriftstjänsten - API för att skapa underlag för signering
  • Ansluta e-tjänsten till Ineras IdP för autentisering (valbart)
  • Hantera det underskrivna dokumentet som returneras till kundens e-tjänst, t ex arkivering

5.3. Anslutning till Underskriftstjänsten - API

Det är lämpligt att de eller de e-tjänster i din organisation som ska anslutas till Underskriftstjänsten - API även ansluter till Ineras IdP för autentisering av användarna. Det är inget krav, det går att använda en lokal IdP för autentiseringen, eller någon annan lösning som din organisation finner lämpligt att använda. Dock är det ur flera aspekter viktigt att fastställa användarens identitet. En är att hantera behörigheten till de dokument som ska signeras, en annan är att kunna skicka signatärernas identitet till Underskriftstjänsten - API som ska fastställa den genom att avkräva legitimering av signatären. 

Varje signeringsuppdrag som administratören lägger upp innehåller information om vilka dokument som ska signeras, av vilka signatärer och vilken underskriftsprofil som gäller för respektive signatär.

Då det signerade dokumentet returneras till den anslutna e-tjänsten är det också lämpligt att integrera e-tjänsten med kundens arkivsystem i de fall dokumentet ska arkiveras utanför systemet.

Signatärerna kan ladda ner de signerade dokumentet för egen hantering.

6. Underskriftstjänsten - Webb

6.1. Översikt

                                                   Underskriftstjänsten - Webb: ingen integration, e-tjänsten och underskriftsflödet finns inbyggt i tjänsten.

I denna variant krävs ingen integration av kundens e-tjänst. E-tjänsten som Inera levererar är integrerad i underskriftsflödet med inbyggd stödtjänstfunktionalitet.

6.2. Verksamhetens ansvar

Underskriftstjänsten - Webb från Inera  kräver minimal teknisk insats för dig som kund. Det finns dock ett juridiskt ansvar för dig som kund, som du kan läsa i den juridiska vägledningen från eSAM. Även om tekniken inte är så komplicerad rekommenderar Inera dig som kund att betrakta detta som ett projekt, då det är ett relativt omfattande arbete att inför digitala signaturer i din organisation. Framför allt när det gäller att hantera det underskrivna dokumentet.

6.3. Anslutning till Underskriftstjänsten - Webb

Då Inera levererar komplett funktionalitet återstår det för verksamheten att införa digitala signaturer i sin verksamhet när man fått tillgång till Underskriftstjänsten - Webb. 

Användaren av systemet är antingen adminstratör och kan lägga upp signeringsuppdrag eller signatär, den som signerar. Administratören måste autentisera sig med SITHS eID, signatären kan signera med SITHS eID eller annan e-legitimation. Se www.inera.se/underskriftstjansten för vilka e-legitimationer som är möjliga att använda för legitimering för underskrift.

Varje signeringsuppdrag som administratören lägger upp innehåller information om vilka dokument som ska signeras, av vilka signatärer och vilken underskriftsprofil som gäller för respektive signatär.

Efter att administratören lagt upp en begäran om signering av en eller flera signatärer via Underskriftstjänsten - Webb så kommer signatärerna notifieras via email. När alla har signerat, notifieras administratören.

Autentiseringen för administratören sköts via Ineras IdP, med SITHS-kort eller Mobilt SITHS.

I tjänsten ingår ingen integration med något arkivsystem. Det innebär att verksamheten själva ansvarar för att ladda ner det signerade dokumentet från tjänsten och arkivera manuellt.

7. För- och nackdelar med de olika anslutningssätten 

8. Referenser

• Anslutningsguide till Ineras Underskrifttjänst
• Att ansluta e-tjänster
• eSams juridiska vägledning 
• Filmer
• Hantering av personidentiteter vid signering i ett underskriftsflöde
• Identifieringstjänst SITHS
• IdP från Inera
• Refererensarkitektur – Elektronisk underskrift och stämpel
• Referensarkitektur – Identitet och åtkomst
• Riksarkivet om dokumentformatet PDF
• Utgivning och användning av SITHS e-legitimation
• Om Underskriftstjänsten på Ineras hemsida, inklusive priser och beställning
• Övrig Dokumentation Underskriftstjänsten
• Testfall och resultat