Bakgrund
Signering via fristående underskriftstjänst infördes i Webcert 6.8.0 och har som huvudsyfte att möjliggöra för underskrifter i andra webbläsare än Internet Explorer för de som använder SITHS-kort. En fristående Underskriftstjänst är en tjänst som följer de specifikationer som anges av DIGG (https://www.digg.se/digital-identitet/e-underskrift), och som upphandlats av Inera.
Initialt kommer flödet med underskriftstjänst användas av de användare som nyttjar annan webbläsare än Internet Explorer, samt de vårdenheter som valt att ingå i en pilot. Längre fram är tanken att Underskriftstjänst skall ersätta behovet av NetID plugin.
En stor skillnad gentemot signering med NetID plugin är att underskriften inte sker med det signerings-certifikat som användaren har på sitt SITHS-kort. Istället legitimerar sig användaren via en IdP, och det är sedan Underskriftstjänsten som använder uppgifter från denna legitimering för att skapa upp ett engångs-signerings-certifikat som sedan ligger till grund för underskriften.
...
Nedan stycke beskriver vad som krävs för app-växling i det nya underskriftsflödet. Notera dock att detta flöde är ett komplement till den underskrift som idag kan göras i Internet Explorer via NetID. Åtgärder som anges nedan är därmed enbart krav för de som ämnar nyttja detta nya underskriftsflöde för att tillgängliggöra Webcert i fler webbläsare.
Nytt Underskriftsflöde
Ur ett användarperspektiv så är det följande som sker.
...
...
1:
Användaren har loggat in i Webcert med SITHS-kort och har skrivit ett intyg som är klart att signera.
Användaren klickar på Signera intyget
...
...
2:
Webcert dirigerar användarens webbläsare till Underskriftstjänsten med information om den data som ska signeras.
Ingen dialog visas för användaren (webbläsaren visar vit bakgrund).
...
3:
Underskriftstjänsten dirigerar användarens webbläsare till Ineras IdP med begäran om att legitimera användaren för underskrift.
IdP’n visar en dialog och försöker samtidigt starta SITHS eID Autentiseringsklientpå användarens dator.
Det är i detta steg som den s.k. app-växlingen sker och där användarens webbläsare behöver ha rättigheter för att öppna program via protokollet siths://.
Om Autentiseringsklienten inte startar automatiskt kan användaren klicka Starta SITHS eID på denna enhetför att försöka starta den manuellt.
Notera att kravet gällande app-växling gäller oavsett om programmet öppnas per automatik eller genom att manuellt klicka på länken.
...
...
4:
SITHS eID Autentiseringsklientstartas och ansluter till Autentiseringsservern.
En dialog visas för användaren med information om vad som ska signeras.
Användaren anger sin PIN-kod för legitimering (PIN1) och klickar Skriv under.
Autentiseringsklienten slutför legitimeringen av användaren och skickar informationen till Autentiseringsservern.
För att steg 3 och 4 i ovan flöde skall fungera så krävs det som sagt att webbläsaren har rättighet att starta det aktuella programmet.
...
...
5:
...
webbläsare
...
.
Webcert visar dialog med signerat intyg, eller felmeddelande om signering misslyckades.
...
Förutsättningar
För att en användare ska kunna nyttja det nya underskriftsflödet krävs att vissa förutsättningar är uppfyllda:
...
| Det nya underskriftsflödet kräver att användaren har ett certifikat utfärdat inom nya SITHS eID PKI-strukturen. Konkret innebär detta att användaren behöver ett certifikat på sitt SITHS-kort utfärdat av en CA (Certificate Authority) i listan nedan. Giltiga certifikatsutfärdare:
|
| När Webcert initierar underskriftsbegäran (EidSignRequest) anges i detta request vilken LoA-nivå som krävs. I detta fall anger Webcert alltid LoA3 enligt nedan. Detta gäller oavsett vilken LoA-nivå som användaren uppnår vid inloggning. Anledningen till att detta nämns i denna förstudie är den specialbehandling av LoA2 som e-tjänster måste hantera efter den 9/12-2020. Normalfallet för Webcert är att enbart LoA3 tillåts vid inloggning, men under en övergångs-period för gamla SITHS-kort är det beslutat av Inera (Fredrik Rosenberg) att även LoA2 skall vara giltigt för åtkomst till patientinformation. Det beslutades dock tidigt att nya Underskriftsflödet inte skall tillåta något annat än LoA3. De användare som autentiserar sig och enbart uppnår LoA2 kan signera i Webcerts gamla signeringsflöde (vilket kommer vara standard för majoriteten av alla användare under en längre tid). |
Programvaror
Nedanstående tabell anger de programvaror som behöver vara installerade och tillgängliga för användaren.
 |
| Genom att använda Chrome så erhålls det nya underskriftsflödet per automatik. |
 |
| Krävs för inloggning till tjänsten, samt för att Testade versioner:
|
 |
| Ny autentiseringsklient som används vid legitimering vid underskrift i nya flödet. Används vid app-växlingen. Länk för nedladdning av autentiseringsklient
|
Anpassningar journalsystem
Nätverksåtkomst
I flödet för signering med Fristående Underskriftstjänst kommer användarens dator att kommunicera med fyra (4) olika tjänster/servrar. För att flödet ska fungera krävs det således att dessa tjänster går att nå från användarens dator.
...
För de som använder Webcert fristående , eller där integrationen sker genom att öppna Webcert i webbläsarens normalläge är detta vanligtvis inte ett problem, utan det är främst de som integrerar genom att öppna Webcert i en inbäddad webbläsare som måste kontrollera funktionalitet och rättigheter.
Ur ett användarperspektiv så är det följande som sker.
...
1: Användaren har loggat in i Webcert med SITHS-kort och har skrivit ett intyg som är klart att signera. Användaren klickar på |
 |
2: Webcert dirigerar användarens webbläsare till Underskriftstjänsten med information om den data som ska signeras. Ingen dialog visas för användaren (webbläsaren visar vit bakgrund). |
|
3: Underskriftstjänsten dirigerar användarens webbläsare till Ineras IdP med begäran om att legitimera användaren för underskrift. IdP’n visar en dialog och försöker samtidigt starta Det är i detta steg som den s.k. app-växlingen sker och där användarens webbläsare behöver ha rättigheter för att öppna program via protokollet Om Autentiseringsklienten inte startar automatiskt kan användaren klicka Notera att kravet gällande app-växling gäller oavsett om programmet öppnas per automatik eller genom att manuellt klicka på länken. |
 |
4:
En dialog visas för användaren med information om vad som ska signeras. Användaren anger sin PIN-kod för legitimering (PIN1) och klickar Autentiseringsklienten slutför legitimeringen av användaren och skickar informationen till Autentiseringsservern. |
 |
5: Användarens webbläsare dirigeras tillbaka till Webcert via Underskriftstjänsten. Webcert visar dialog med signerat intyg, eller felmeddelande om signering misslyckades. |
|
Teknisk beskrivning av app-växling
För att steg 3 och 4 i ovan flöde skall fungera så krävs det som sagt att webbläsaren har rättighet att starta det aktuella programmet.
Programmet startas genom att webbläsaren försöker öppna en länk som börjar på siths://. Detta är ett eget protokoll som är unikt för SITHS eID Autentiseringsklient. Vid installation så registrerar programmet att när någon försöker öppna en länk som börjar med siths://så är det just detta program som skall startas.
...
Följande ger en proof-of-concept på hur man kan tillåta SITHS-protokollet att exekvera/app-växla vid användning av CefSharp. Beskriv kort vad CefSharp är.
Givetvis skiljer sig implementationen mellan alla olika journalsystem, så nedan exempel är enbart tänkt som en fingervisning på hur det kan göras i just denna implementationen av inbäddad webbläsare.
...