Checklista för anpassning av anslutande meddelandesystem till SDK

Anslutning för deltagarorganisationer
Sidkod: A2.8
Version: 1.5

Sammanfattande information och principer för leverantörer av meddelandesystem (meddelandeklient och meddelandetjänst) som planerar anslutning till Säker digital kommunikation (SDK).

1. Syfte

SDK är en säker transportinfrastruktur för asynkron punkt-till-punkt (meddelande levereras direkt till mottagarens accesspunkt) arkitektur som bygger på Diggs plattform för eDelivery (baserad på CEF eDelivery). För att etablera SDK-förmåga inom en deltagarorganisation behöver IT-stöd anpassas och en eller flera klienter/verksamhetssystem behöver anslutas.

Accesspunkt (AP):

  • En accesspunkt är en standardiserad mjukvara som anpassas enligt Diggs tekniska specifikationer.
  • “AP-operatör är den part som tillhandahåller accesspunkt till en eller flera deltagarorganisationer i enlighet med SDK:s regelverk och avtal (en accesspunkt kan delas).
  • En AP-operatör kan vara deltagarorganisationen själv eller en extern leverantör.
  • En accesspunkt ska ha ett öppet tillgängligt API för att kunna integrera med olika meddelandetjänster.

Meddelandetjänst (MT):

  • En integrationskomponent för att hantera meddelandeflöden mellan accesspunkt och meddelandeklienter/verksamhetssystem. En deltagarorganisation kan ha en meddelandetjänst.
  • Dekrypterar, krypterar, signerar och validerar signatur på SDK-meddelanden.
  • Validerar och kvitterar meddelanden (meddelande mottaget).
  • Validerar giltig avsändare och mottagare mot SDK adressbok.
  • Ansvarar för att leverera meddelandet internt inom deltagarorganisationen.
  • En meddelandetjänst ska ha ett öppet tillgängligt API för att kunna integrera med olika accesspunkter och meddelandeklienter.

Meddelandeklient/Verksamhetssystem (MK):

  • Representerar ett verksamhetssystem där användaren finns.
  • Meddelandeklienten behöver anpassas för att kunna hantera SDK-meddelanden och kvittenser.
  • Meddelandeklienten ska ha ett öppet tillgängligt API för att kunna integrera med olika meddelandetjänster.
  • Söker mottagare i SDK Adressbok

Mål: Stödja en deltagarorganisation som ska etablera SDK-förmåga. Dokumentet lyfter fram områden som behöver utredas och vägval som behöver göras.

Checklistan är framtagen för att stödja deltagarorganisationer gällande vägval som behöver göras eller utredas för att etablera lokal SDK-förmåga från meddelandeklient/verksamhetssystem till accesspunkt.

Dokumentet avhandlar den del av IT-stöd och lokal infrastruktur som inom eDelivery betecknas som backend, dvs. mellan meddelandeklient/meddelandetjänst och accesspunkt

1.1 Målgrupp

Personer som ska genomföra förstudier eller analyser av behov och ta fram lösningsförslag för att etablera lokal IT-förmåga för SDK-anslutning.

  • Lösningsarkitekter
  • Projektledare/utredare

1.2 Dokument

Nedan listas ett urval av dokumentation och specifikationer som är relevanta vid anpassning av lokala komponenter för utbyte av SDK meddelanden.

Övergripande arkitektur

Implementationsnära specifikationer:

Regler och informationssäkerhet

2. Sourcingstrategi SDK förmåga (vägval för etablering)

Regelverket för deltagarorganisationer inom SDK är framtaget för organisationer som har för avsikt att ansluta till SDK och specificerar de säkerhetskrav som ställs på anslutna aktörer till SDK.

Vid tillämpning av regelverk och specifikationer finns det frihet när det gäller hur krav skall implementeras. Det finns en hel del vägval som anslutande deltagarorganisationer behöver överväga.

Vägval för deltagarorganisation



Accesspunkt via AP-operatör

Meddelandetjänst (meddelandelager)

Meddelandeklient (verksamhetslager)

  • Ta fram själv/anpassa
  • Anskaffa
  • Gemensam anskaffning
  • Ta fram själv/anpassa
  • Anskaffa
  • Gemensam anskaffning
  • Ta fram själv/anpassa
  • Anskaffa
  • Gemensam anskaffning


Alternativ som bör övervägas

Kommentar

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

  • Deltagarorganistionen antar själv rollen som AP-operatör.
  • Installera och konfigurera egen accesspunkt, ta fram integrationslösning (meddelandetjänst) meddelandevalidering, meddelandekvittens och informationsutbyte med meddelandeklient/verksamhetssystem.
  • Fördel: Passar organisationer som har egen infrastruktur- och utvecklingskompetens
  • Fördel: Har behov av skräddarsydda eller anpassande lösningar
  • Fördel: Har egen kompetens kring integration med olika system
  • Fördel: Har egen förmåga att drifta och förvalta lösningar

Anskaffa komponenter

  • Anskaffar accesspunkt via AP-operatör.
  • Anskaffa komponenter meddelandetjänst och meddelandeklient.
  • Fördel: Enkelt att anskaffa
  • Fördel: Förutsägbara kostnader
  • Fördel: Lista med leverantörer som har utfört tester i OPEN-TEST med godkänt resultat (kontakta sdk@digg.se)

Gå samman/gör tillsammans med andra

Organisationer kan gå samman och etablera accesspunkt och SDK-komponenter.

  • Respektive deltagarorganisation representeras med eget organisations-ID och certifikat. Information separeras logiskt på ett säkert sätt.
  • Fördel: Passar organisationer som redan samverkar kring IT-drift och verksamhetstjänster
  • Fördel: Stordriftsfördelar och man kan dela på kostnader.

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

  • Fördel: Enkel pakterad lösning där ingen lokal drift eller förvaltning behövs
  • Nackdel: Integration mot lokala verksamhetssystem kan vara utmanande.

3. Anskaffa helhetslösning eller anskaffa/utveckla olika delar

Kapitlet beskriver vilka vägval som kan bli aktuella för en deltagarganisation.

Oavsett anskaffningsstrategi är meddelandetjänst en strategisk komponent då den är central för en deltagarrorganisations meddelandeutbyte mellan en/flera meddelandeklient (-er)/verksamhetssystem och accesspunkt för vidare distribution inom SDK-federationen.

3.1 Helhetslösning

En helhetslösning innebär att accesspunkt, meddelandetjänst och meddelandeklient paketeras tillsammans. SDK-förmåga levereras och administreras som en tjänst.

En helhetslösning passar sannolikt organisationer som önskar anskaffa SDK-förmåga snabbt samt bedömer att en separat dedikerad klient passar verksamhetens behov.

Anskaffa lokala komponenter eller köpa som tjänst (Software as a service - SaaS) passar organisationer som önskar enkel paketerad lösning som inte kräver lokal drift eller förvaltning.

Viktiga vägval:

Fördelar

  • Snabb anskaffning av SDK-förmåga.
  • En fristående klient kan användas av alla i organisationen.
  • Enkel anslutning till SDK-federationen.
  • Enklare administration då leverantören tar driftansvar för alla komponenter. Alla delar levereras och administreras som en tjänst.

Nackdelar

  • Separat klient för meddelandeutbyte, dvs ytterligare ett system för användarna.
  • Om ytterligare meddelandeklienter/verksamhetssystem behöver integreras kan stöd saknas eller behöva hanteras som ett tillägg. Anslutning till ytterligare meddelandeklienter/verksamhetssystem kan bli kostsam.
  • Information, t ex i bilagor (PDF eller annat format) måste importeras/exporteras mellan systemen.
  • Hantering av ärendehistorik och beslut om slutlagring eller gallring av dokumentation.

Rekommendation

Även om en helhetslösning anskaffas är det viktigt att säkerställa att komponenter levereras med öppna API:er som möjliggör att komponenter kan bytas ut eller utökas. Komponenter bör levereras med ett öppet tillgängligt API som möjliggör byte av accesspunkt, meddelandetjänst och meddelandeklienter, se Rekommendation API MT-MK.

3.2 Anskaffa eller utveckla olika delar själv

Att etablera SDK-komponenter separat passar sannolikt organisationer som långsiktigt vill integrera med flera meddelandeklienter/verksamhetssystem. Organisationen bör ha en strategi för hur olika meddelandeklienter/verksamhetssystem skall integreras och kopplas till olika funktionsadresser.

Anskaffa eller utveckla olika delar själv passar organisationer som önskar installera och konfigurera AP själv, ta fram eller integrera med befintlig integrationslösning (meddelandetjänst/meddelandeväxel) för meddelandevalidering, meddelandekvittens och informationsutbyte med meddelandeklient/verksamhetssystem.

Rekommendation att undersöka:

  • att det finns lokal kompetens inom integration.
  • administration, anpassning/utveckling av integrationsflöden.
  • om lokal infrastruktur t ex integrationsmotor (meddelandetjänst) kan användas för att hantera interna meddelandeflöden.
  • vilka förutsättningar som finns för att anpassa befintliga meddelandeklienter/verksamhetssystem.
  • om det finns egen förmåga att drifta och förvalta lösningen.

Generalisera komponenter för:

  • Adressbokens API:er.
  • Meddelandetjänstens API:er
  • Accesspunktens API:er

Säkerställ att komponenter utformas/levereras med öppna API:er som möjliggör att komponenter kan bytas ut eller utökas. T ex att komponenter levereras med ett öppet tillgängligt API som möjliggör byte av accesspunkt, meddelandetjänst och meddelandeklienter, se Rekommendation API MT-MK.

Fördelar

  • Egna komponenter ger anpassningsbarhet – full kontroll över koden.
  • Integrationsflöden kan skräddarsys för verksamhetens behov.
  • Lätt att koppla på nya klienter (verksamhetssystem).
  • Återanvända befintliga komponenter för förvaltning och behörighetsstyrning.
  • Lätt att byta implementation av accesspunkten.

Nackdelar

  • Det tillkommer utvecklings- och förvaltningskostnader.
  • Kräver ofta egna resurser och kompetens inom utveckling och integration, eventuellt även inom applikationsförvaltning, alternativt vana av att kravställa mot leverantörer.
  • Kräver fortsatt vidmakthållande av egna lösningar för att t ex löpande följa SDK:s livscykel för tekniska specifikationer och dokumenttyper.
  • Komplicerat om lösningar och förvaltning fördelas på flera team och plattformar.

4. Säkerhet

Regelverk för deltagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa, se regelverk för deltagarorganisationer inom SDK.

4.1 Roller och ansvar - övergripande orientering

Inom SDK-federationen fördelas ansvar mellan följande aktörer och roller, se bilaga om aktörer och roller inom SDK.

4.1 Informationsklassning

SDK-federationen är framtaget för att stödja informationsutbyte av känsliga personuppgifter. Det är därför viktigt att alla ingående komponenter lever upp till gällande lagar och regelverk för vald informationsklassning.

Regelverk för delatagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa. Se regelverk för deltagarorganisationer inom SDK samt bilaga för informationssäkerhet inom SDK.

4.2 Lokalt ansvar: Inre säkerhet (Inom deltagarorganisation)

Med inre säkerhet avses säkerhet mellan deltagarorganisationens interna komponenter. Regelverk för deltagarorganisationer inom SDK innehåller gemensamma krav som alla deltagarorganisationer behöver följa. Inom området inre säkerhet brukar nedanstående områden lyftas fram som viktiga.

4.2.1 Inloggning (Multifaktorautentisering)

Multifaktorautentisering (multifaktorsinloggning) kan uppnås på olika sätt. Ett vanligt sätt är att en e-legitimation används vid inloggning. E-legitimation kan integreras i användarens dator (operativsystem), alternativt används en intern/extern IdP (Identity Provider) via säkerhetsprotokoll som t.ex. SAMLv2/OAuth/OIDC.

4.2.2 Behörighetshantering (Auktorisation av personal)

  • Säkerställa att behörighetssystemet endast ger behörig användare tillgång till informationen.
  • Säkerställa att adressering av funktionsbrevlådor motsvara behörighetsmodellen (sekretessgränser).

4.2.3 Behörighetskatalog

  • Behörighetsstyrning kan med fördel utgå från en för deltagarorganisationen gemensam katalog. Undersök om en gemensam behörighetskatalog kan användas, t.ex. lokalt Active Directory (AD) eller motsvarande.
  • Fristående meddelandeklienter kan innebära att en klientspecifik behörighetskatalog behöver administreras.

4.2.4 Säkerhet mellan interna komponenter

Kommunikation mellan komponenter t.ex. accesspunkt, meddelandetjänst och meddelandeklient ska vara transportkrypterad och autentisering av systemen ska tillämpas (endast behöriga system ska kunna hantera information).

Rekommendation

  • Komponenter som hanterar SDK-meddelanden måste vara anpassade för att hantera känsliga personuppgifter.
  • IT-säkerhetsbilagan innehåller detaljerade krav på säkerhet och säkerhetsprotokoll.

4.3 Yttre säkerhet (mellan deltagarorganisationer)

Informationsöverföring mellan deltagarorganisationer hanteras av AP-operatörens accesspunkt. Diggs regelverk och specifikationer reglerar säkerhet mellan accesspunkter. I huvudsak är det nedanstående säkerhetsmekanismer som tillämpas, se även Plattform-informationssäkerhet och tillitsmodell. Länk till annan webbplats.

Hanteras av AP-operatör - accesspunkt:

  • Transportkryptering (mTLS) kan även implementeras i skalskydd.
  • Tillförlitlig källa för metadata och teknisk adressering. Signering av metadata i metadatatjänst (SMP) och Certifikatspubliceringstjänst (CertPub, del av SMP).
  • AS4 meddelandekryptering (WS-Security AP till AP).

Hanteras av deltagarorganisation - meddelandetjänst:

  • Kryptering och signering av nyttolast för SDK-meddelandet samt signering av kvittensmeddelande.
  • Meddelandet krypteras och signeras innan det lämnas till accesspunkt för meddelandeöverföring.
  • Behörighetshantering mellan accesspunkt och meddelandeklienter.

Läs mer om säkerhet i SDK SAD.

Rekommendation

  • Använda stödfunktioner i SDK QA-miljö som hjälper deltagarorganisationen att validera följsamhet till tekniska krav.

5. Säkerhet i IT-drift

SDK har inte tagit fram SDK-specifika krav på lokal IT-drift. Vid anslutning till SDK regleras ansvarsförhållanden samt förväntningar gällande SLA, se bilaga för tillgänglighet inom SDK. Anslutande deltagarorganisation förväntas ha en säker och robust IT-drift eller ha förmåga att kravställa en säker IT-miljö. Deltagarorganisationen ska säkerställa att lokal IT-miljö är utformad på ett sätt så den kan hantera känsliga personuppgifter.

Rekommendation

  • SKR/Inera har tagit fram bra anvisningar inom området som är tillgängliga för regioner och kommuner. Dessa anvisningar finns tillgängliga via Ineras kundservice.
    • Anvisning för Säkerhet i drift
    • Anvisning för Loggning i driftsmiljön
    • Anvisning Informationssäkerhet
  • Digg har tagit fram ett beskrivande dokument som syftar till att öka medvetenhet och skapa förståelse kring Informationssäkerhet och tillit inom plattformen för eDelivery samt anslutning av federationer för samtliga intressenter oavsett roll.

6. Övergripande arkitektur

Avsnittet beskriver vilka övergripande frågor som behöver utredas för att kunna välja rätt anpassnings- och anskaffningsstrategi för att etablera lokal SDK-federation.

6.1 Ansvar för SDK:s olika delar

Utifrån SDK:s ovanstående övergripande arkitekturskiss fördelas ansvaret för att etablera komponenterna samt kravuppfyllnad enligt tabell nedan.

Kolumnen Omfattning ger en indikation på omfattning av resursbehov (tid eller kostnad) för att etablera SDK.

  • S: Small
  • M: Medium
  • L: Large

Komponent

Ansvar

Beskrivning

Omfatt-ning

Meddelandeklient

Deltagarorganisation

Meddelandeklient/verksamhetssystem är den komponent där verksamhetsprocessen och användarna finns. En deltagarorganisation kan ha många meddelandeklienter.

En funktionsadress slutdestination är meddelandeklienten.

Meddelandeklient/verksamhetssystem ansvarar för permanent lagring av information samt integrerar med SDK-federationen via dess 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

Deltagarorganisation

Meddelandetjänst/meddelandeväxel, hanterar integration mellan accesspunkt och meddelandeklienter. En deltagarorganisation 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.

Validerar avsändare och mottagare mot SDK adressbok.

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 deltagarorganisation har normalt en accesspunkt som hanterar alla dess meddelandeutbyten inom SDK-federationen.

En accesspunkt måste tillhandahållas av AP-operatörsrollen som regleras av Digg.

En deltagarorganisation kan vara AP-operatör.

Komponenten 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 ska konfigureras enligt Diggs ansvisningar och valideringsprocess.

M

SDK adressbok (gemensam komponent)

Federationsägare (Digg)

SDK adressbok är en tjänst som möjliggör för anslutna organisationer att registrera organisatoriska adressuppgifter för att identifiera anslutna organisationer och hitta mottagare för överföring av digitala meddelanden via SDK.

 

SDK adressbok (innehåll)

Deltagarorganisation

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.

M

SMP

Digg

SMP är en tjänst som innehåller metadata om en deltagarorganisation. Med hjälp av metadata kan korrekt adressering genomföras av meddelande till mottagarens accesspunkt. SMP är en gemensam komponent i plattform för eDelivery

 

SMP/CertPub (AP metadata)

AP-operatör

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

Hanteras av AP-operatör via Diggs anvisning.

S

O2O-certifikat

  • Anskaffa
  • Registrera i CertPub (via anslutningsförfarande)

Deltagarorganisation

Certifikat för O2O-kryptering (Organisation till organisation) anskaffas från godkända certifikatsutgivare. Se regelverk för deltagarorganisationer inom SDK.

M

Uppfyllande av informationssäkerhetskrav och SLA

Deltagarorganisation (via intygande om överensstämmelse)

Krav på deltagarorganisationen gällande informationssäkerhet och IT-säkerhet.

  • Inloggning och behörighetstilldelning

M

Rekommendation

  • Analysera vilka verksamhetsprocesser eller verksamhetsfunktioner som ska anslutas till SDK-federationen.
  • Analysera vilka verksamhetssystem eller meddelandeklient (-er) som kan användas för att stödja en verksamhetsprocess/verksamhetsfunktion.
  • En meddelandeväxel är en strategisk lokal SDK-förmåga som bör kunna stödja mer än ett verksamhetssystem/meddelandeklient.
  • Analysera om er organisation har en gemensam behörighetshantering (t ex AD) som kan användas för behörighetsstyrning av funktionsbrevlådor i meddelandeklient.
  • Komponenter kan etableras genom upphandling, avrop mot (framtida) ramavtal eller tas fram av egna resurser.
  • Analysera vilka anpassningsmöjligheter som finns i verksamhetssystem/meddelandeklient
  • Informationssäkerhetskrav:
    • Krav på multifaktorautentisering (meddelandeklient/verksamhetssystem)
    • Krav på behörighetsmodell

7. Meddelandeklient, meddelandetjänst och accesspunkt

Tabellen nedan sammanställer områden som kan underlätta anslutande parts förstudie inför införande.

 

Meddelandeklient
(Verksamhetssystem)

Meddelandetjänst

Accesspunkt

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 Diggs krav krävs

Validering och kvittering av meddelande

 

 

 

Integrerar direkt eller indirekt mot mot SDK adressbok

 

 

 

Loggning

 

 

 

Routing - Meddelandeklient/ funktionsadress

 

 

 

Koppling till adressbok

 

 

 

Koppling till SMP/CertPub

 

 

 

7.1 Meddelandeklient - Verksamhetssystem

En verksamhetsprocess, t ex att skicka/ta emot en orosanmälan, representeras i SDK adressbok i form av en funktionsadress. Det är meddelandeklient/verksamhetssystem som ansvarar för lagring av meddelanden (ärendehistorik etc). Alla funktionsadresser som skapas i SDK adressbok ska i slutändan levereras till en meddelandeklient eller ett verksamhetssystem. Hur många meddelandeklienter eller verksamhetssystem som ska anslutas till SDK-flöden får avgöras av det lokala IT-landskapets utformning.

Meddelandeklienten ska också ha ett behörighetssystem som säkerställer att endast behörig användare har tillgång till information som förmedlas via SDK-federationen. Meddelandeklienten/verksamhetssystemet behöver kunna hantera två meddelandetyper (dokumenttyper, xml-meddelanden) som krävs inom SDK. Se bilaga om meddelandetyper.

Rekommendation

  • Säkerhet
    • Multifaktor autentisering av användaren (t.ex. e-legitimation eller motsvarande)
    • Behörighetskontroll av användare
  • Meddelande
    • Meddelandeklient/verksamhetssystem måste kunna skapa och hantera meddelande och meddelandekvittens enligt specifikation.
  • Integration
    • Meddelandeklient/verksamhetssystem integreras med meddelandetjänst/meddelandeväxel.
      • Om möjligt används av Digg rekommenderade API:er
        • Integreras med meddelandetjänst/meddelandeväxel (Skicka/ta emot meddelanden, kontrollera meddelandestatus/kvittens)
      • Integration med SDK adressbok är nödvändig, alternativt ha en egen lokal läskopia av adressboken.

7.2 Meddelandeformat

När det gäller meddelandeklient eller verksamhetssystem kan det vara enklare att initialt välja en dedikerad meddelandeklient eftersom den kan vara enklare att anpassa enligt SDK meddelandeformat.

Meddelandeformatet är “e-post liknande” innehållsmässigt enligt följande övergripande struktur:

  • Message
    • MessageHeader
      • Recipient
      • Sender
    • Message
      • Subject
      • Text
      • Attachement

Rekommendation

Man bör undersöka att meddelandeklienten eller verksamhetssystemet kan:

  • hantera meddelanden (dokumenttyper)
  • hantera bifogade filer i form av t ex PDF.
  • sortera meddelanden enligt en meddelandetråd (konversations-id).
  • presentera statusmeddeland tillsammans med meddelanden:
    • Transportkvittens - Meddelande har levererats till mottagarens accesspunkt
    • Meddelandekvittens - Meddelandet är validerat och är tillgängligt för mottagaren
    • Felhantering - Felmeddelanden

7.3 Meddelandetjänst - meddelandeväxel

Deltagarorganisationen behöver etablera en komponent som kallas meddelandetjänst/meddelandeväxel (MT). MT kan beskrivas som en integrationsmotor som löpande hämtar och lämnar meddelanden mellan accesspunkten och meddelandeklienter/verksamhetssystem (t ex via dess interna API:er; SOAP eller REST).

  • Meddelandetjänsten ansvarar för att:
    • Kryptera, dekryptera, signera och validera signatur av meddelanden.
    • Validera SDK-meddelanden, dvs kontrollera att meddelandet följer schema och regelverk.
    • Kontrollera att funktionsadressen är korrekt och att den är aktiv.
    • Skapa ett kvitteringsmeddelande, inkl felmeddelanden om den funktionsadress som har angivits inte är aktiv.
    • Ansvarar för att "routa" meddelanden till verksamhetssystemen (meddelandeklienter) som ansvarar för funktionsadressen. Man bör ta höjd för att kunna hantera flera meddelandeklienter.
    • Svarstidsbevaka skickade meddelanden, dvs att ett skickat meddelande kvitteras av mottagaren. En kvittering innebär att meddelandet är utlämnat och har nått mottagaren.
    • Kommunicera meddelandestatus till meddelandeklient/verksamhetssystem.
  • Integrationsgränsnitt:
    • Öppet integrationsgränssnitt (API) för att integrera med olika meddelandeklienter och accesspunkter.
    • Stödja API:er som Digg rekommenderar.
  • Ett säkerhetskoncept för att säkra organisationens “inre säkerhet”:
    • Transportkryptering
    • Autentisering av systemkomponenter
    • Behörighetskontroll
    • Certifikat för signering och kryptering av meddelanden.
  • Externa komponenter:
    • DNS för dynamisk inhämtning av metadata från SMP.
    • CertPub (SMP) register med deltagarorganisationers publika nycklar (kryptering, validering av signatur).
    • SDK adressbok för adressuppslag.

Meddelandetjänsten utgör en meddelandeväxel som transporterar meddelanden mellan meddelandeklienter, t ex olika verksamhetssystem, och deltagarorganisationens accesspunkt. Nedanstående tabell listar övergripande funktioner/förmågor som komponenten behöver stödja.

Se även testfall för meddelandesystem för anslutning till OPEN-TEST.

Övergripande funktion/förmågor

Stöd som tillhandahålls av SDK-federationen: SDK QA-miljö och OPEN-TEST (för leverantörer)

Adapter (Connector)

En adapter används för att uppnå koppling (integration) mellan accesspunkt och meddelandetjänst som inte är produktspecifik. Denna komponent är inte standardiserad av 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)
  • Kan vara ett API eller en meddelandekö

Verifieras vid Diggs anslutningstester för AP-operatör. Verifieras även indirekt via anslutning till SDK QA-miljö genom att meddelanden skickas, valideras och kvitteras med t ex testklient.

Rekommenderade specifikationer:

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:

Dekryptera, Validera

Komponenten dekrypterar, validerar signatur coh 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:

Status

Komponenten skapar ett 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:

Vägval/”routing”

Vägval och “routing”

Meottagande funktionsadress/ 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 15 minuter för att anses vara levererat.
  • Hantera meddelandestatus för SDK meddelande (ej standardiserat)
  • Transportstatus/transportkvittens

Verifieras indirekt genom att testklient skickar ett kvitteringsmeddelande.

Rekommenderade specifikationer:

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 regelverk för deltagarorganisationer inom SDK, se bilaga för IT säkerhet inom SDK.

Komponent

Beskrivning

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

Dekryptera, Validera

Applikation som validerar meddelanden.

· Dekryptera och validera meddelandets signatur (XHE)

· Schemavalidering (XSD)

· Schematronvalidering (SCH)

· Storleksvalidering

· Skydd mot skadlig kod

· 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

Rekommendation

Meddelandetjänst/meddelandeväxel är en komponent där utveckling/anpassning är nödvändig.

7.4. Accesspunkt (AP)

Accesspunkten är en integrationskomponent som är baserad på en standardiserad mjukvara. Accesspunkten består av applikationsserver, applikation och databas. Komponenten skall installeras och konfigureras enligt Diggs anvisningar för att fungera i SDK-federationen. Se Transportpofil AS4 Länk till annan webbplats., PKI för accesspunkter Länk till annan webbplats. samt Accesspunktsoperatör – gemensamma regler och rutiner. Länk till annan webbplats.

Accesspunkt medger anpassade interna integrationsgränssnitt beroende på mjukvara.

En accesspunkt som är integrerad i SDK-federationen kommer automatiskt att ta emot och leverera meddelanden till/från deltagarorganisationer inom federationen. Accesspunkten hanterar endast transport av meddelanden. Meddelanden skapas och hanteras av meddelandetjänsten.

Lokalt ansvar:

  • Anskaffa en Accesspunkt
    • Alternativ: Via extern AP-operatör.
    • Alternativ: Ansöka om att bli AP-operatör.
    • Välja vilken mjukvara som ska användas som accesspunkt Länk till annan webbplats..
      • Installera och konfigurera accesspunkt (applikationsserver, applikation, databas).
      • Konfigurera enligt Diggs anvisningar.
        • Installera godkänt certifikat i accesspunkt.
        • Konfigurera “trust” till godkända certifikatsutställare.
      • AP-operatör registrera vilka dokumenttyper och deltagarorganisationer som accesspunkten skall kunna skicka och ta emot (hanteras via anslutningsprocess).
      • Federationsägare godkänner registrering i SDK-federation.
      • Accesspunkt integreras mot meddelandetjänst (MT).

Rekommendation

  • Anskaffa godkänd accesspunkt via en AP-operatör eller ansök själv om att bli AP-operatör hos Digg.
  • Anpassa lokal driftinfrastruktur för kommunikation mellan accesspunkter. Säkerställ transportkryptering (TLS) t ex terminering av TLS.
  • Accesspunkt bör ha ett öppet tillgängligt API som möjliggör integration mot olika meddelandetjänster.

8. SDK adressbok

SDK adressbok är ett gemensamt adressregister för information om SDK-anslutna deltagarorganisationer och funktioner inom dessa. SDK adressbok är en komponent i SDK-federatioen.

Syftet med SDK adressbok är:

  • Att vara en källa för adressuppgifter genom att behöriga användare registrerar och underhåller information om en deltagarorganisation och dess funktioner (funktionsadresser) via adressbokens administrationsgränssnitt.
  • Att tillhandahålla funktionalitet för att hitta mottagare genom att SDK-anslutna deltagarorganisationer kan söka och hitta andra anslutna deltagarorganisationer och deras funktionsadresser.

Adressboken tillhandahåller ett integrationsgränssnitt ett så kallat Sök-API som kan användas för direktintegration eller skapa en lokal läskopia. Deltagarorganisationen anger behöriga administratörer under anslutningsprocessen och administrera själv sin information.

8.1 Strukturera adressboken - Använda standardiserade sökord

Adressboken ska struktureras för att stödja externa parters behov av att hitta rätt mottagare inom respektive deltagarorganisation. Adressboken ska inte vara strukturerad utifrån den intern organisationsstrukturen. Funktionsadresser i SDK adressbok behöver beskrivas på ett enhetligt standardiserat sätt för att stödja extern sökning. Detta uppnås genom att tillämpa sökord för funktionsadress enligt de kodverk som finns tillgängliga inom SDK adressbok.

I SDK finns i huvudsak tre typer av kodverk för att stödja behovet av att hitta rätt mottagare:

  • Geografisk hemvist: Var tillhandahålls funktionen (kommun, län eller nationellt).
  • Strukturkodver: Placering av funktion i verksamhetsstrukturen.
  • Sökkodverk: En sökkod (sökord) för en specifik funktion.

Rekommendation

8.2 Integrera med/söka i SDK adressbok

Användare av meddelandeklienter/verksamhetssystem behöver kunna söka i SDK adressbok för att adressera ett meddelande. SDK adressbok innehåller alla anslutna deltagarorganisationers funktionsadresser.

Integration mot SDK:s adressbok kan göras via SDK:s Sök-API. Sök-API är framtaget för att stödja direktsökning men kan även användas för att skapa en lokal läskopia.

  • Skapa en lokal läskopia av adressboken
    • Genom att uppdatera en lokal läskopia kan integration med meddelandeklienter/verksamhetssystem underlättas då befintlig funktionalitet kan återanvändas.
  • Direktintegration via adressbokens Sök-API.
    • Funktioner: Fritextsökning, sökning baserat på urval och kodade värden.
  • Strukturerad sökning
    • Tillämpa kodverk

Lokal läskopia:

Fördelar:

  • Integration med befintlig kataloglösning kan underlätta integration med meddelandeklient/verksamhetssystem.
  • Enklare integration.
  • Mindre påverkan på meddelandeklient/verksamhetssystem.
  • Minskar lokal påverkan vid SLA störningar i central adressbok.

Nackdelar:

  • Avancerad kodad sökning mot adressboken kan vara svår att realisera.
  • Lokal läskopia måste hållas uppdaterad och säker.
  • Uppdateringar kan ta längre tid innan dessa får genomslag.

9. Leverantörsmarknad

Idag finns inget specifikt ramavtal för SDK-komponenter. Adda inköpscentral erbjuder kommuner och regioner stöd i form av ett dynamiskt inköpssystem för Säker digital kommunikation. Mer information om det stöd som erbjuds via Adda finns att läsa här: https://www.adda.se/upphandling-och-ramavtal/planerade-och-pagaende-upphandlingar/saker-digital-kommunikation-DIS Länk till annan webbplats.

Det finns även ett antal leverantörer som erbjuder SDK-komponenter, kontakta sdk@digg.se för mer information.

Etablering kan ske via befintligt avtal eller genom direktupphandling.

Rekommendation

  • Ta ställning till om ni vill ta del av Addas dynamiska inköpssystem för Säker digital kommunikation.
  • Undersök om befintliga avtal kan användas för att anskaffa och anpassning av nödvändig mjukvara.
Hjälpte denna information dig?

Ditt svar hjälper oss att förbättra sidan

Senast uppdaterad: