0.9

2020-12-01

Marco de Luca

• Version för avstämning med projektets referensgrupper, piloter och styrgrupp. 

• Denna version har uppdaterats avseende:

  • Dokument upprättat

0.9 (2022)

2022-02-14

Marco de Luca

Revidering 2022

• Uppdatering för att inkludera

  • Aktiviteter som relaterar till O2O kryptering och signering

  • Inkludera rollen AP-operatör som ansvarar för Accesspunktsfunktion

• Inkluderat detaljerat exempel från dokument “Förmågor i Meddelandetjänst och övriga lokala SDK-komponenter”

1.0 (2022)

2022-02-28

Marco de Luca

Beslutad version för Tjänsten Säker digital kommunikation.

1.1 (2022)

2023-09-12

Marco de Luca

Uppdatering för att tydliggöra att komponenter bör kravställas att vara “öppna” för att minska risk för leverantörs inlåsning.

R1

Specifikation av validering, felhantering och kvittens

Specifikation av validering, felhantering och kvittens

R2

SDK Innehållsspecifikation - Meddelande

SDK Innehållsspecifikation - Meddelande

R4

SDKs Testinstruktioner för anslutningstester

SDKs Testinstruktioner för anslutningstester

R5

Säker digital kommunikation SAD

Säker digital kommunikation SAD

R6

Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga

Regelverk för anslutning

R9

SLA Tillgänglighet

/wiki/spaces/OISDK/pages/289118785

R10

SDK Adressbok Användarhandledning Administratör

Användarhandledning för administratörer i SDK Adressbok

R11

SDK Adressbok

Informationsmodell, kodverk och Sök-API.
/wiki/spaces/OISDK/pages/743528012716107264

R12

Meddelandespecifikation: Meddelandekvittens

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R14

Transportmodell - Utökad Bas

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R15

Transportprofil AS4

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R16

PKI för Accesspunkter Tjänstebeskrivning

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R17

Accesspunktsoperatör - Gemensamma Regler och Rutiner

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R18

Kuverteringsprofil XHE

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R19

Certifikatspublicering - REST-bindning till SMP

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R20

Plattform - Informationssäkerhet och tillitsmodell

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

Ta fram själv/Egen utveckling/Anpassa befintliga lösningar

• Användarorganistionen antar själv rollen AP-operatör

• Installera och konfigurera Accesspunkt själv, ta fram integrationslösning(Meddelandetjänst/meddelandeväxel) meddelandevalidering, meddelandekvittens och informationsutbyte med meddelandeklient/verksamhetssystem.

• Passar organisationer som har egen infrastruktur- och utvecklingskompetens.

• Har behov av skräddarsydda eller anpassade lösningar

• Har egen kompetens kring Integration med olika system

• Egen förmåga att drifta och förvalta lösningar.

Anskaffa komponenter

• Anskaffar Accesspunkt via AP-operatör.

• Anskaffa komponenter Meddelandetjänst/Meddelandeväxel och Meddelandeklient.

• Enkelt att anskaffa

• Förutsägbara kostnader

• Upphandlingsstöd saknas

• Lista med leverantörer som har fungerande komponenter saknas

Gå samman/gör tillsammans med andra

• finns här:

  • Anslutna leverantörer i SDK Öppen testmiljö (ÖTM) och leverantörer med godkänd mjukvara för MT/MK

• Användarorganisationen kan använda SDKs kravkatalog. Den är tänkt att utgöra ett stödjande material för anslutande organisationer vid anskaffning av de tekniska komponenter som behövs för anslutning till SDK.Kravkatalog för anskaffning

Gå samman/gör tillsammans med andra

• Organisationer kan gå samman och etablera Acesspunkt och SDK-Komponenter.

• Respektive användarorganisation representeras med eget organisations-id och certifikat. Information separeras logiskt på ett säkert sätt..

• Passar organisationer som redan samverkar kring IT-drift och verksamhetstjänster

• Stordriftsfördelar och dela på kostnader

Köpa som tjänst

• Köpa som tjänst (Software as a service - SaaS)

• Enkel paketerad lösning där ingen lokal drift eller förvaltning behövs

• Integration mot lokala verksamhetssystem kan vara utmanande.

Ansvarig för eDelivery transportinfrastruktur

I Sverige ansvarar Myndigheten för digital förvaltning, DIGG, för eDelivery transportinfrastruktur.

SDK-federationsägare

SDK-federationsägare ansvarar för federationen gentemot ansvarig för eDelivery transportinfrastruktur. SDK-federationsägare kan utse SDK-federationsoperatör. För närvarande är Inera både SDK-federationsägare- och operatör.

SDK-federationsoperatör

SDK-federationsoperatör är den organisation som förvaltar SDK och tillhandahåller SDKs gemensamma komponenter, miljöer och regelverk. För närvarande är Inera både SDK-federationsägare- och operatör.

Accesspunktsoperatör (AP-operatör)

Accesspunktsoperatör avser den roll som ansluter användarorganisationen till eDelivery transportinfrastruktur via en accesspunkt. En AP-operatör kan hantera många användarorganisationer.

Accesspunkt

Accesspunkten utgör respektive användarorganisations anslutningspunkt till eDelivery transportinfrastruktur.

Accesspunkten är den anslutningspunkt som en användarorganisation använder för att överföra meddelanden till andra användarorganisationer i SDK via eDelivery transportinfrastruktur. En Accesspunkt kan delas av användarorganisationer.

Användarorganisation

Användarorganisation avser den organisation som har anslutit eller har för avsikt att ansluta till SDK i syfte att överföra digitala meddelanden till andra användarorganisationer.

Användarorganisation i SDK motsvarar deltagare i eDelivery transportinfrastruktur.

Meddelandeklient/Verksamhetssystem

Användar-organisation

Meddelandeklienten eller verksamhetssystem är den komponent där verksamhetsprocessen och användarna finns. En användarorganisation har normalt kan ha många verksamhetssystem. Meddelandeklient/verksamhetssystem /meddelandeklienter.

En funktionsadress slutdestination är Meddelandeklienten.

Meddelandeklient/verksamhetssystem ansvarar för permanent lagring av information samt integrerar med SDK-federationen via Accesspunkt samt ansvarar för permanent lagring av informationdess Meddelandetjänst (MT).

Meddelandeklient behöver kunna söka I SDK Adressbok.

Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster.

L

Meddelandetjänst/ meddelandeväxel

Användar-organisation

Meddelandetjänst/Meddelandeväxel, hanterar integration mellan accesspunkt och meddelandeklienter. En användarorganisation har normalt en meddelandetjänst/meddelandeväxel men kan ha flera.

Komponenten ansvarar också för kryptering, dekryptering, signering och validering av signatur samt validering och kvittering av meddelanden.

Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Accesspunkter och Meddelandeklienter.

L

Accesspunkt

AP-operatör

En användarorganisation har normalt en (1st) accesspunkt som hanterar alla dess meddelandeutbyten inom SDK-federationen.

En Accesspunkt måste tillhandahållas av en rollen AP-operatör som regleras av DIGG.

En användarorganisation kan vara AP-operatör.

S

Accesspunkt validering

APKomponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster.

S

Accesspunkt validering

AP-operatör

En AP-operatörs Accesspunkt skall konfigureras enligt DIGGs ansvisningar och valideringsprocess

M

Adressbok (gemensam komponent)

SDK-federationsoperatör

Adressbok (Innehåll)

Användar-organisation

Behörig administratör underhåller funktionsadresser. Funktionsadressens tekniska adress behöver samordnas med meddelandetjänsten/meddelandeväxelns “routing”- funktion. Denna hanterar leverans av meddelande till funktionsadressens meddelandeklient/verksamhetssystem.

Funktionsadresser bör också kodas(kodverk) för att öka sökbarhet och möjliggöra strukturerad sökning av funktionsadresser. Se avsnitt SDK Adressbok för mer information.

M

SMP (gemensam Komponent)

DIGG Federationsoperatör (DIGG)

SMP/CertPub (AP metadata)

AP-operatör

Behörig användare underhåller metadata(Certifikat, URL till AP etc) för användarorganisationens AP.

Hanteras av AP-operatör via DIGGs ansvisninganvisning.

S

O2O-certifikat

• Anskaffa

• Registrera i CertPub(via anslutningsförfarande)

Användar-organisation

Certifikat för O2O-kryptering (Organisation till organisation) anskaffas från godkända certifikatsutgivare (Se Regelverk för anslutning R6.)

M

Uppfyllande av informationssäkerhetskrav och SLA

Användar-organisation (via självdeklaration)

Krav på användarorganisationen gällande informationssäkerhet och it-säkerhet.

• Inloggning och behörighetstilldelning

M

Informationslagring

• Temporär lagring(under leverans/transport)

Informationslagring

• Långtidslagring (ärende, ärendehistorik, meddelande)

Multifaktorsautentisering av personal

Behörighetsstyrning av personal

Autentisering integration

Transportkryptering (TLS)

Meddelandekryptering

Meddelande

AS4

Standardiserad mjukvara tillgänglig

Anpassning enligt DIGG krav krävs

Validering och kvittering av meddelande

Loggning

Routing

• Meddelandeklient/ funktionsadress

Koppling till Adressbok

Koppling till SMP/CertPub

Adapter (konnektorConnector)

En adapter används för att uppnå lös koppling (integration) mellan Accesspunkt och Meddelandetjänst /meddelandeväxelsom inte är produktspecifik. Denna komponent är inte standardiserat standardiserad av EU/CEF (byggblock eDelivery)CEF. Adaptern bör ha ett öppet tillgängligt API för att möjliggöra integration av olika leverantörers lösningar.

• Komponenten kan även ansvara för innehållsvalidering (Schema, Scheamtron)

• API eller meddelandekö

• för innehållsvalidering (Schema, Scheamtron)

• Kan vara ett API eller meddelandekö

Verifieras vid DIGGs anslutningstester för AP-operatör. Verifieras även indirekt via SDK Testbädd (QA) genom att meddelanden skickas, valideras och kvitteras med t.ex. Testklient.

Rekommenderade specifikationer:

• Transportprofil AS4 (Se ref R15)

• Accesspunktsoperatör - Gemensamma Regler och Rutiner (Se ref R17)

Hämta(lämna)

Komponent som löpande hämtar/lämnar meddelanden från accesspunkten. Det kan vara en meddelandekö, pollning eller hämtning baserat på notifiering.

Funktionalitet:

• Hämtar inkommande meddelanden från accesspunkt (Adapter)

• Lämnar utgående meddelanden

• Kontrollerar leveransstatus(meddelandestatus) på utgående meddelanden

Verifieras i SDK anslutningstester indirekt genom att meddelanden skickas, valideras och kvitteras.

Rekommenderade specifikationer:

• SDK Anslutningstester (Se ref R4)

Dekryptera, Validera

Komponenten dekrypterar, validerar signatur, validerar meddelandets struktur dvs kontrollera att meddelandet följer schema och regelverk(schematron).

• Dekryptera och validera signatur:

  • Dekrypterar meddelandet

  • Validerar avsändarens signatur

• Validerar meddelande enligt specifikation.

  • XML schema validering

  • XML Schematron validering

  • Söker efter skadlig kod, förhindrar skadlig kod

Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient.

Rekommenderade specifikationer:

• Sammanfattande dokument: Specifikation av validering, felhantering och kvittens (Se ref R1)

• SDK Innehållsspecifikation - Meddelande (Se ref R2)

• Transportmodell - Utökad Bas (Se ref R14)

• Kuverteringsprofil XHE (Se ref R18)

• Certifikatspublicering - REST-bindning till SMP (Se ref R19)

Status

Komponenten skapar ett sk kvitteringsmeddelande eller ett felmeddelande.

• Skicka kvitteringsmeddelande (ACCEPT, REJECT)

Persistens/lagring av meddelandet och meddelandets status under pågående transaktion.

• Meddelandestatus

• Omsändningsstatus

• Svarstidsbevakning

Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient.

Rekommenderade specifikationer:

• Meddelandekvittens (Se ref R12)

• SDK Anslutningstester (Se ref R4)

Vägval/”routing”

• Vägval och “routing”

  • Meddelandets funktionsadressens tekniska adress kan hämtas från en lokal katalogfunktion

  • Meddelande levereras till utpekad meddelandeklient/verksamhetssystem för funktionsadressen

Vägval/routing funktion bör stödja olika verksamhetssystem/Meddelandeklienter.

Verifieras EJ av Testklient (lokal hantering)

Skicka

• Paketering av meddelande

  • Kryptering och signering av SDK meddelande

  • Signering av Kvittensmeddelande

• Svarstidsbevakning av meddelanden (dvs SDK meddelandet skall enligt SLA kvitteras inom 15min för att anses vara levererat)

• Hanterar meddelandestatus för SDK meddelande(ej standardiserat)

  • Transportstatus/transportkvittens

Verifieras indirekt genom att Testklient skickar ett kvitteringsmeddelande.

Rekommenderade specifikationer:

• Sammanfattande dokument: Specifikation av validering, felhantering och kvittens (Se ref R1)

• SDK Innehållsspecifikation - Meddelande (Se ref R2)

• Transportmodell - Utökad Bas (Se ref R14)

• Kuverteringsprofil XHE (Se ref R18)

• Certifikatspublicering - REST-bindning till SMP (Se ref R19)

• Transportkryptering och autentisering

• Följsam till krav på inre säkerhet som är specificerat i IT-säkerhetsbilaga.

Verifieras EJ av Testklient (lokal hantering)

Krav specificerade i Inre säkerhet i dokumentet: IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet (Se ref R6).

Katalog

Katalogfunktion som innehåller funktioners tekniska adress etc. En funktionsadress behöver en teknisk adress för att kunna levereras till rätt meddelandeklient. I de fall det endast finns en Meddelandeklient kan denna komponent vara överflödig.

Meddelandestatus

Persistens/lagring av meddelandet under pågående transaktion.

• Meddelandestatus

• Svarstidsbevakning

Dekrypter, Validera

Applikation som validerar meddelanden.

• Dekryptera och validera meddelandets signatur (XHE)

• Schemavalidering (XSD)

• Schematronvalidering (SCH)

• Storleksvalidering

• Skydd mot skadligkod

• Duplikatkontroll, kontrollera att meddelande är unikt.

  • Kontroller att meddelandet är unikt och inte är en dubblett som redan är mottagen/hanterad.

• Verifiera funktionsadress mot SDK adressbok.

Vägval

Komponenten hämtar teknisk adress till den Meddelandeapplikation/verksamhetssystem som hanterar funktionsadress.

• Slår upp funktionsadress (hämtar teknisk adress).

Router/Skicka

Komponenten levererar meddelandet till Meddelandeklient/verksamhetssystem.

• Skicka/leverera

• Omsändning

• Felhantering

Adapter/konnektor

Anpassningskomponent mellan meddelandetjänst och komponenter som Accesspunkt eller Meddelandeklient/verksamhetssystem.

• Autentisering och auktorisering

• Komponenten kan även ansvara för validering (Schema, Schematron)

• API eller meddelandekö

• Integrerar mot Accesspunkt och verksamhetssystem/Meddelandeklienter

Meddelandeklient (verksamhetssystem)

Kravställer SDK i detalj hur en klient skall fungera?

• Funktionalitet

• Grafiskt gränssnitt

Nej

Finns stöd för klientsignering (person signera meddelandet som skickas)

Nej

Finns funktionalitet för att se om mottagaren har läst meddelandet?

Nej

Finns det funktionalitet för att se om meddelandet har levererats till mottagaren (användarorganisation)?

Ja

Får avsändaren ett felmeddelande om t.ex. mottagarens anslutning ligger nere?

Ja

Är det bara PDF som får bifogas i SDK meddelanden?

JaNej

Adressboken

Finns personer eller personal Adressboken?

Nej

Är det användarorganisationen som ansvarar för att underhålla adressuppgifter i adressboken

Ja

Kan man synkronisera adressboken med t.ex. HSA eller lokal katalog.

Nej

Hur hittar man rätt i adressboken? Finns det färdiga regler och kodverk för kodning av funktionsadresser?

Ja

Är all information i SDK adressbok öppet tillgänglig på internet?

Ja

Finns det ett öppet sök API till adressboken?

Ja

Kan man använda e-post i SDK?

Nej

Tekniska gränssnitt

Är APIer mellan Accesspunkt, meddelandetjänst och meddelandeklient standardiserade?

Nej

SDKs källkod

Delar Inera källkod för Testbäddens komponenter (Testklient, auktorisation)

Nej