SKLTP VP SAD (Mule) - 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.

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

Funktionella krav

Detaljerade krav på funktionalitet i Virtualiseringsplattformen. 

Standardiserade felkoder

Implementationen av en virtualiseringsplattform skall returnera standardiserade SoapFault - felmeddelanden enligt följande:

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.

Anrop mot VP 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 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 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.

• VP kontrollerar tjänstekonsumentens behörighet att anropa tjänsteproducenten. Tjänstekonsumentens certifikat (Konsument certifikat) innehåller ett HSA-ID som används som sändarens identitet. Denna identitet måste finnas registrerad i TAK 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 (NTjP certifikat) 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.

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.

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.

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"
• 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.

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.

1. Klienten sänder en begäran att nå en skyddad resurs, typ https://aaa.bbb
2. Servern svarar med att skicka sitt certifikat samt en begäran om att klienten skall skicka sitt certifikat till servern.
3. Klienten validerar serverns certifikat mot sitt sk truststore.
4. Klienten sänder sitt certifikat till servern.
5. Servern validerar klientens certifikat mot sitt truststore.
6. 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:

1. 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.
2. Samtyckestjänsten adresseras på vårdgivarenivå.
3. NPÖ är en nationell konsument av samtyckestjänsten som därmed skall ha behörighet för alla vårdgivare i Sverige.
4. 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: