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 motiven till tjänsteplattformens komponenter. Komponenternas namn och funktionella ansvarsfördelning är baserade på resultatet av det proof-of-concept som genomfördes för T-bokens referensarkitektur [4].
Krav - Administration av systemförändringar ska vara minimal
Samverkan över vårdgivargränser förutsätter samverkan mellan vårdgivares lokala system, eller säkerhetsmässigt komplett anslutning till nationella tillämpningar. Arkitekturen ska minimera eventuella dominoeffekter av förändringar i systemen hos en samverkande part och i nationella tjänster. Arkitekturen ska i detta avseende ta hänsyn till att det för enskilda IT-tjänster kan skapas grupper av vårdgivare som delar infrastruktur så väl som IT-lösningar och att dessa grupper kan förändras över tiden.
Krav - Anslutningspunkter
Arkitekturen ska minska dominoeffekten av systemförändringar, genom att erbjuda en nationell lösning för lös koppling (jfr SOA/W3C ”intermediary”). På så sätt kan förändringar i anslutningspunkter hos en vårdgivare isoleras från övriga parter i arkitekturen.
Krav - Administration av organisationsförändringar ska vara minimal
Arkitekturen ska minimera effekten av omorganisationer inom vård och omsorg, som ett led i att maximera tillgängligheten hos nationellt realiserade tjänster. En rimlig målsättning är att isolera behovet av förändringar till de organisationer som deltar i omorganisationen. Organisationsförändring kan avse sammanslagningar och andra omstruktureringar vårdgivare emellan. Det kan också avse organisationers tillträde och utträde i/ur nationell samverkan – t.ex. sammanhållen patientjournal.
Krav – Meddelande format
Följsamhet mot nationellt fastställda tjänstekontrakt är en viktig förutsättning för att undvika dominoeffekt av förändringar som annars riskeras. De nationella RIV-baserade formaten ska i sina xml-scheman införliva konstruktioner för utökningsbarhet. Utökning genom dessa konstruktioner ska kunna ske utan påverkan på konsumenter eller producenter som förlitar sig på grundformatet, så länge inte bruten bakåtkompatibilitet uttryckligen angivits enligt överenskommen standard.
Hantering RIV-TA profiler
Denna version har inget stöd för konvertering mellan RIV-TA-profiler, eftersom det bara finns en profil att ta hänsyn till. Däremot är implementationen förberedd på att hantera denna typ av konvertering. Alla Logiska Adresser som matchar given producent(Logisk Adressat),
Tjänstekontrakt och tidpunkt hämtas ut från Tjänstekatalogen. Det kan då finnas flera träffar med olika RIV-TA-profiler. I version 1.0 väljs den som matchande RIV-TA-profil och ett fel skapas om den saknas.
VP har stöd för konvertering mellan RIV TA BP 2.0 och BP 2.1.
Felhantering
Alla former av fel kan spåras i efterhand då dessa loggas persistent. Lognivå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.
Standardiserade felkoder
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. |
Icke funktionella krav
Prestandakrav
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.
Skalbarhet
Virtualiseringsplattformen stödjer gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer.
Säkerhet
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).
Se vidare kapitlet om säkerhet.
Utökningsbarhet
TP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler.
Flexibilitet
TP kan driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner.
Monitorering
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. TP loggar på logformat lämpliga för övervakning av gängse övervakningsverktyg.
Tillgänglighet
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.
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.
Interoperabilitet
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.
Öppenhet
TP levereras som öppen källkod under licensen LGPL.
Säkerhet
Säkerheten i version 1 av tjänsteplattformen baseras på protokollsäkerhet via SSL i enlighet med RIV Tekniska Anvisningar Basic Profile 2.0. Virtualiseringsplattformen utför även behörighetskontroll av anropande tjänstekonsument för den resurs som efterfrågas.
VP nyttjar HCC funktionscertifikat för att åstadkomma transportsäkerhet mellan tjänster via https. En tjänstekonsuments certifikat (del av subject) används dessutom som identifikation av tjänstekonsumenten i virtuella tjänster (HSA-Id), i syfte att verifiera anropsbehörighet till härledd tjänsteproducent.
Autentisering
Anrop mot TP sker via HTTPS. Detta protokoll är HTTP över SSL/TLS och stödjer klient autentisering med hjälp av klientens X509 certifikat. Detta kallas även för ”mutual authentication”, förklaras mer under avsnitt 9.3 nedan. Då man upprättat en förbindelse över HTTPS har man även erhållit insynsskydd av de meddelanden som transporteras. Tjänsteplattformens grundfunktionalitet är att dirigera anrop från tjänstekonsumenter via VP till tjänsteproducenter. Detta innebär att vi kommer att etablera 2 säkra förbindelser, en från tjänstekonsumenten till virtualiseringplattformen(1) och en från virtualiseringplattformen till tjänsteproducenten(2), se bild nedan.
I förbindelse 1 fungerar virtualiseringplattformen certifikat som server certifikat och i förbindelse 2 fungerar samma certifikat som klient certifikat. Om en förbindelse sker genom federerade virtualiseringplattformar så ser det se ut som bilden nedan.
Detta innebär att en tjänsteproducent autentiserar anropande TP genom att lita på den CA som är utställare av VP's certifikat.
Auktorisation
Allt underlag för behörighetsbeslut finns lagrat i TK. 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.
- VP kontrollerar tjänstekonsumentens behörighet att anropa tjänsteproducenten. Tjänstekonsumentens certifikat (Certifikat K) innehåller ett HSA-ID som används som sändarens identitet. Denna identitet måste finnas registrerad i TK som en giltig konsument av den tjänst som tjänsteproducenten exponerar. På detta sätt flyttas behörighetskontrollen ut till VP.
- Tjänsteproducenten får ett inkommande anrop (2) från VP med dess certifikat (Certifikat VP) som identifikation. Tjänsteproducenten auktoriserar VP. Detta genomförs förslagsvis genom ACL-funktionalitet i den infrastruktur som används av tjänstproducenten. Exempel på mjukvaror som har denna funktionalitet är Apache HTTPD (http://httpd.apache.org) och Squid (http://squid-cache.org).
Motsvarande bild vid federerade virtualiseringsplattformar ser ut som nedan:
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.
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.
I det enklaste fallet, med enbart en tjänsteplattform i anropskedjan, så bilden enligt följande:
Dvs VP kommer både göra behörighetskontroll och sätta header för ursprunglig avsändare med samma HSA-ID, kallat "Ursprungs-HSA-ID
" i bilden ovan).
Ökar man på komplexiteten genom att införa en regional tjänsteplattform konsumentsidan så ser man i bilden nedan att:
- Det blir nu den regionala tjänsteplattformen som gör behörighetskontroll på den ursprunglige konsumentens HSA-ID och som sätter http-headern.
- Den nationella tjänsteplattformen skickar nu bara vidare headern samt gör nu inte behörighetskontroll på den ursprunglige konsumentens HSA-ID utan på HSA-ID för den mest näraliggande komponenten i anropskedjan, dvs den regionala tjänsteplattformens HSA-ID.
Lägger man till sist på en regional tjänsteplattform även på producent-sidan så blir bilden följande:
Dvs, den regionala tjänsteplattform på producent-sidan kommer att agera på liknande sätt som den nationella tjänsteplattformen:
- 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.
Lastbalanserare och 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
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.