eDelivery - Ny Arkitektur För Att Ersätta Faxen?

SKL/Inera projektet Säker digital kommunikation fick 2017 uppdraget att ”ersätta faxen”. Med detta initiativ kraftsamlar man för att adressera det faktum att det inte finns en gemensam säker kommunikationskanal mellan olika myndigheter i Sverige (det finns många icke kompatibla lösningar). Det har visa sig att myndigheter/kommuner lägger ned ofantligt mycket tid på telefonerande, brevskrivande och faxande. Ett ärende som tar några minuter att hantera kan ta månader att administrera på grund av avsaknad av gemensam arkitektur och infrastruktur och verktyg för säker kommunikation. Delivery som grund för säker kommunikation? Utifrån b.la. erfarenheter från PEPPOL* har CEF (Connecting Europe Facility) utvecklat byggblocket eDelivery som är en arkitektur och infrastruktur för säker informationsutbyte mellan organisationer. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/What+is+eDelivery+-+EU+legislation eDelivery är en arkitektur för kommunikation mellan distribuerade noder(organisationer) i ett säkert definierat nätverk. Arkitekturen stipulerar en sk fyra hörnsmodell vilket innebär att ett verksamhetssystemen (backend), hörn ett och fyra aldrig utbyter meddelanden direkt utan via lokal accesspunkter, hörn två och tre.

Källa: CEF building blocks. Varje organisation ansluter son ”AccessPoint” till nätverket. Backen utgör organisationens verksamhetssystem (e-post, ärendehanteringssystem)

Som jämförelse kan vi titta på SKL/Inera:s tjänsteplattform (NTjP) för informationsutbyte ”sammanhållen journal” där en central hub(accesspunkt) används dvs 3 hörnsmodell. Trehörnsmodell (Inera arkitektur med tjänsteplattform)

Bilden illustrerar övergripande hur Ineras arkitektur för informationsutbyte baseras på en sk 3 hörnsmodell. "Accesspunkt" representeras av en sk regional tjänsteplattform (RTP) eller tjänsteproducent.

Egenskaper: Varje organisations accesspunkt ansluts ”hårt” mot den centrala hubben (tjänsteplattformen). Hubben reglerar vem så får kommunicera med vem.

Informationsspecifikation (tjänstekontrakt) måste administreras samtliga tre hörn.

Fyrhörnsmodell (eDelivery)

Bilden illustrerar övergripande eDeliverys arkitektur för informationsutbyte baseras på en sk 4 hörnsmodell.

Egenskaper: Accesspunkt ansluts ”löst” federativ. Alla kan kommunicera med alla. Varje organisations publicerar vilken informationsmängd och version(jämför tjänstekontrakt) som kan tas emot. En fyrhörns arkitektur kräver mindre central administration samt skalar bättre än en trehörns modell. eDelivery:s fyrhörnsmodell använder DNS och SMP för att hitta anslutna organisationer. DNS administreras via en funktion som kallas SML och kan skötas centralt eller lokalt. Beroende på hur nätverket implementeras.

eDelivery är primärt utformad för asynkron informationsöverföring och består av följande delar: 1. Transport Infrastructure Service Metadata Locator (SML)     a. Komponenten ansvarar för att uppdatera DNS (CNAME eller NAPTR)     b. Varje organisations SMP registreras via denna komponent i DNS 2. DNS uppslag enligt BDX-Location-v1.0 (DNS)     a. Standard DNS     b. DNS används för att hitta mottagarens SMP och AccessPunkt. 3. Service Metadata Publisher (SMP)    a. Komponenten definierar vilka ”document type” samt vilken tekniks adress (URL organisationens accesspunkt har.   b. Innehåller även säkerhetsinformation för accesspunkt (certifikat) och information som krypteringskrav på payload nivå. 4. AccessPoint (AP)    a. Teknisk komponent för att skicka/ta emot meddelanden (dokument typer)    b. Komponenter integrerar sedan med respektive organisations bakomliggande verksamhetssystem (backend). 5. Payload: En meddelandespecifikation (documentType)    a. Meddelande som skickas mellan parterna 6. Backend (verksamhetssystem)  a. Meddelanden levereras till respektive organisations verksamhetssystem t.ex. e-post eller ärendehanteringssystem.

Varje organisation som deltar i nätverket ansvarar för Uppdatera de gemensamma komponenterna SML och DNS. Tillhandahålla egna SMP och AP (nätverket kan implementeras med en central SMP). Informationsöverföring sker med hjälp av SOAP och innehåller kodas enligt OASIS AS4 specifikationen som stödjer strukturerad XML samt filöverföring (t.ex. bilagor).

AS4 specifikationAS4 är en B2B OASIS standard som baseras på SOAP, MIME och WS-*. AS4 specifikationen (profil av ebMS) skapades 2013. Användningen av AS4 är numera stor och den kanske mest kända implementationen är i Europa är PEPPOL (order, faktura) och internationellt IATA (kommande standard för kommunikation mellan flygbolag och resebyråer).

AS4 stödjer olika typer av meddelandeformat (XML, JSON, binärfil etc).

Bilden illustrerar hur ett AS4 meddelande är uppbyggt. Övergripande meddelandestruktur MessageInfo: Innehåller tidsstämplar och meddelande-id

PartyInfo: Identifierar avsändare(From) och mottagare(To).

CollaborationInfo: Processinformation, åtgärder och id för att sammankoppla meddelande, definieras av nätverkets deltagare.

MessageProperties: Utrymme för att utöka meddelandet, definieras av nätverkets deltagare.

PayloadInfo: Referens till meddelandet (SOAP Body eller WS-Attachment) Här specificeras även vilken typ av information som skickas (XML schema, MIME type).

SOAP Body: Utrymme för meddelande.

MIME Parts: Utrymme för meddelande.

Kryptering och signering av meddelanden är möjlig.

Övergripande tekniskt flöde

Bilden illustrerar hur ett meddelande skickas. Sändande AP hittar mottagande organisations AP genom DNS och SMP anrop.

Flöde: Ett verksamhetssystem t.ex. verksamhetssystem skapar ett meddelande som är adresserat till en organisation inom eDelivery nätverket. Adressering t.ex. via en adressbok (hanteras utanför standarden).

1. Ett adresserat meddelande skapas i sändande organisations accesspunkt.AccessPunkt frågar DNS var mottagande organisations SMP tjänst finns 2. Accesspunkten hämtar information från SMP så som meddelandeformat (dokument typ) som stöds samt vilken teknisk adress URL mottagarens accesspunkt har. Säkerhetsinformation så som certifikat för att identifiera mottagaren finns också.

Meddelande skickas via SOAP till mottagande organisations accesspunkt.

Ansluta verksamhetssystem (Backend) Varje organisation väljer själv vilka system som skall kunna skicka och ta emot meddelanden i nätverket. Det kan t.ex. vara ett ärendehanteringssystem, e-postsystem eller en enkel webbklient för att läas och skicka meddelanden.

eDelivery reglerar inte hur verksamhetssystem internt skall kommunicera med sin Accesspunkt(AP).

eDelivery är en öppen standard finns både licensierade och öppenkällkods produkter tillgängliga på marknaden (Se https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+conformant+solutions).

Strategiska frågor vid etablering av eDelivery

Även om eDelivery och AS4 är etablerade standard så behöver varje nätverk som etableras fatta ett antal strategiska beslut.

Några exempel:

Hur skall säkerheten lösas mellan nätverkets noder. Standarden stödjer WS-S vilket t.ex. medger standard PKI som t.ex. SITHS eller Efos.

Hur skall organisationer inom nätverket adresseras? Standarden stipulerar följande:ISO 6523 (organization identification scheme) Här finns kod för t.ex. organisationsnummer. ISO 9735 (UN/EDIFACT syntax)ISO 20022 (Universal financial industry message scheme) Eget kodverk via ”Unregistred”.

Behövs en gemensam adressbok för verksamhetsadressering? eDelivery stödjer endast adressering på organisationsnivå.

Vilka dokument typer skall kunna utbytas? Ett meddelandeformat behöver tas fram (jämför RIV-TA tjänstekontrakt). Valfri MIME typ kan användas. Då eDelivery primärt används för asynkrona flöden kommer ett regelverk för meddelandevalidering behöva tas fram. Separata regelverk för meddelandeflöden och felhantering bör tas fram

Reflektioner:

- Varje organisation måste ansluta och anpassa sina system för att kunna skicka meddelanden i nätverket.

- Det finns dock utrymmer för marknaden att bygga SaaS tjänster för att underlätta anslutning och användandet för organisationer.

- eDelivery baseras på det ”omoderna” SOAP protokollet

- Protokollet är primärt utformat för asynkron hantering

- Meddelandevalidering sker inte av accesspunkten utan behöver hanteras av bakomliggande verksamhetssystem (backend)

- Alla kan skicka till alla inom ett eDelivery nätverk.