1 Bakgrund
2 Förutsättningar
- 2.1 SITHS-kort
- 2.2 Programvaror
- 2.3 Nätverksåtkomst
- 2.4 App-växling
  - 2.4.1 Nya underskriftsflödet
  - 2.4.2 Teknisk beskrivning
  - 2.4.3 Exempelkod för inbäddad webbläsare
3 Test
4 Vanliga frågor

Bakgrund

Tidigare använde Webcert en funktion för att signera intyg med SITHS-kort via NetID från Secmaker men som tyvärr bara fungerade med Internet Explorer. Därför har en nytt underskriftsflöde introducerats i Webcert, som erbjuder signering genom fristående underskriftstjänst, med huvudsyfte att möjliggöra för underskrifter i andra webbläsare än Internet Explorer.

En stor skillnad gentemot signering med NetID är att underskriften inte sker med det signerings-certifikat, PIN-kod för underskrift (PIN2), som användaren har på sitt SITHS-kort. Istället legitimerar sig användaren, PIN-kod för legitimering (PIN1), 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.

Det nya underskriftsflödet har ersatt den underskrift som tidigare kunde göras i Internet Explorer via NetID. Åtgärder som anges nedan är därmed krav för de som nyttjar detta nya underskriftsflöde för att tillgängliggöra Webcert i Chromium-baserade webbläsare.

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:

SITHS-kort: Behöver innehålla certifikat med rätt LoA-nivå.
Programvaror: Användarens dator behöver ha rätt programvaror.
Nätverksåtkomst: Användarens dator behöver ha nätverksåtkomst till de ingående komponenterna (servrarna) i flödet.
App-växling: Användare av Webcert via en så kallad inbäddad webbläsare (via ett journalsystem), behöver kontrollera att deras lösning kan hantera app-växling via protokollet siths://.

SITHS-kort

Nedanstående tabell anger de krav som finns kring SITHS-kort.

Level of Assurence (LoA)

Den nya underskriftstjänsten stödjer SITHS-kort med certifikat som har tillitsnivåerna LoA 2 och LoA 3.

Programvaror

Nedanstående tabell anger de programvaror som behöver vara tillgängliga för användaren.

Chrome

Edge Chromium

Genom att använda Chromium-baserade webbläsare så erhålls det nya underskriftsflödet per automatik.

I dagsläget är flödet testat med Chrome och Edge Chromium.

SITHS eID Windowsklient

Ny autentiseringsklient som används vid legitimering vid underskrift i nya flödet. Används vid app-växlingen. OBS! För att köra mot Test behövs en testklient installeras. Länk för nedladdning av SITHS eID Windowsklient

Första gången ett SITHS-kort används med SITHS eID Windowsklient behöver det registreras innan användning. När SITHS eID Windowsklienten startas första gången tas användaren automatiskt vid behov till registreringsflödet. Där efterfrågas användarens legitimeringskod.

För mer information se avsnitt Registrera kort i Användarhandbok – SITHS eID Windowsklient

Nätverksåtkomst

I flödet för signering med fristående underskriftstjänst kommunicerar användarens dator 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.

Tjänst/Server	Beskrivning	Adress

Tjänst/Server	Beskrivning	Adress
Webcert	Användaren loggar in i Webcert med sin webbläsare.	Produktion: `https://webcert.intygstjanster.se` Test: Flera miljöer finns tillgängliga beroende på aktör, syfte och version.
Fristående underskriftstjänst	Användarens webbläsare ansluter till denna tjänst i flödet.	Produktion: `https://esign.v2.signatureservice.se` Test: `https://esign.v2.st.signatureservice.se`
IdP för legitimering vid underskrift	Användarens webbläsare ansluter till denna tjänst i flödet.	Produktion: `https://idp.inera.se` Test: `https://idp.ineratest.org`
Server för autentiseringsklient	`SITHS eID Windowsklient` ansluter till denna server i flödet	Produktion: `https://mobiltsiths.inera.se` Test: `https://mobiltsiths.ineratest.org`

App-växling

Den nya underskriftfunktionen som är tillgänglig i Webcert använder s.k. app-växling för att öppna det program där användaren anger sin PIN-kod för legitimering (PIN1). Detta är en ny autentiseringsklient som tagits fram inom SITHS. Vidare i texten kommer denna benämnas SITHS eID Windowsklient

Om man ser till användarflödet så är de flesta redan vana vid denna typ av app-växling, då det vanligtvis sker på samma sätt när man använder BankID eller Mobilt BankID. Dvs användarens webbläsare är ansvarig för att öppna det program där PIN-koden skall anges.

För att detta skall fungera ur ett tekniskt perspektiv är det således ett krav att webbläsaren har rätt behörighet för att utföra denna åtgärd, dvs öppna ett annat program.

För de som använder Webcert fristående är detta inte ett problem, utan det är de som integrerar genom att öppna Webcert i en inbäddad webbläsare som måste kontrollera funktionalitet och rättigheter.

Nya underskriftsflödet

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 Windowsklient`på 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 `SITHS eID Windowsklient` inte startar automatiskt kan användaren klicka `Starta SITHS eID på denna enhet`fö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 Windowsklient`startas 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`. `SITHS eID Windowsklient` 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

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 Windowsklient. 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.

Om man använder Devtools i webbläsaren så kan man se hur länken anropas:

Det är i detta steg som det kan ta stopp i en inbäddad webbläsare. Dessa kan ha begränsade rättigheter vilka hindrar de från att öppna externa program. På grund av detta behöver de som använder inbäddade webbläsare kontrollera med sina leverantörer att detta steg fungerar.

Exempelkod för inbäddad webbläsare

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 (CefSharp är baserat på Chromium Embedded Framework och kan användas för att integrera en webbläsare i en C#-applikation).

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.

Det viktigaste i exemplet är den anpassade ResourceRequestHandler som tillåter protokollet siths men inget annat protokoll. Denna funktion anropas för alla protokoll som är okända, innan de tillåts.

class CustomResourceRequestHandler : ResourceRequestHandler
{
    protected override bool OnProtocolExecution(IWebBrowser chromiumWebBrowser, IBrowser browser, IFrame frame, IRequest request)
    {
        Uri uri = new Uri(request.Url);
        if (uri.Scheme == "siths")
        {
            return true;
        }
        return false;
    }
}

// Här skapas en factory-klass som returnerar en custom implementation av ResourceRequestHandlerFactory
public class CustomResourceRequestHandlerFactory : IResourceRequestHandlerFactory
{
    public bool HasHandlers => true;    public IResourceRequestHandler GetResourceRequestHandler(IWebBrowser chromiumWebBrowser, 
    IBrowser browser, IFrame frame, IRequest request, bool isNavigation, bool isDownload, string requestInitiator, ref bool disableDefaultHandling)
    {
        return new CustomResourceRequestHandler();
    }
}

// och slutligen pekas denna factory-klass ut för browser-instansen
var browser = new ChromiumWebBrowser(<url till den sida som webbläsaren ska inbädda>)
{
    ResourceRequestHandlerFactory = new CustomResourceRequestHandlerFactory()
};
panel.Controls.Add(browser);

Test

SITHS eID Windowsklient kan testas på följande sidor.

Miljö	Länk

Miljö	Länk
Produktion	https://test.idp.inera.se/
Test	https://test.idp.ineratest.org/

Vanliga frågor

Behöver vi göra en beställning för att börja använda Webcerts nya underskriftslösning?

Nej, ingen separat beställning behövs.

Hur kommer vi i igång med den Webcerts nya underskriftslösning?

För att erhålla det nya underskriftsflödet behöver ni:

installera SITHS eID Windowsklient på alla lokala klienter
byta ut IE11 mot Chrome eller Edge Chromium. Gäller även inbyggda webbläsare i journalsystemen.
om ni använder NetiD, säkerställ att ni har den senaste versionen. Ny version av Net iD Enterprise - Inera

Krävs det att man har de nya SITHS-korten för att använda Webcerts nya underskriftslösning?

Nej, underskriftslösningen fungerar med både ”gamla” SITHS-kort och ”nya” SITHS-kort (940).

En rekommendation är att ni med Citrix-miljöer på Windows Server 2016 och äldre
går in i SIT2 för att testa underskriftslösningen.

Öppen info: Intygstjänster

Webcert integrerat - signera intyg i Chrome och Edge Chromium