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.
...
| 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.
...
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 baserat på Chromium Embedded Framwork 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.
...
| Kodblock |
|---|
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;
}
}
|
| Kodblock |
|---|
// 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(); } } |
| Kodblock |
|---|
// och slutligen pekas denna factory-klass ut för browser-instansen. var browser = new ChromiumWebBrowser("https://enrollment.preacctest.ineratest.org") { ResourceRequestHandlerFactory = new CustomResourceRequestHandlerFactory() }; panel.Controls.Add(browser); |