...
- Fristående underskriftstjänst utan egna grafiska gränssnitt som kräver viss teknisk implementation och anpassning av den egna e-tjänsten i din organisation. Denna variant kallas för Underskriftstjänsten - Bas och stödjer SITHS eID.
- Integrerad lösning där den egna e-tjänstern använder ett API för att starta ett underskriftsflöde, detta kallas för Underskriftstjänsten - API. Denna lösning stödjer SITHS eID och flera privata e-legitimationer som till exempel BankID.
- Webbapplikation där du som kund laddar upp dokument för elektronisk underskrift. Underskriftstjänsten - Webb kräver ingen integration. Det går bra att använda SITHS eID och privata e-legitimationer med denna variant.
Verksamhetens ansvar
Underskriftstjänsten 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 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
| Info |
|---|
| Anslutningen till Underskriftstjänsten är specifik för varje ansluten e-tjänst men Stödtjänsten kan användas av flera e-tjänster i din organisation. Dvs det räcker med en installation av Stödtjänsten för att försörja flera e-tjänster med denna funktion. |
Anslutning till Stödtjänsten och IdP från Inera tillsammans med Underskriftstjänsten
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 beskriver IT-arkitekturen 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
Kundens lokala IdP med Underskriftstjänsten
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.
Kundens IdP ansluten till Ineras IdP som IdP-proxy
För- och nackdelar med de olika anslutningssätten där e-tjänsten är ansluten till Underskriftstjänsten men olika IdP:er nyttjas i lösningen
...
Referenser och vidare läsning
...