Innehållsförteckning | ||
---|---|---|
|
Arkitekturella krav
T-boken [2] beskriver de övergripande kraven på den tekniska arkitekturen. En delmängd av dessa krav omsätter T-boken i en konceptuell arkitektur uppbyggd av komponenter som tillsammans benämns T- bokens Tjänsteplattform.
Övergripande arkitekturella krav
Här sammanfattas de övergripande kraven samt ges en identitet för senare uppföljning i SAD:en.En Virtualiseringsplattform (VP) realiserar ett flertal krav enligt T-boken såsom:
- Administration av systemförändringar blir minimal. VP minimerar dominoeffekter vid förändringar i system hos en samverkande part eller i nationella tjänster.
- VP erbjuder en lös koppling mellan två samverkande parter.
- Administration av organisationsförändringar blir minimal genom att VP erbjuder en flexibel adresseringsmodell mellan samverkande parter.
- Följsamhet mot nationellt fastställda tjänstekontrakt.
Icke funktionella krav
Krav Id | Beskrivning | Typ |
---|
K-1 |
Krav - Administration av systemförändringar ska vara minimal
Krav - Anslutningspunkter
Krav - Administration av organisationsförändringar ska vara minimal
Krav – Meddelande format
Krav - Hantering av RIV-TA profiler
För version 1.0 av virtualiseringsplattformen levereras inte stöd för översättning mellan olika RIVTA-versioner (transformering mellan olika kuverterings- och säkerhetsmodeller). Det är dock av största vikt att detta kan läggas till i nästa version utan befintlig arkitektur eller produkt behöver bytas. Vi behöver därför fundera igenom hur detta skulle kunna taklas, till en nivå att vi bedömer risken liten för att en nya arkitektur skulle behöva etableras för att klara detta krav.
Krav - felhantering
Alla former av fel kan spåras i efterhand då dessa loggas persistent. Loggnivån är även konfigurerbar för att kunna spara extra mycket spårningsinformation. Virtualiseringsplattformen bidrar till felsökning genom att svarstider mot bakomliggande tjänsteproducenter visas. De fel som en tjänstekonsument utsätts för innehåller tydlig information om felorsaken.
Öppenhet
VP levereras som öppen källkod under licensen LGPL.
Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent ska maximalt tillföra 40 millisekunder i exekveringstid, i förhållande till ett anrop utan mellanhand. | Prestanda | |
K-2 | Virtualiseringsplattformen ska stödja gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer. | Skalbarhet |
K-3 | All kommunikation ska säkras enligt RIV Tekniska Anvisningar Basic Profile 2.0 (https med ömsesidig autentisering). Detta innebär att båda parter skall presentera giltiga certifikat vid upprättandet av en säker förbindelse (sk SSL-handshake). | Säkerhet |
K-4 | VP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler. | Utökningsbarhet |
K-5 | VP ska kunna driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. | Flexibilitet |
K-6 | Virtualiseringsplattformen ska ha stöd för teknisk monitorering av Mule ESB. Detta innebär också riktat stöd för monitorering av svarstider hos tjänsteproducenter och att VP loggar på loggformat lämpliga för övervakning av gängse övervakningsverktyg. | Monitorering |
K-7 | Virtuella tjänster är tillståndslösa mellan anrop, vilket gör att s.k. fail-over inte behöver införas för att uppnå hög tillgänglighet. Hög tillgänglighet bedöms kunna uppnås genom klustring. | Tillgänglighet |
K-8 | Virtualiseringsplattformen (VP) ska inte vara beroende av att Tjänstekatalogens (TAK) tjänster för att hämta behörighet och routing är tillgänglig online, vilket medför att VP ska kunna utföra sitt uppdrag även när TAK inte är tillgänglig. | Tillgänglighet |
K-9 | VP ska levereras som öppen källkod under licensen LGPL. | Flexibilitet |
K-10 | VP ska levereras med automatiserade last- och robusthets-tester. Plattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig. | Prestanda |
K-11 | All utveckling av VP ska baseras på portabla, komponentbaserade byggen enligt en väl beskriven produktstruktur. | Flexibilitet |
K-12 | Virtualiseringar ska kunna skapas mha en enkel instruktion. Detta utifrån en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt och därefter kunna skapa paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen. |
Funktionella krav
Detaljerade krav på funktionalitet i Virtualiseringsplattformen.
Krav Id | Beskrivning | Typ |
---|---|---|
FK-1 | Autentisering för HTTPS ska ske via "mutual authentication" i två led eller fler led för Virtualiseringsplattformen enligt RIV Tekniska Anvisningar. | Säkerhet |
FK-2 | Auktorisation för HTTPS ska ske via det HSA-id ett anropande system presenterar i certifikatets "subject" | Säkerhet |
FK-3 | Autentisering och Auktorisation för HTTP ska ske genom användning av information i HTTP-headers. | Säkerhet |
FK-4 | All intern kommunikation mellan SKLTP-komponenter ska gå via HTTP med extra verifiering av anslutande part enligt FK-3. | Säkerhet |
FK-5 | VP ska stödja "RIV-TAs frivilliga anvisning angående HTTP Header för att ange ursprunglig avsändare". | |
FK-6 | VP ska hantera olika versioner av RIV-TA profiler, dvs en översättning mellan olika RIV TA-profiler (transformering mellan olika kuverterings- och säkerhetsmodeller). | |
FK-7 | Felmeddelande som orsakas i virtualiseringsplattformen ska rapporteras som SOAPFault till tjänstekonsumenten med tillhörande HTTP Status kod (500), samt loggas. ID i SOAPFault ska finnas |
för korrelering mot en loggfil. | Felhantering |
FK-8 | Felsituationer som är förutsägbara baserade på |
inkonsistens mellan metadata i meddelandetrafik och innehåll i tjänstekatalog, ska redovisas i SOAPFaults med mycket stor tydlighet, så att det inte råder något tvivel |
om orsaken och vad som behöver göras (se standardiserade felkoder nedan). |
Felhantering |
FK-9 |
Referensapplikation
En exempelapplikation visar ett komplett uppsatt end-to-end-exempel, baserat på PoC. Det handlar alltså om en version av PoC, men utan de delar som relaterar till mätningar. Detta ger en startpunkt för dem som vill testköra och praktiskt skapa sig en förståelse för tjänsteplattformen.
Som ... vill jag kunna ladda hem och provköra, samt titta på exempelkod. Det måste inte vara ursprunglig PoC men FitNess-paketeringen där är kraftfull och skulle vara till nytta.
Lasttester
Virtualiseringsplattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig. det är därför av största vikt att leveransen (denna och framtida) kvalitetssäkras av automatiserade lasttester.
Som ... vill jag att varje leverans lasttestats med tester som redovisar snitttid för dirigering genom virtuell tjänst, max och min tid, baserat på en realistisk last som körts under minst ett dygn.
Portabla byggen
T-bokens krav på portabla byggen och testautomation ska vara uppfyllda
Som ... vill jag att all utveckling är baserad på portabla, komponentbaserade byggen enligt välbeskriven produktstruktur, med Maven som byggsystem.
Alla former av fel ska kunna spåras i efterhand då dessa loggas persistent. Loggnivån ska vara konfigurerbar för att kunna spara extra mycket spårningsinformation. | Felhantering | |
FK-10 | VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar och dels till anropande system. | Monitorering |
FK-11 | VP ska under drift kunna hämta och uppdatera sin konfiguration från en Tjänstekatalog (TAK). Detta innebär att VP behöver ha en cache med TAK konfiguration om en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop. | |
FK-12 | VP ska under drift kunna hämta och uppdatera sin HSA konfiguration från en lokalt inläst HSA-fil. Detta innebär att VP behöver ha en cache med HSA konfiguration om en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop. | |
FK-13 | VP ska per tjänst kunna konfigurera ett separat time-out värde. Är inget time-out värde angivet skall ett defaultvärde användas(konfigurerbart). | |
FK-14 | VP ska per tjänst kunna konfigurera om keep-alive skall användas i kommunikationen. | |
FK-15 | VP ska stödja "RIV-TAs frivilliga anvisning angående status för anrop till aggregerande tjänster". | |
FK-16 | VP ska per tjänst kunna besvara ett tjänsteanrop med ?wsdl. Detta så att tjänstekonsumenter alltid kan få tillbaka aktuell wsdl och scheman för tjänsten. Detta skall gälla även om det finns en reverse-proxy/lastbalanserare framför VP. | Tillgänglighet |
FK-17 | Såväl vägval som behörigheter ska kunna registreras högre upp i HSA-s organisationsträd än på vårdgivarnivå. För vägval kan registrering typiskt ske på den nivå som det tjänsteproducerande systemet stöttar respektive organisation och för behörighet på den nivå i organisationen som konsumenten skall ha access. | Säkerhet |
FK-18 | Logisk adress kan anges som VG#VE där VG är vårdgivares HSAID och VE vårdenhets HSAID. Not: Denna adressering får endast användas efter godkännande från Inera. Detta krav har lagts till här då det är en existerande funktion i SKLTP. Funktionen kan dock komma att avvecklas. Se FK-17 som är en generellt krav för klättring i HSAID-trädet. | Säkerhet |
FK-19 | VP ska kunna göra ett nytt försök att anropa producent efter ett misslyckat anrop. Tiden mellan anropen ska vara konfigurerbar och funktionen ska även kunna stängas av. | Stabilitet |
FK-20 | VP ska kunna hantera och exponera ett korrelations-id (x-skltp-correlation-id) som används som en gemensam identitet vid kommunikation över flera system och vid loggning. Om korrelations-id saknas ska ett sådant kunna genereras av VP. | Monitorering |
FK-21 | VP ska kunna logga till en annan applikation via socket. |
Standardiserade felkoder
Ankare | ||||
---|---|---|---|---|
|
Implementationen av en virtualiseringsplattform skall returnera standardiserade SoapFault - felmeddelanden enligt följande:
Felkod | Feltext | Kommentar |
---|---|---|
VP001 | Riv-version inte konfigurerad för den anslutningspunkt som den virtualiserade tjänsten publicerar. |
VP002 | SERIALNUMBER ej tillgängligt i konsumentens certifikat i namn-attributet. |
VP003 | ReceiverId ej ifylld i RivHeadern i inkommande meddelande. |
VP004 | Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar ReceiverId, Tjänstekontrakt och dagens datum. |
VP005 | Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar Riv-version, konvertering mellan rivversioner inte implementerat. |
VP006 | Det finns mer än 1 tjänsteproducent definierad i Tjänstekatalogen som matchar ReceiverId, Tjänstekontrakt och dagens datum. Tyder på att Tjänstekatalogen är felkonfigurerad. |
VP007 | Den finns ingen behörighet för den tjänstekomponent som anropar att samverka med tjänsteproducenten. Avser behörigheter definierade i tjänstekatalogen. |
VP008 | Ingen kontakt med tjänstekatalogen. Innebär att vägvalsagenten inte kunnat hämta vägvalsinformation varken vid uppstart eller vid något efterföljande anrop. |
VP009 | Fel vid kontakt med tjänsteproducenten. |
VP010 | Ingen adress angiven i tjänsteproducenten |
VP011 | Anropande konsument är inte betrodd att göra http-anrop till VP | Anropande konsument kan tex vara en annan SKLTP komponent, en lastdelare eller tex en reverse proxy. |
VP012 | Nödvändiga resurser för att VP skall fungera saknas. | Virtualiseringsplattformen saknar någon av de resurser som krävs för att den skall kunna fullfölja sitt uppdrag att hantera routing och behörighet. |
Funktionella krav
Detaljerade krav på funktionalitet i Virtualiseringsplattformen.
Krav Id | Beskrivning | Typ |
---|---|---|
FK-1 | Autentisering för HTTPS via mutual authentication i två led eller fler led för virtualiseringspattformen | |
FK-2 | Auktorisation för HTTPS via HSA_id i anropande systems certifikats "subject" | |
FK-3 | Autentisering och Auktorisation för HTTP genom användning av information i HTTP-headers | |
FK-4 | Stödja "RIV-TAs frivilliga anvisning angående http header för att ange ursprunglig avsändare | |
FK-5 | All intern kommunikation skall gå via HTTP | |
FK-6 | Virtuella tjänster skall paketeras separat, samt därmed kunna driftsättas separat i VP Virtualiseringsplattformen är distribuerad till sin natur. Det innebär att ett tjänstekontrakt kan virtualiseras i många instanser av virtualiseringsplattformen, för att undvika single-point-of-failure. Subsidiaritetsprincipen (VIT-boken) är det grundläggande motivet för en dsitribuerad driftssättning. Det innebär att konfiguration av virtuella tjänster behöver kunna genomföras och paketeras/distribueras fristående från de instanser i vilka de kommer att driftsättas. Som ... vill jag kunna följa en enkel instruktion som beskriver hur jag utgående från en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt skapar paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen. Jag vill också att instruktionerna visar hur jag verifierar min paketering, så att driftsättare slipper problem som jag kunnat förebygga. | |
Reset cache TAK | ||
Reset cache HSA |
Icke funktionella krav
Krav Id | Beskrivning | Typ |
---|---|---|
IFK-1 | Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent beräknas tillföra mindre än 40 millisekunder, i förhållande till ett anrop utan mellanhand. | Prestanda |
IFK-2 | Virtualiseringsplattformen stödjer gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer. | Skalbarhet |
IFK-3 | All kommunikation säkras enligt RIV Tekniska Anvisningar Basic Profile 2.0 (https med ömsesidig autentisering). Detta innebär att båda parter skall presentera giltiga certifikat vid upprättandet av en säker förbindelse (sk SSL-handshake). | Säkerhet |
IFK-4 | VP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler. | Utökningsbarhet |
IFK-5 | VP kan driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. | Flexibilitet |
IFK-6 | Virtualiseringsplattformen har stöd för teknisk monitorering av Mule ESB. Den har också riktat stöd för monitorering av svarstider hos tjänsteproducenter. VP loggar på loggformat lämpliga för övervakning av gängse övervakningsverktyg. | Monitorering |
IFK-7 | Virtuella tjänster är tillståndslösa mellan anrop, vilket gör att s.k. fail-over inte behöver införas för att uppnå hög tillgänglighet. Hög tillgänglighet bedöms kunna uppnås genom klustring. | Tillgänglighet |
IFK-8 | Virtualiseringsplattformen (VP) är inte beroende av att Tjänstekatalogens (TAK) tjänster för att hämta behörighet och routing är tillgänglig online, vilket medför att VP kan utföra sitt uppdrag även när TAK inte är tillgänglig. | Tillgänglighet |
IFK-9 | Virtualiseringsplattformen har inga egna protokoll, utan använder samma protokoll som föreskrivs av vården för samverkan mellan tjänster. För version 1.0 innebär det RIV Tekniska Anvisningar Basic profile 2.0. | Interoperabilitet |
Förtydligande av specifika krav
Förtydligande av specifika krav
FK-1, Autentisering via certifikat
Autentisering av en tjänstekonsument skall ske genom att säkerställa att certifikatet är utställt av en betrodd CA samt att identiteten för tjänstekonsumenten hämtas från certifikatets "subject" del och där närmare bestämt från fältet serialNumber som anger ett HSA-Id.
...
Detta innebär att en tjänsteproducent autentiserar anropande VP genom att lita på den CA som är utställare av VP's certifikat.
FK-2, Auktorisation av anropande system
Allt underlag för behörighetsbeslut finns lagrat i TAK. VP använder denna information för att auktorisera anropande tjänst mot den tjänst man vill nå. Anropande tjänsts identitet hämtas från det klient certifikat som används när man upprättar kommunikationen. I bilden nedan visas stegvis hur behörigheten kontrolleras vid ett anrop.
...
Här auktoriserar den nationella VP tjänstekonsumentens anrop till den regionala VP. Därefter auktoriserar den regionala VP anropet till tjänsteproducenten. Tjänsteproducenten auktoriserar inkommande anrop från den regionala VP t.e.x med ACL-funktionalitet.
FK-3, Intern HTTP kommunikation
Bakom en reverse proxy, på ett känt nätverk (eget nätsegment) vill man minimera kommunikationsoverhead så mycket som möjligt. För att stödja detta kan SKLTP komponenter ansluta till VP genom att bifoga information om avsändare, logisk tillhörighet och ip-adress.
- x-vp-sender-id = http-header med avsändarens identitet, motsvarande det som står i certifikatet vid https/ssl-anrop
- x-vp-instance-id = http-header med Id som måste stämma överens med id på den VP som ansvarar för routing och behörighet inom en viss logisk gruppering av SKLTP komponenter
- ip-adress = avsändarens ip adress, för att säkerställa att endast betrodda ip-adresser används
Obs: Detta gäller inte om det är HTTPs (extern) kommunikation.
FK-5, Ursprunglig avsändare
Enligt RIV-TA frivillig anvisning angående http header för att ange ursprunglig avsändare (se rivta.se/documents) så skall en tjänsteplattform sätta en http-header (”x-rivta-original-serviceconsumer-hsaid
") för att ange den ursprunglige avsändaren av ett meddelande. Denna information skall kunna användas av t ex en tjänsteproducent för loggning och/eller behörighetskontroll.
...
- Den skickar oxå bara vidare http-headern
- Behörighetskontroll görs också på HSA-ID för den mest näraliggande komponenten i anropskedjan, dvs den nationella tjänsteplattformens HSA-ID.
Kontroll av vem som skickar in http-header för ursprunglig avsändare
Då denna header kan användas för behörighetskontroll i källsystem så måste tjänsteplattform säkerställa att den enbart tar emot denna header från betrodda parter, typiskt andra angränsande tjänsteplattformar som den kommunicerar med. Ett sätt att säkerställa att avsändaren är känd kan vara att hålla en lista på ip-nummer som man litar på och kontrollera mot den innan man accepterar inkommande header för ursprunglig avsändare.
...
Ursprunglig avsändare och lastbalanserare/reverse-proxy
Då det är mycket vanligt att man använder lastbalanserare och/eller reverse-proxy framför sin tjänsteplattform så kompliceras bilden en smula:
- Typiskt terminerar man inkommande https/ssl-anrop i lastbalanseraren eller reverse-proxy och måste därmed skicka in klient-certifikatet i en separat http-header så att VP kan extrahera HSA-ID't från det certifikatet.
- Not: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
x-vp-auth-cert
"
- Not: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
- Vidare måste oxå lastbalanseraren/reverse-proxy skicka vidare ev http-headern för ursprunglig avsändare, ”
x-rivta-original-serviceconsumer-hsaid
", om den är med i inkommande anrop.- För att VP skall kunna säkerställ att denna header kommer från en betrodd avsändare måste också lastbalanseraren/reverse-proxy skicka in ip-adressen för den som anropat lastbalanseraren/reverse-proxy i en separat http-header.
Intern kommunikation
Bakom en reverse proxy, på ett känt nätverk vill man minimera kommunikationsoverhead så mycket som möjligt. För att stödja detta kan SKLTP komponenter ansluta till VP genom att bifoga information om avsändare, logisk tillhörighet och ip-adress.
- x-vp-sender-id = http-header med avsändarens identitet, motsvarande det som står i certifikatet vid https/ssl-anrop
- x-vp-instance-id = http-header med Id som måste stämma överens med id på den VP som ansvarar för routing och behörighet inom en viss logisk gruppering av SKLTP komponenter
- ip-adress = avsändarens ip adress, för att säkerställa att endast betrodda ip-adresser används
K-3, Mutual Authentication med SSL
I en kommunikation måste båda parterna presentera giltiga certifikat. Se bild och text nedan för en förenklad förklaring.
...
- Klienten sänder en begäran att nå en skyddad resurs, typ https://aaa.bbb
- Servern svarar med att skicka sitt certifikat samt en begäran om att klienten skall skicka sitt certifikat till servern.
- Klienten validerar serverns certifikat mot sitt sk truststore.
- Klienten sänder sitt certifikat till servern.
- Servern validerar klientens certifikat mot sitt truststore.
- Om alla villkor är uppfyllda etableras en HTTPS förbindelse mellan klient och server.
Certifikat
Alla certifikat som är inblandade i kommunikationen med tjänsteplattformen är HCC Funktionscertifikat. I certifikaten finns subjektets HSA-id lagrat. HSA-id från tjänstekonsumentens HCC Funktionscertifikat används av virtualiseringsplattformen vid den behörighetskontroll som TP utför.
Truststore
Alla truststore som är inblandade i kommunikationen antas innehålla utfärdande CA's certifikat. Detta innebär att alla verifieringar av certifikat godkänns då dessa är utfärdade av denna CA.
Nätverk
All kommunikation mellan inblandade tjänster sker på Sjunet, som är vårdens privata nät.
FK-17, Integration mot HSA organisationsträd
En allt för fingranulär behörighetsregistrering ner på vårdgivare eller vårdenhetsnivå skapar lätt administrativa flaskhalsar..
För att avsevärt minska den administrativa bördan för registrering av såväl behörigheter som vägval (routing) så ska SKLTP integrera mot HSA och kunna traversera mot dess organisationsträd. Därmed kan såväl vägval som behörighet registreras högre upp i organisationsträdet.
...
För vägval kan registrering typiskt ske på den nivå som det tjänsteproducerande systemet stöttar respektive organisation och för behörighet på den nivå i organisationen som konsumenten skall ha access.
Exempel:
- Säkerhetstjänsten för samtycke, v2.1, finns implementerad dels på nationell nivå samt som en lokal samtyckestjänst för Örebro läns landsting.
- Samtyckestjänsten adresseras på vårdgivarenivå.
- NPÖ är en nationell konsument av samtyckestjänsten som därmed skall ha behörighet för alla vårdgivare i Sverige.
- Två lokala konsumenter av samtyckestjänsten, en som skall ha behörighet att adressera samtyckestjänsten för vårdgivare i VGR och en som skall ha behörighet att adressera samtyckestjänsten för vårdgivare i Örebro läns landsting.
Utan HSA integration skulle NPÖ behöva registrera ett stort antal vårdgivare men med HSA integration blir adminstrationen minimal enligt följande:
Följande bild visualiserar en del av HSA's organisationsträd:
Konfiguration av vägvalsinformation
För den nationella och lokala samtyckestjänsten behöver vägvalsinformation endast registreras på vardera en nod i organisationsträdet enligt:
Konfiguration av behörighetsinformation
För de tre konsumenterna registreras också bara respektive behörighet på vardera en nod enligt: