Specifikation av validering, felhantering och kvittens

Figur illustrerar SDKs referensmodell för säker meddelandeöverföring och dess gränsytor. Se en större variant av bilden. png, 67.6 kB.

2.1 Principer för validering

• Validera och kontrollera så tidigt som möjligt i kedjan, där det finns störst möjlighet att åtgärda eventuella fel.
  
• Gör det lätt för användaren i verksamhetssystemet (meddelandeklienten) att göra rätt från början, t.ex. genom att kontrollera att bifogade filer har rätt typ, att kontrollera format på inmatade värden i meddelandefält o.s.v.
  
• Det ska finnas skydd mot skadlig kod i nyttolast. Skyddet kan implementeras i Meddelandeklient (MK), Meddelandetjänst (MT) eller motsvarande. Om skadlig kod upptäcks ska, om möjligt, ett felmeddelande skickas åter till avsändaren. Skalskydd i form av antivirussystem bör förhindra vidare hantering genom att t.ex. sätta meddelandet i "karantän".
  
• Om skadlig kod upptäcks ska, om möjligt, ett felmeddelande skickas åter till avsändaren. Skalskydd i form av antivirussystem bör förhindra vidare hantering genom att t.ex. sätta meddelandet i "karantän".
• Både avsändare och mottagare har ansvar för validering mot gemensamma regler, t.ex. kontroll av meddelandeformatet, adressering, skanning av skadlig kod, e.t.c.
  
• Separera ansvar för transportvalidering till transportlagret (eDelivery) och innehållsvalidering till meddelandelagret (SDK), undantaget kontroll av adressering för att säkerställa säker mottagare och säker avsändare.
  
  Motiv: Detta gör transportlagret återanvändbart för flera typer av meddelandeöverföringar. Transportlagret ska inte behöva ha mer än nödvändig kunskap om den aktuella nyttolasten. Detta medger också att lägga in tillämpningsspecifik validering anpassad för olika meddelandetyper utan att påverka tekniken i transportlagret. T.ex. kan vissa meddelanden kräva tyngre validering, vilket då inte påverkar transportlagrets förmåga att sända och ta emot. Det ger även större möjlighet att testa och verifiera nya valideringsregler i meddelandelagret innan dessa sätts i produktion.
  

2.2 Principer för kvittens av mottagen leverans

• Transportkvittenser skickas som signalmeddelanden efter att validering utförts av mottagarens accesspunkt. Detta är en del av eDelivery AS4-specifikationen, se Transportprofil AS4 och sker per automatik av en godkänd accesspunkt.
  
• Transportkvittens på "överfört meddelande" sker synkront i transportlagret, dvs. sändande accesspunkt får direkt en kvittens från mottagande accesspunkt att överföringen lyckats på transportnivå.
• Meddelandekvittensen för ”meddelande mottaget” sker asynkront i meddelandelagret (MT), vilket medger att hantera meddelandelasten via ett kösystem för bättre skalbarhet i systemet. Meddelandekvittenser ska följa Meddelandespecifikation: Meddelandekvittens.
  
• Kvittenser innehåller alltid ett korrelations-id som sätts till meddelande-id för meddelandet som kvittensen, alternativt felmeddelandet, avser. Därmed är varje kvittens unikt spårbar till vilket meddelande som har kvitterats.
• Ett meddelande anses levererat när avsändaren erhåller Meddelandekvittens för ”meddelande mottaget” (ACCEPTED) i meddelandelagret.

3. Ansvar för validering, felhantering och kvittens

Robust meddelandeöverföring via SDK bygger på följande ansvarsfördelning mellan meddelande- respektive transportlager.

3.1. Meddelandelagret - Meddelandetjänst (Meddelandeväxel)

Meddelandetjänsterna i meddelandelagret ansvarar för:

Validering av meddelande

• Meddelandets (nyttolast) adressering valideras mot transportlagrets (AS4) adressering. Detta för att kontrollera meddelandets ursprung.
  
• Meddelandekuvertets struktur och i förekommande fall innehåll (kodverksregler e.t.c.) valideras.
  
• Validering görs både före sändning och efter mottagning i meddelandelagret hos avsändare respektive mottagare. I normalfallet stoppas därmed ev. fel tidigt, och vid ev. felkonfiguration hos en avsändande part, kan fel fångas upp hos mottagaren innan det går vidare in till meddelandeklient (verksamhetssystem).
• I normalfallet stoppas därmed eventuella fel tidigt, och vid eventuell felkonfiguration hos en avsändande part, kan fel fångas upp hos mottagaren innan det går vidare in till meddelandeklient (verksamhetssystem).

I normalfallet stoppas därmed eventuella fel tidigt, och vid eventuell felkonfiguration hos en avsändande part, kan fel fångas upp hos mottagaren innan det går vidare in till meddelandeklient (verksamhetssystem).

Meddelandekvittens/felhantering

Skickas asynkront efter validering i mottagande meddelandelager och påvisar att överföringen har accepterats av mottagarens meddelandetjänst (mottaget meddelande - ACCEPTED), alternativt att något fel inträffat hos mottagaren (ej mottaget meddelande - REJECTED).

Följande principiella fall finns:

• Om meddelandet mottagits utan avvikelser, ska meddelandekvittens med status ACCEPTED skickas tillbaka till avsändaren (mottaget meddelande).
• Om meddelandet mottagits med stoppande avvikelser, ska meddelandekvittens med status REJECTED skickas tillbaka till avsändaren. Felmeddelandet ska även innehålla kodad information om felets art.
  

Svarstidsbevakning på avsändarens meddelandelager

• Fångar upp uteblivna svar (meddelandekvittens) p.g.a tekniskt fel, nätverksproblem el. dyl.
• Gemensamma regler för svarstider tillämpas enligt fastslagen SLA inom federationen, se bilaga för tillgänglighet inom SDK.
  

Spåra och övervaka på meddelandenivå
I meddelandelagret realiseras funktioner för att se status för meddelandeöverföringen, t.ex.

• Meddelande klart för att skickas till Accesspunkt (SCHEDULED)
• Meddelande skickat till Accesspunkt (SUBMITTED)
• Meddelandet har transportkvitterats av mottagande Accesspunkt (ACKNOWLEDGED)
• Meddelandet har inte kunnat levereras till mottagande Accesspunkt, ett problem har uppstått (MESSAGE_EXCHANGE_ERROR)
• Meddelande kvitterat (ACCEPTED)
• Meddelande kvitterat med stoppande fel. Meddelandet har ej levererats till avsedd mottagare (REJECTED)

3.2 Transportlagret – Accesspunkt

Accesspunkterna i transportlagret utför validering enligt Diggs krav på AP-operatörer, se Accesspunktsoperatör – gemensamma regler och rutiner.

Omsändning definieras genom en total omsändningsperiod och antal försök som genomförs under den perioden.

Omsändning:

• En accesspunkt ska göra omsändningar enligt fastslagen SLA inom federationen enligt SDK-federationens anpassningar mot plattform för eDelivery och Bilaga för tillgänglighet inom SDK
  

4. Detaljering av validering, felhantering och kvittens

Bilden visar modell för robust meddelandeöverföring, validering, felhantering och kvittens. Se en större variant av denna bild här. png, 135.8 kB.

Avsändare (C1)

Steg: Initiera meddelande-överföring

Aktör

Verksamhetslager - Meddelandeklient/Verksamhetssystem

Aktivitet

Observera regelverk:

SKA hantera meddelandestatus

• Transportkvittens (från mottagande accesspunkt)
• Meddelandekvittens (från mottagande meddelandetjänst)
  

Skydd mot skadlig kod kan finnas i Meddelandeklient/verksamhetssystem, Meddelandetjänst eller motsvarande.

Steg: 1. Skapa meddelande

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelande SKA skapas enligt en godkänd meddelandtyp (bilaga för meddelandetyper), t ex SDK Innehållsspecifikation Meddelande.

Meddelandet paketeras (kuverteras) enligt specifikation eDelivery - Kuverteringsprofil XHE.

Observera regelverk:

• SKA använda tillförlitlig källa för adressering. Mottagande användarorganisation och dess funktionsadress SKA hämtas från
• SDK Adressbok (direktintegration via Sök-API)
  Kvalitetssäkrad läskopia

Hantering av meddelande-id och konversations-id, se även specifikation:

• SDK Adressbok API dokumentation

Steg: 2. Schemavalidering

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelandepaketering (kuvert) SKA valideras enligt eDelivery - Kuverteringsprofil XHE.

Meddelandet(nyttolast) SKA valideras enligt meddelandetypens specifikation, t ex SDK Innehållsspecifikation – Meddelande.

• Meddelandet schemavalideras programmatiskt (t ex xsd)
• Meddelandets regelverk valideras programmatiskt med fastslagna valideringsskript (schematronvalidering).
  

Observera regelverk:

• SKA endast skicka meddelanden som passerat validering.
  

Steg: 3. Innehållsvalidering

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelandet kontrolleras:

• Skydd mot skadlig kod kan finnas i Meddelandeklient/verksamhets-system, Meddelandetjänst eller motsvarande.
  

Observera regelverk:

• Meddelandetypens regelverk SKA kontrollera meddelandets storlek
  

Se specifikation:

• SDK Innehållsspecifikation – Meddelande, se bilaga SDK Innehållsspecifikation Meddelande

Steg: Kryptera och signera meddelande

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelandelager - Meddelandetjänst

Meddelandet SKA krypteras och signeras.

Mottagande deltagarorganisations publika nyckel SKA hämtas från Certifikatspublicering enligt Certifikatspublicering REST bindning till SMP,

• Kontrollera att metadata där publik nyckel ingår är signerad av betrodd part.
• Spärrkontroll av mottagarens publika nyckel.
  

Se specifikation:

• Transportmodell - Utökad Bas med signering och kryptering
• Kuverteringsprofil XHE
• Certifikatspublicering - REST-bindning till SMP
• Bilaga för IT-säkerhet inom SDK, se avsnitt “Certifikat för O2O-kryptering och signering av meddelanden – skydd vid meddelandeöverföring mellan deltagarorganisationer“

Steg: Sänd meddelande

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelandet överför meddelandet till accesspunkt för distribution till mottagaren.

Meddelandetjänst:

SKA hantera meddelandestatus

• Transportkvittens (från mottagande accesspunkt) dvs meddelandet är levererat till mottagarens accesspunkt.
• Svarstidsbevakning (enligt definierad SLA, se Bilaga för tillgänglighet inom SDK) sker till dess meddelandekvittens mottagits.
• Vid uteblivna kvittenser skall felmeddelande returneras till meddelandeklient.

Avsändarens AP-operatör (C2)

Aktör

Accesspunkt

Aktivitet

AP-operatör SKA validera meddelandet enligt Diggs specifikationer för AP-operatörer.

Se specifikation:

• Transportprofil AS4
• Accesspunktsoperatör - Gemensamma Regler och Rutiner (Observera regel för omsändning som specificeras i SDKfederationens anpasningar mot plattform eDelivery)

Mottagande AP-operatör (C3)

Aktör

Accesspunkt

Aktivitet

AP-operatör SKA validera meddelandet enligt Diggs specifikationer för AP-operatörer.

Se specifikation:

• Transportprofil AS4
• Accesspunktsoperatör - Gemensamma Regler och Rutiner

Mottagare (C4)

Schemavalidering

Steg: Validera signatur och dekryptera meddelande

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Meddelandetjänst:

Meddelandets signatur SKA valideras. Sändande (C1) deltagarorganisations publika nyckel hämtas från Certifikatspublicering.

• Kontrollera att metadata där publik nyckel ingår är signerad av betrodd part.
• Spärrkontroll av sändarens (C1) publika nyckel.
• Validering av signatur är också en del av SDK:s ursprungskontroll, se Innehållsvalidering enligt punkt 5 nedan.
  

Se specifikation:

• Transportmodell - Utökad Bas med signering och kryptering
• Kuverteringsprofil XHE
• Certifikatspublicering - REST-bindning till SMP

Steg: Schemavalidering

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Tillämpar validering enligt Schemavalidering, se punkt 2 ovan.

Steg: 5. Innehållsvalidering

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Tillämpar validering enligt Innehållsvalidering, se punkt 3 ovan.

Ursprungskontroll

• Sändarens(C1) organisations-id verifieras genom kontroll av meddelandets signatur.
• Signatur kontrolleras mot publik nyckel registrerad i Certifikatspubliceringstjänst.
• Verifiera att sändande organisations-id är korrekt i kuvert och nyttolast (AS4, XHE och SDK Meddelande) och enligt meddelandetypens specifikation.

T.ex. SDK meddelande: Ett filformat (bifogad fil) som ej stöds ska kvitteras (REJECTED).

Se specifikation:

• Bilaga för meddelandetyper i SDK
• Transportmodell - Utökad Bas med signering och kryptering.
• Kuverteringsprofil XHE
  

Steg: Sänd meddelande-kvittens

Aktör

Meddelandelager - Meddelandetjänst

Aktivitet

Efter genomför validering och kontroller SKA meddelandetjänst skicka meddelandekvittens alternativt felmeddelande.

• Om meddelandet mottagits utan avvikelser, ska meddelandekvittens med status ACCEPTED skickas tillbaka till avsändaren (mottaget meddelande).
• Om meddelandet mottagits med stoppande avvikelser, ska meddelandekvittens med status REJECTED skickas tillbaka till avsändaren. Felmeddelandet ska även innehålla kodad information om felets art.

Se specifikation:

• Meddelandespecifikation: Meddelandekvittens

Steg: Initiera intern behandling av meddelande

Aktör

Verksamhetslager - Meddelandeklient/Verksamhetssystem

Aktivitet

Meddelandeklient/Verksamhetssystem

• SKA hantera meddelande enligt meddelandetypens specifikation.

Se specifikation:

• Meddelandespecifikation: Meddelandekvittens