Implementation av Regional Tjänsteplattform. Version 1.0

Transkript

1 Implementation av Regional Tjänsteplattform

2 Innehållsförteckning Förord... 4 Nomenklatur... 4 Bakgrund... 7 Sammanfattning... 7 Förberedelser Produktionsmiljö Testmiljö Maskiner Produktionsmiljö Testmiljö Brandvägg Produktionsmiljö Testmiljö Certifikat Produktionsmiljö Testmiljö Truststore Tjänsteplattform Övriga beroenden Publiceringsplattform Övriga verktyg SoapUI OpenSSL Installation Tjänsteplattform Publiceringsplattform Certifikat Truststore Konfigurering SSL Reverseproxy Lastbalansering Tjänstekatalogen Konfigurering av regionala tjänsteplattformens tjänstekatalog Konfigurering av lokala nationella tjänsteplattformens tjänstekatalog Uppdatering av tjänsteplattformens cache Anslutningshantering Färdigpaketerade tjänster Installation av tjänstekontrakt Verifiering av tjänst Anslutning av konsumentapplikation Anslutning av producentsystem Etablera samverkan Anslutning till nationell tjänsteplattform Drift av en regional tjänsteplattform Förvaltning av regional tjänsteplattform Sid 2/57

3 Revisionshistorik Version Författare Kommentar 0.5 Peter Back, Omegapoint Första versionen 1.0 Peter Back, Omegapoint Omdöpt och klar för publicering Sid 3/57

4 Förord Detta dokument är baserat på resultatet av det arbete som bedrivits hos huvudmannen Landstinget Dalarna och dennes tolkning av den nationella arkitekturen. Dokumentet har tagits fram på uppdrag av CeHis och Inera med syftet att ge stöd, tips och inspiration till andra huvudmän som befinner sig i en motsvarande situation där användning av en regional tjänsteplattform övervägs. Vissa termer som förekommer i dokumentet används enbart hos huvudmannen och har inte en nationell förankring. Författaren ber om läsarens överseende med detta. Nomenklatur Dokumentet använder ett antal olika begrepp för att beskriva arkitekturen och de involverade komponenterna. För att öka läsbarheten och förståelsen av dokumentets innehåll förklaras dessa termer i nedanstående tabell: Nomenklatur Fullständigt namn Förkortning Beskrivning Demilitariserad zon DMZ Platsen mellan den yttre och den inre brandväggen. Enterprise Service Bus ESB En serverfunktion som kan köra tjänster Konsument Den som anropar en producent via en tjänsteplattform och konsumerar svaret. Konsumenten kan vara en nationell applikation (exempelvis MVK) eller den nationella tjänsteplattformen beroende från vilken referenspunkt arkitekturen betraktas. Vanligtvis anses konsumenten vara den som initierar anropskedjan från början. Lastbalanserare LB Funktion för fördelning av anropslast mellan två eller flera virtualiseringsplattformar. Mina VårdKontakter MVK Nationell applikation för medborgare ( Nationell tjänsteplattform NTP Producent Den tjänsteplattform (inklusive virtualiseringsplattform och tjänstekatalog) som driftas för nationell användning. Producenten är den som tar emot ett anrop och returnerar ett svar. Den regionala tjänsteplattformen kan ses vara en producent sett från den nationella tjänsteplattformens perspektiv. Det interna system som exempelvis adresseras av den regionala tjänsteplattformen är en producent ur dennes synpunkt. Vanligtvis anses dock producenten vara den som i slutändan returnerar ett svar på en fråga. Publiceringsplattform* PP Begreppet omfattar de ingående komponenterna reverseproxy samt lastbalanserare (se kommentar nedan). Publiceringsplattformen används lokalt hos huvudmannen för att möjliggöra åtkomst till de tjänster som körs på den regionala tjänsteplattformen i huvudmannens lokala nät. Regelverk för Interoperabilitet inom Vård och omsorg - Tekniska anvisningar RIV-TA Regional tjänsteplattform RTP Anvisning som beskriver hur informationsutbyte realiseras mellan två parter. Den tjänsteplattform som finns lokalt hos respektive huvudman. Den regionala tjänsteplattformen omfattar liksom den nationella tjänsteplattformen - även virtualiseringsplattformen och tjänstekatalogen. Sid 4/57

5 Reverseproxy RP Tar emot anrop och styr dessa vidare till den regionala tjänsteplattformen, den nationella tjänsteplattformen eller andra producenter beroende på anropsriktning och inställningar. Identifierar sig gentemot den nationella tjänsteplattformen med huvudmannens publika certifikat för sjunet. Tjänstekatalog TK Del av tjänsteplattformen. Tjänstekatalogen består av en databas och ett administratörsgränssnitt där adressinformation och anropsbehörigheter matas in och lagras. Virtualiseringsplattformen använder innehållet i databasen för att hämta logiska adressater, logiska adresser, anropsbehörigheter till dess mm. Tjänstekontrakt Regelverk för kommunikation mellan konsumenter och producenter baserat på RIV-TA. Tjänsteplattform TP Begreppet omfattar de ingående funktionerna virtualiseringsplattform samt tjänstekatalog Virtualiseringsplattform VP Del av tjänsteplattformen. Virtualiseringsplattformen körs ovanpå ESBprodukten Mule och tar emot anrop som adresserats till RIVTA-tjänster. Virtualiseringsplattformen använder tjänstekatalogen för vägval av vart inkommande anrop till tjänst ska skickas vidare. Virtuell tjänst En tjänst som skapats utifrån ett tjänstekontrakt och som exekverar inom ramen för tjänsteplattformen. Den virtuella tjänsten utgör en anslutningspunkt för konsumenter och vidarebefordrar anropen till adresserad tjänsteproducent. * Begreppet Publiceringsplattform kommer från huvudmannen Landstinget Dalarnas interna namnsättning och är inte nationellt förankrad. Termen används i dokumentet för att abstrahera funktioner så som reverseproxy och lastbalanserare. Sid 5/57

6 Som nomenklaturen ovan beskriver är tjänsteplattform ett samlingsnamn där virtualiseringsplattformen och tjänstekatalogen ingår. I förekommande bilder där ordet tjänsteplattform används förutsätts dessa funktioner inrymmas om inte någon av dessa har lyfts ut för förtydligandets skull.!"#$%&'()*+,-./ 01-&2*)1%'-1$3%()*+,-./!"#$%&'4*&*),3/ Figur 1: Tjänsteplattform med ingående funktioner Publiceringsplattform är ett samlingsnamn för funktionerna reverseproxy och lastbalanserare (termen är specifik för Landstinget Dalarna). Dessa kan ibland inrymmas i en produkt men kan lika väl vara realiserade med hjälp av flera enskilda produkter.!"#$%&'(%)*+,$-./(01 2'3'(+',(/ #-$-)+'(-('1 Figur 2: Publiceringsplattform med ingående funktioner Sid 6/57

7 Bakgrund I samband med att den nationella IT-strategin för vård och omsorg lanserades 2006 påbörjades arbetet med att definiera och fastställa en gemensam nationell infrastruktur för landets vårdgivare. Denna strategi omfattar bl.a. nationell PKI (SITHS), katalog (HSA), tjänster och samverkansarkitektur för informationsutbyte. Namnet på strategin ändrades 2010 till Nationell ehälsa för att även spegla hur framtidens vård och omsorg som helhet ska fungera och förbättras med hjälp av e-tjänster. Den tekniska arkitekturen för denna samverkan finns beskriven i VITS-bokens tekniska arkitektur, den s.k. T-boken. T-boken beskriver bl.a. nyttan med denna samverkan, vilka spelregler som gäller samt vilka lokala insatser som behövs. Den beskriver också hur tjänster interagerar med varandra, principer för hur tjänstekontrakt adresseras samt anslutningsarkitekturen för huvudmän. Detta dokument beskriver ett möjligt alternativ för realisering av denna anslutningsarkitektur på en regional nivå. Den nationella tjänsteplattform som omnämns i T-boken finns tillgänglig som öppen källkod på projektets hemsida hos Google Code - Sammanfattning Detta dokument beskriver hur en regional tjänsteplattform samt publiceringsplattform kan användas för att integrera huvudmannens interna system med den nationella tjänsteplattformen. En sådan integration gör att huvudmannens verksamhet kan fungera som producent till de nationella applikationerna som interagerar med den nationella tjänsteplattformen. Integrationen möjliggör kommunikation i båda riktningar d v s att den nationella tjänsteplattformen, eller andra huvudmän, också kan fungerar som producenter. Dokumentet går inte ned på detaljer kring installation av enskilda komponenter eller hantering av dialektala skillnader mellan olika miljöplattformar. Huvudsyftet med dokumentet är att förmedla ett exempel på hur en regional tjänsteplattform och publiceringsplattform kan installeras och konfigureras samt hur kommunikation mellan dessa och den nationella tjänsteplattformen kan realiseras. Den nationella tjänsteplattformen har utvecklats bl.a. med syftet att fungera som informationsförsörjare åt vårdens nationella applikationer. Virtuella tjänster på tjänsteplattformen anropas av applikationer och anropen förmedlas vidare till producenterna av denna information; t.ex. interna system hos huvudmannen, externa tjänster hos Försäkringskassan, Apoteket m fl. För att anropskedja ska fungera måste respektive producent tillhandahålla en anropskanal in till det bakomliggande systemet som normalt sett endast är åtkomligt via det lokala nätverket. Sid 7/57

8 Ett sätt att göra detta på är att installera en regional instans av den nationella tjänsteplattformen i det interna nätet hos huvudmannen och att låta den nationella tjänsteplattformen kommunicera direkt med den regionala instansen. De virtuella tjänster som anropas av applikationen på den nationella tjänsteplattformen måste även finnas tillgängliga på den regionala instansen. Vid anrop till dessa skickas anropet vidare till det bakomliggande systemet för bearbetning och returnering av svar. Vid anslutning av tjänster på den nationella tjänsteplattformen måste dessa konfigureras med anropsbehörigheter och adressinformation för vidarebefordring av inkommande anrop. Detta gäller också för den regionala tjänsteplattformen. Skillnaden mellan den nationella- och den regionala konfigureringen är att den regionala tjänsteplattformen ger anropsrättigheter till den nationella plattformen och adresserar den slutliga mottagaren av anropet i informationskedjan. 8$%,60&%)(!"#$%&''( )*+%,)&-'".$/0( 1&23$%"'( )*+%,)&-'".$/0( 4/$567&%)( Figur 3: Översikt anropskedja Kontaktytan mellan den nationella- och den regionala tjänsteplattformen sker i gränslandet mellan det yttre nätet och det lokala nätet. Vanligtvis hanteras denna kontaktyta av en brandvägg där konvertering mellan den yttre- och den inre IP-adressen sker (NAT). Brandväggen består ofta av en yttre- och en inre brandvägg. Mellan dessa brandväggar (DMZ) finns möjligheten att ta emot anropet, göra verifieringar och kontroller samt att styra anrop vidare genom den inre brandväggen till den regionala tjänsteplattformen. Hanteringen av inkommande anrop mot den regionala tjänsteplattformen (det interna nätet) kan hanteras av en publiceringsplattform. Denna omfattar funktionerna reverseproxy och lastbalansering där reverseproxyns uppgift är att verifiera den anropande parten med certifikat, presentera sig på motsvarande sätt mot konsumenten samt att vidarebefordra anropet till den regionala tjänsteplattformen efter motsvarande genomförda handskakningsprocess. Lastbalanseringsfunktionen kan användas för att växla mellan flera instanser av regionala tjänsteplattformar om så önskas. Orsaken till att publiceringsplattformen placeras i DMZ är för att möta upp anropet så tidigt som möjligt och om nödvändigt bryta anropskedjan innan denna har kommit in på det lokala nätet. Bilden nedan visar publiceringsplattformen samt den yttre och inre brandväggen som gula pelare. Sid 8/57

9 8$%,60&%)(!"#$%&''( )*+%,)&-'".$/0( 469'37&/3%2,: -'".$/0( 1&23$%"'( )*+%,)&-'".$/0( 4/$567&%)( Figur 4: Översikt med publiceringsplattform Fördelen med lastbalanseringsfunktionen är att en regional instans av tjänsteplattformen kan uppdateras eller uppgraderas under tiden som anrop styrs mot den andra instansen. När förändringarna är genomförda kan trafiken styras om till den modifierade tjänsteplattformen för verifiering och tester. Vid eventuella problem är det enkelt att återgå till den tidigare instansen under tiden som åtgärder vidtas. Om uppdateringen fungerade väl kan nästa instans uppdateras på motsvarande sätt. En annan fördel är att det enkelt går att skala upp lösningen med fler instanser av regionala tjänsteplattformar. :$%,80&%)(!"#$%&''( )*+%,)&-'".$/0( 68;'39&/3%2,< -'".$/0( 1&23$%"'( )*+%,)&-'".$/0( 45( 1&23$%"'( )*+%,)&-'".$/0( 4=( 6/$789&%)( Figur 5: Lastfördelning mellan två regionala tjänsteplattformar Sett från det regionala perspektivet finns även behovet av omvänd kommunikation; interna konsumenter behöver anropa den nationella tjänsteplattformen eller andra externa producenter på sjunet/internet alternativt andra producenter i det interna nätet. För att konsumenterna inte ska behöva kännedom om vilken eller eventuellt vilka regionala tjänsteplattformar som för tillfället är i produktion, kan det vara lämpligt att även låta dessa kommunicera via en intern publiceringsplattform. Denna kan då lastbalansera mellan de aktuella tjänsteplattformarna alternativt kommunicera direkt med den publiceringsplattform som står i DMZ för vidare anrop mot aktuell tjänst. Sid 9/57

10 9/$:8;&%)(!"#$%&''( )*+%,)&-'".$/0( 98<'3;&/3%2,= -'".$/0( 1&23$%"'( )*+%,)&-'".$/0( 45( 1&23$%"'( )*+%,)&-'".$/0( 46( 98<'3;&/3%2,= -'".$/0( 7$%,80&%)( Figur 6: Interna konsumenter Detta dokument går igenom förberedelser, steg och som vad som kan vara bra att tänka på i samband med uppsättning av publiceringsplattform samt regional tjänsteplattform i det interna nätet. Lösningen som presenteras i dokumentet består av en publiceringsplattform i DMZ, två regionala tjänsteplattformar (eller tydligare: två virtualiseringsplattformar och en tjänstekatalog) samt en intern publiceringsplattform för hantering av interna konsumenter. 9/$:8;&%)(!"#$%&''( )*+%,)&-'".$/0( 98<'3;&/3%2,= -'".$/0( 1&23$%"'( )*+%,)&-'".$/0( 45( 1&23$%"'( )*+%,)&-'".$/0( 46( 98<'3;&/3%2,= -'".$/0( 7$%,80&%)( Figur 7: Konceptuell box I bilden nedan visas alla ingående delar i lösningen. Här kan vi se att de regionala tjänsteplattformarna inrymmer en varsin virtualiseringsplattform och att det endast finns en tjänstekatalog som virtualiseringsplattformarna delar på. Sid 10/57

11 456($7"0$&#-8.('/%01)!"9"0-".0%:;) <'-*6'('&-"0'0")!"#$%&'() *+,&-*".('/%01) 23) =$0*5'($-"0$&#-8.('/%01)!"#$%&'() *+,&-*".('/%01) >+,&-*"?'*'(%#) 456($7"0$&#-8.('/%01)!"9"0-".0%:;) <'-*6'('&-"0'0") =$0*5'($-"0$&#-8.('/%01) Figur 8: Ingående detaljer Följande bild visar ett exempel taget från översikten av produktionsmiljö och testmiljö (figur 10 nedan). I respektive box har namnet på maskinen, certifikatet och den fiktiva IP-adressen angivits. Exemplet beskriver en av de två maskinerna där den regionala tjänsteplattformen körs: Maskinnamn: RTPServer1 (Regional Tjänsteplattform Server 1) Certifikat (CN): rtp.<domän>.se Maskinens fiktiva IP-adress: XXX.XXX.XXX.101 Funktionens namn: RTP1 (Regional Tjänsteplattform nr 1) RTPServer1 rtp.<domän>.se (XXX.XXX.XXX.101) RTP1 Figur 9: Exempel på beskrivning Sid 11/57

12 Översikt produktion- och testmiljö! <sjunet> Produktion: esb.ntjp.sjunet.org PPDMZServer Produktion: <namn>.<domän>.sjunet.org AAA.AAA.AAA.10 RTPServer1 rtp.<domän>.se (XXX.XXX.XXX.101) PPInternServer ppint.<domän>.se (XXX.XXX.XXX.1) NTP PP RTP1 Test: qa.esb.ntjp.sjunet.org PPDMZTestServer Testmiljö: <namn>.test.<domän>.sjunet.org AAA.AAA.AAA.20 RTPServer2 rtp.<domän>.se (XXX.XXX.XXX.102) TK PPInt NTPTest PPDMZTest RTP2 NTPTestServer ntptest.<domän>.se (XXX.XXX.XXX.2) PPTestServer pptest.<domän>.se (XXX.XXX.XXX.20) RTPTestServer1 rtptest.<domän>.se (XXX.XXX.XXX.201) PPTestServer NTPTestServer pptestint. <domän>.se RTPTest1 NTPTest PPTest RTPTestServer2 rtptest.<domän>.se (XXX.XXX.XXX.202) TK PPTestInt TK RTPTest2 Figur 10: Denna bild visar produktionsmiljö (övre raden) och testmiljö (nedre raden). Yttre och inre brandvägg är markerat i orange. I kommande kapitel kommer namnreferenser till denna bild användas. Sid 12/57

13 Förberedelser Produktionsmiljö Val av plattformsmiljö för publiceringsplattformen och den regionala tjänsteplattformen kommer i praktiken att bero på vilken plattform som idag används lokalt samt vilken kompetens och erfarenhet som finns tillgänglig. Det är lämpligt att förvaltningsorganisationen är involverade från början när produktionsmiljön designas. Även om tjänsteplattformen i sig är plattformsoberoende (kan köras i Windowsmiljö/Linuxmiljö m fl.) så blir det ändå, sett ur ett förvaltningsperspektiv skillnader i hur den kommer att behöva förvaltas; om filsystem kan länkas, hur tjänster driftsätts o s v. Designen av produktionsmiljön för den regionala tjänsteplattformen är beroende av ett flertal parametrar. Hänsyn måste tas till redundans, backup, möjlighet till att använda virtuella servrar (vilket starkt rekommenderas) alternativt fysiska, hur uppdateringar och uppgraderingar ska hanteras i ett produktionsscenario samt vilka kostnader de olika alternativen medför. Den nationella tjänsteplattformen har ett SLA-krav på 24/7. Detta är naturligt eftersom denna måste vara tillgänglig för de applikationer som använder plattformen. För den regionala tjänsteplattformen kan det vara annorlunda, men om det finns lokala producenter som konsumenter nyttjar via den nationella tjänsteplattformen, måste även den regionala tjänsteplattformen ha samma SLA-krav som finns på nationell nivå. Den regionala tjänsteplattformen smittas i grund och botten av de SLA som gäller för respektive tjänst som körs på plattformen. Vissa tjänster är av naturen sådan att de alltid måste vara tillgängliga medan andra kan köras med en möjlig lägre grad av beredskap och åtgärdsplan vid eventuella störningar. Alternativa flöden så som telefonsupport, mejl eller liknande kan innebära att en regional tjänsteplattform inte måste ha samma höga beredskap för tillgänglighet som den nationella. Men det innebär givetvis också en försämring av den service som t ex en nationell applikation kan tillhandahålla om den regionala tjänsteplattformen inte kan svara på förfrågningar. Vid designen av produktionsmiljön bör höjd tas för möjligheten att skala upp vid hög last och att kunna göra förändringar utan att produktionen påverkas. Om dessa faktorer tas med från början, även om de inte används initialt, förenklar detta avsevärt en senare förändring av miljön. Översiktsbilden för produktion och testmiljö ovan i kapitlet Sammanfattning (figur 10) visar ett förslag på en design där en server används för att köra en publiceringsplattform i DMZ (bilden nedan visar inte maskinen men publiceringsplattformen som koncept där den yttre och inre brandväggen är ritad som en del av plattformen). Sid 13/57

14 !"#$%&'(%)*+,$-./(01 2'3'(+',(/ #-$-)+'(-('1 Figur 11: Publiceringsplattformens funktioner i förhållande till yttre och inre brandvägg. Publiceringsplattformen kan i denna lösning fördela inkommande anrop mellan två instanser av virtualiseringsplattformen, där varje instans körs i en egen virtuell maskin. Plattformarna delar på samma tjänstekatalog där adresser, logiska adressater, anropsbehörigheter mm definieras. Detta minskar risken att drabbas av eventuella konfigurationsfel i samband med växling mellan virtualiseringsplattformarna. Dessa upptäcks istället direkt. Givetvis finns även alternativa lösningar till detta exempelvis en publiceringsplattform där reverseproxyfunktionen läggs i DMZ och lastbalanseringsfunktionen läggs innanför den inre brandväggen.!"#$%&'(%)*+,$-./(01 2'3'(+',(/ #-$-)+'(-('1 Figur 12: Lastbalanseringsfunktionen flyttad från DMZ till det interna nätverket Ytterligare alternativt är att båda dessa funktioner läggs i det interna nätet. Sid 14/57

15 !"#$%&'(%)*+,$-./(01 2'3'(+',(/ #-$-)+'(-('1 Figur 13: Reverseproxy- och lastbalanseringsfunktionen i interna nätverket Ett annat exempel skulle kunna vara att låta brandväggen sköta handskakningen utåt (förutsatt att den kan göra detta) och att skicka anropet direkt till en intern lastbalanserare. Valet av lösning beror helt enkelt på vilka möjligheter och produkter som finns hos huvudmannen i fråga. Testmiljö Testmiljön bör spegla designen på produktionsmiljön i största möjliga mån. Det finns behov av att köra interna tester där alla kommunikation sker i det interna nätet men även tester från den nationella testmiljön. För att möjliggöra tester i flera steg används i den föreslagna lösningen en lokal nationell tjänsteplattform som simulerar den nationella tjänsteplattformen men där huvudmannen själv har kontroll på miljön. Denna tjänsteplattform körs alltså i det lokala nätet men spelar rollen av en nationell tjänsteplattform i samband med interna tester. En möjlig testkedja efter upplägg av tjänster skulle kunna se ut som följer: 1. Lokalt test för verifiering av att konfigurering av tjänstekatalog och installationen av tjänster i den lokala tjänsteplattformen är korrekt: Konsument => NTPTest => PPTest => RTPTest1/RTPTest2 => Producent 2. Lokalt test för att verifiera att publiceringsplattformen i DMZ kan anropa tjänsterna: Konsument => NTPTest => PPDMZTest => RTPTest1/RTPTest2 => Producent 3. Nationellt test från den nationella testmiljön: Nationell konsument => NTPTest (nationell) => PPDMZTest => RTPTest1/RTPTest2 => Producent Sid 15/57

16 Givet att den beskrivna lösningen ska användas måste följande förberedelser vidtas innan installation och konfigurering av respektive del kan genomföras. Namnsättning refererar till tidigare nämnd översiktsbild (figur 10). Maskiner Maskinerna för produktionsmiljön och testmiljön kan med fördel vara virtuella. Produktionsmiljö Maskin för: Placering Kommentar Publiceringsplattform (PPDMZServer) Regional tjänsteplattform #1 (RTPServer1) Regional tjänsteplattform #2 (RTPServer2) Intern publiceringsplattform (PPInternServer) DMZ (sjunet) LAN LAN LAN Tar emot anrop, identifierar sig med SITHScertifikat och skickar anropen vidare till intern tjänsteplattform genom den inre brandväggen. Regional tjänsteplattform. På denna körs en instans av virtualiseringsplattformen. Regional tjänsteplattform. På denna körs en instans av virtualiseringsplattformen. Tar emot anrop från interna konsumenter vars mottagare är: 1. Interna producenter 2. Externa producenter 3. Externa producenter på den nationella tjänsteplattformen. På denna maskin installeras även tjänstekatalogen. Denna läses och delas av samtliga virtualiseringsplattformar i produktionsmiljön. Testmiljö Maskin för: Placering Kommentar Lokal Nationell tjänsteplattform för test i lokala nätet (NTPTestServer) Publiceringsplattform (PPDMZTestServer) Publiceringsplattform (PPTestServer) LAN DMZ (sjunet) LAN Denna simulerade nationella tjänsteplattform kan användas för att testa nationella anrop i det lokala nätet(*) Tar emot anrop, identifierar sig med SITHScertifikat och skickar anropen vidare till intern tjänsteplattform genom den inre brandväggen. Speglar publiceringsplattformen i DMZ för interna tester Sid 16/57

17 Regional tjänsteplattform #1 (RTPTestServer1) Regional tjänsteplattform #2 (RTPTestServer2) Intern publiceringsplattform. Denna kan köras på NTPTestServer för att minska antalet servrar i testmiljön. Tjänstekatalogen för RTPTestServer1 och RTPTestServer2 kan köras på NTPTestServer av samma anledning. Alternativt körs både publiceringsplattformen och tjänstekatalog på en separat server. LAN LAN LAN Regional tjänsteplattform. På denna körs en instans av virtualiseringsplattformen. Regional tjänsteplattform. På denna körs en instans av virtualiseringsplattformen. Tar emot interna anrop vars mottagare är: 1. Interna producenter 2. Externa producenter 3. Externa producenter på den nationella tjänsteplattformen. (*) Den simulerade nationella tjänsteplattformen skulle kunna placeras på sjunet - vilket då skulle ge fördelen att anropen går genom yttre- och inre brandväggen samt den publiceringsplattform som används vid nationella tester. Brandvägg Anrop från den nationella tjänsteplattformen sker via HTTPS på port 443 och måste släppas in genom den yttre brandväggen. Den inre brandväggen måste i sin tur öppnas till regional tjänsteplattform #1 och #2 (i detta fall) för att anropet ska kunna skickas vidare in till det lokala nätet. Ett alternativ till detta är exempelvis att öppna endast en ingång i den inre brandväggen och lastbalansera mellan virtualiseringsplattformarna i det interna nätet. Möjligheter och begränsningar beror på den lokala miljön och utrustningen i denna. Produktionsmiljö IP-adress Riktning IP-adress Kommentar esb.ntjp.sjunet.org ó AAA.AAA.AAA.10 Inkommande och utgående anrop mellan publiceringsplattformen i DMZ och den nationella tjänsteplattformen AAA.AAA.AAA.10 ó XXX.XXX.XXX.101 Inkommande och utgående anrop mellan regional tjänsteplattform #1 och publiceringsplattform i DMZ AAA.AAA.AAA.10 ó XXX.XXX.XXX.102 Inkommande och utgående anrop mellan regional tjänsteplattform #2 och publiceringsplattform i DMZ Sid 17/57

18 Testmiljö IP-adress Riktning IP-adress Kommentar qa.esb.ntjp.sjunet.org ó AAA.AAA.AAA.20 Inkommande och utgående anrop mellan publiceringsplattformen i DMZ och den nationella tjänsteplattformen AAA.AAA.AAA.20 ó XXX.XXX.XXX.201 Inkommande och utgående anrop mellan regional tjänsteplattform #1 och publiceringsplattformen i DMZ AAA.AAA.AAA.20 ó XXX.XXX.XXX.202 Inkommande och utgående anrop mellan regional tjänsteplattform #2 och publiceringsplattformen i DMZ XXX.XXX.XXX.2 => AAA.AAA.AAA.20 Anrop från lokalt simulerad nationell tjänsteplattform för tester Certifikat Mottagare av anrop från den nationella tjänsteplattformen måste kunna identifiera sig med ett giltigt SITHS-certifikat. DNS-namnet för den publika IP-adress som huvudmannen använder måste speglas i certifikatets CN (common name). Detta gäller för både produktionsmiljö och testmiljö. Certifikaten installeras på respektive publiceringsplattform i DMZ och används vid handskakning med den nationella och den regionala tjänsteplattformen. För certifikat i produktion används SITHS CA v3 vid utfärdande av funktionscertifikat. För testmiljön används SITHS CA TEST v4. Notera att den nationella testmiljön använder ett certifikat utfärdat av SITHS CA v3 d v s CA för produktion. Det innebär att även denna måste finnas med i truststore för att anropen ska accepteras. Under 2012 förväntas SITHS CA uppdateras till version 5. För att skapa ett funktionscertifikat måste DNS-namnet för servercertifikatet läggas in i HSAkatalogen på lämplig plats i funktionsträdet. I samband med detta skapas det HSAID som, när certifikatet skapas, läggs in som serialnumber i certifikatet. Detta HSAID används sedan vid konfiguration av anropsbehörigheter i tjänstekatalogen och valideras i samband med anrop till tjänsteplattformen. Certifikatet skapas via SITHS-Admin. Personen som utfärdar certifikatet måste ha RA/ORA/LRA-behörigheter kopplade till sitt tjänstekort som används vid inloggning i applikationen. Detta arbete utförs normalt av etjänstekortsförvaltningen hos respektive huvudman. Följande certifikat måste skapas. Observera att namnsättning för certifikat som används internt givetvis inte är tvingande; rtp.<domän>.se kan exempelvis heta ltp.<domän>.se, tp.<domän>.se eller liknande. Viktigt är dock att certifikat som kommunicerar ut på sjunet följer mönstret xxx.<domän>.sjunet.org, där <domän> är huvudmannens domännamn. Sid 18/57

19 Produktionsmiljö Certifikatsnamn (CN) <namn>.<domän>.sjunet.org rtp.<domän>.se ppint.<domän>.se Kommentar Detta certifikat används av publiceringsplattformen när denna identifierar sig mot nationella tjänsteplattformen. Exempel eservice.ltdalarna.sjunet.org Används av den lokala tjänsteplattformen när denna identifierar sig mot publiceringsplattformen (DMZ och internt) samt interna producenter Används av den interna publiceringsplattformen då denne identifierar sig mot interna konsumenter samt lokal tjänsteplattform Testmiljö Certifikatsnamn (CN) <namn>.test.<domän>.sjunet.org rtptest.<domän>.se pptest.<domän>.se pptestint.<domän>.se ntptest.<domän>.se consumertest.<domän>.se producertest.<domän>.se Kommentar Detta certifikat används av publiceringsplattformen när denna identifierar sig mot nationella tjänsteplattformens testmiljö. Exempel eservicetest.ltdalarna.sjunet.org Används av den regionala tjänsteplattformen när denna identifierar sig mot publiceringsplattformen (DMZ och internt) samt interna producenter Används av den lokala motsvarigheten till publiceringsplattformen i DMZ då denna identifierar sig mot lokal nationell tjänsteplattform samt regional tjänsteplattform. Används av den interna publiceringsplattformen då denne identifierar sig mot interna konsumenter samt regional tjänsteplattform Används då den lokala nationella tjänsteplattformen identifierar sig mot publiceringsplattformen (DMZ och LAN) Ett certifikat för konsumenten som används vid testanrop Ett certifikat för producent som används vid testanrop Sid 19/57

20 Truststore Tjänsteplattformen och publiceringsplattformen använder truststore för att verifiera den anropande partens certifikat i samband med handskakningen. För att bygga dessa truststore behöver vi tillgång till SITHS publika rootcertifikat. Dessa kan hämtas från Ineras hemsida på adressen SITHS-CA/. Följande certifikat ska hämtas: Rootcertifikat Kommentar SITHS CA version 3 För produktion SITHS CA version 4 För produktion SITHS CA TEST version 3 För testmiljö SITHS CA TEST version 4 För testmiljö SITHS CA version 5 För produktion (kommer under 2012) SITHS CA TEST version 5 För testmiljö (kommer under 2012) Tjänsteplattform Tjänsteplattformen kan laddas ner från projektets hemsida som komprimerad binär. Detta är det rekommenderade tillvägagångssättet. Aktuell information och vidare beskrivning kan läsas på Ineras hemsida Kontakta Inera om något är oklart (kundservice nås på kundservice@inera.se). Ett alternativt till detta är att hämta hem källkoden för lokal kompilering. Koden är tillgänglig via Subversion och beroende på vilket verktyg för versionshantering som används så kan proceduren se lite olika ut. Nedanstående kommando visar hur utcheckning av koden på trunk kan se ut. svn checkout <namn-påkatalog> Bilden nedan visar en del av källkodsträdet i projektet. Sid 20/57

21 Figur 14: Källkodsträd i subversion Notera att tjänsteplattformens virtualiseringsplattform (VP) är beroende av flera projekt för att bygga. Detaljerade beskrivningar och aktuella instruktioner kring hur tjänsteplattformen byggs finns tillgängliga på projektets hemsida. Övriga beroenden Tjänsteplattformen är beroende av ett antal komponenter som måste installeras innan plattformen själv kan installeras. Aktuella beroenden finns beskrivna på projektets hemsida och instruktioner kring nedladdning av dessa hänvisas till dessa. I skrivande stund finns följande beroenden: Beroenden Java Mule Apache ActiveMQ Apache Tomcat MySQL Kommentar Tjänsteplattformen är Java-baserad Tjänsteplattformen körs på Mule (integrationsplattform) Köhanterare för loggutskrifter till databas Hanterar administratörsgränssnitt samt sökgränssnitt mot tjänstekatalogen Databas för tjänstekatalog och loggning Sid 21/57

22 Publiceringsplattform I denna beskrivning används Apache HTTPD-server som publiceringsplattform. Apache inkluderar både reverseproxy- och lastbalanserarfunktionerna. Webbservern hämtas på projektets hemsida Notera att det är binären inklusive OpenSSL som ska användas. Övriga verktyg SoapUI För tester av anrop till tjänsteplattformen kan verktyget SoapUI används. Detta kan, baserat på tjänsternas WSDL-filer samt schemafiler skapa klientanrop och stubbar för svar på anrop så kallade mocktjänster. Detta är väldigt praktiskt då verifiering av tjänstekatalogens konfiguration och tjänstens installation ska verifieras. Detsamma gäller vid senare verifiering av den skarpa producentens svar, kontroll av anrop via brandväggar etc. SoapUI kan även användas för att skapa testfall och lasttester. Verktyget kan hämtas på projektets hemsida OpenSSL Certifikat som skapas via SITHS-admin levereras som PKCS#12-filer (p12:or). Tjänsteplattformen kan använda dessa utan vidare bearbetning alternativt kan dessa konverteras till java-keystores men Apache föredrar certifikaten i PEM-format. För att tillverka dessa rekommenderas verktyget OpenSSL, som kan hämtas på Sid 22/57

23 Installation Innan installationen påbörjas kan det vara bra att tänka igenom på vilka maskiner respektive delar ska installeras. Lämpligen påbörjas installationen av testmiljön då detta ger möjlighet till korrigering, verifiering och tester av plattformen och tjänster på denna. Som översiktsbilden i kapitel sammanställning visar kan t.ex. PPTestInt samexistera på samma maskin som NTPTest och dennes tjänstekatalog. Detsamma gäller tjänstekatalogen för alla regionala tjänsteplattformsinstanser (RTPTest1/RTPTest2). Deras tjänstekatalog kan installeras på PPTestServer utan att detta stör t.ex. val av portar etc. För enkelhetens skull utgår vi ifrån nedanstående bild där de regionala tjänsteplattformarnas (virtualiseringsplattformarnas) tjänstekatalog och den interna publiceringsplattformen installeras på en egen maskin (PPTestServer2). Notera att NTPTest är en lokal testmiljö för att simulera anrop från den nationella tjänsteplattformen. 7"!"#$%&#'(#'+*,"!"#$%&#'(#'*,-./0#11* %230$%#41-5/'6* "?*!!"#$%&#'(#'+*!;<19=#'908$> 41-5/'6* 7#89/0-1* %230$%#41-5/'6* :+* 7#89/0-1* %230$%#41-5/'6* :)* 7"!"#$%&#'(#')*!!"#$%&#'(#')* "?*!;<19=#'908$> 41-5/'6* Figur 15: Testmiljö med namngivna servrar Eftersom grundinstallationen av tjänsteplattformen är densamma för alla tre instanserna NTPTest, RTPTest1 och RTPTest2 kan det förenkla installationsprocessen att installera en tjänsteplattform på en maskin och sedan klona denna maskin till de övriga två. Detta förutsätter givetvis att virtuella maskiner används. I testmiljön kan det t o m vara en fördel om tjänsteplattformen, tjänstekatalogen och publiceringsplattformen installeras på en och samma maskin för att sedan klonas till övriga maskiner. På det sättet räcker det med att stänga av (eller att avstå från att aktivera) de delar som inte ska vara aktiva på respektive maskin. Detta alternativ ger mer frihet för egna tester och laborationer men kan också upplevas som mer komplex. Tjänsteplattform I stora drag består installationen tjänsteplattformen av följande steg. Detta givet att allt ska installeras på en och samma maskin. Sid 23/57

24 1. Installation av Java 2. Installation av MySQL 3. Installation av Tomcat 4. Installation av Mule 5. Installation av tjänstekatalog 6. Installation av tjänsteplattform 7. (Installation av publiceringsplattform) För vår testmiljö gäller följande installationssteg: NTPTestServer 1. Installation av Java 2. Installation av MySQL 3. Installation av Tomcat 4. Installation av Mule 5. Installation av tjänstekatalog 6. Installation av tjänsteplattform PPTestServer1 1. Installation av publiceringsplattform RTPTestServer1/RTPTestServer2 1. Installation av Java 2. Installation av Mule 3. Installation av tjänsteplattform PPTestServer2 1. Installation av Java 2. Installation av MySQL 3. Installation av Tomcat 4. Installation av tjänstekatalog 5. Installation av publiceringsplattform För aktuella och detaljerade instruktioner som beskriver installationen av tjänsteplattformen, tjänstekatalogen samt verifiering av dessa hänvisas till respektive projekts hemsidor. Sid 24/57

25 Publiceringsplattform Som tidigare nämnts består publiceringsplattformen av funktionerna reverseproxy och lastbalansering. Apache har båda dessa funktioner inbyggda och dessa kan aktiveras genom konfigurering. Installationen av publiceringsplattformen initieras genom att först installera Apache HTTPDserver. Hur detta görs finns beskrivet på projektets hemsida Efter installationen återstår tre steg; installation av certifikat, konfigurering av servern så att den fungerar som en reverseproxy samt att aktivera lastbalanseringsfunktionaliteten. Certifikat För att kunna använda SITHS-certifikaten i Apache krävs att certifikatet och nyckel exporteras till separata filer. För detta ändamål används verktyget OpenSSL. Certifikatet som ska konverteras är alltså det som publiceringsplattformen använder sig av när denne identifierar sig mot NTPTest och RTPTestServer1/RTPTestServer2. Certifikatet är tidigare refererad med namnet pptest.<domän>.se, där <domän> ska ersättas med huvudmannens domän. Som exempel och för att öka läsbarheten används domänen huvudman.se. Följande kommandon körs i Windows kommandofönster eller Linux terminalfönster beroende på använd plattform: Exportera nyckel ur SITHS p12-filen: openssl pkcs12 in pptest.huvudman.se.p12 out pptest.huvudman.se.encrypted.key nocerts Exportera certifikatet ur p12-filen: openssl pkcs12 in pptest.huvudman.se.p12 clcerts nokeys -out pptest.huvudman.se.pem Ta bort krypteringen av nyckeln: openssl rsa in pptest.huvudman.se.encrypted.key -out pptest.huvudman.se.decrypted.key Filerna pptest.huvudman.se.pem och pptest.huvudman.se.decrypted.key används vid identifiering gentemot anropande part. För identifiering mot insidan d v s med den regionala tjänsteplattformen krävs ett certifikat i PEM-format som innehåller både certifikatet och nyckeln. Nyckeln får inte vara krypterad. Denna fil skapas på följande sätt: openssl pkcs12 in pptest.huvudman.se.p12 -out pptest.huvudman.se.certandkey.pem -nodes Sid 25/57

26 Certifikaten läggs sedan förslagsvis in i katalogen <installationskatalog>/conf/ssl/siths. Placeringen av certifikaten är valfri men följande instruktioner bygger på denna struktur. Truststore Apache använder truststore för att verifiera utgivaren av den anropande partens certifikat. Truststore skapas genom att de rotcertifikat som reverseproxyn ska lita på läggs in i en fil på exempelvis nedanstående sätt (Windows): copy siths_ca_test_version_4.cer + siths_ca_test_version_3.cer + siths_ca_version_3.cer truststore-siths-testv3-testv4-v3.pem eller (Linux): cat siths_ca_test_version_4.cer siths_ca_test_version_3.cer siths_ca_version_3.cer > truststore-siths-testv3-testv4-v3.pem Notera att rotcertifikaten måste vara PEM-formaterade för att detta ska fungera annars måste de först konverteras till detta format. Notera även att den nationella testmiljön använder ett certifikat som har utfärdats av SITHS CA v3, varför även detta måste finnas med i truststore-filen för testmiljön. En ytterligare notering är att vissa av rotcertifikaten som kan hämtas från Ineras hemsida innehåller blankrader i PEM-formateringen. Dessa måste tas bort innan de läggs in i truststore. Alla rotcertifikat måste också avslutas med ett nyradstecken vilket inte alla gör. Manuell editering är alltså nödvändig för att få ett korrekt fungerande truststore. Konfigurering Konfigurationsfilen för Apache återfinns i <installationskatalog>/conf. Filen heter httpd.conf. Följande punkter beskriver de tillägg som måste göras i konfigurationsfilen för att få Apache att fungera som en reverseproxy. Notera att de IP-adresser som används är de fiktiva adresser som finns angivna i översiktsbilden över produktions och testmiljön. Först och främst så vill vi lyssna efter anrop till maskinens IP-adress på port 443: Listen XXX.XXX.XXX.20:443 För konfigurering av beteendet vid anrop behöver vi namnge och skapa en virtuell host: NameVirtualHost XXX.XXX.XXX.20:443 <VirtualHost XXX.XXX.XXX.20:443> Därefter anges servernamnet som ska användas: ServerName pptest.huvudman.se Sid 26/57

27 SSL SSL-funktionen i Apache aktiveras genom att inkludera följande moduler dessa följer med vid installationen men måste laddas separat i konfigurationsfilen. LoadModule ssl_module modules/mod_ssl.so LoadModule headers_module modules/mod_headers.so Följande kommando slår på SSL-motorn och möjliggör att vi kan använda SSL/certifikat för identifiering och krypterad kommunikation: SSLEngine on Använd proxy-motorn och slå på InsecureRenegotiation för att kunna kommunicera med konsumenter/producenter som använder äldre version av OpenSSL än Denna inställning bör i framtiden stängas av beroende på om konsumenter/producenter är beroende av den eller inte. Inställningen kan teoretiskt öppna upp för man-in-the-middle prefix attacker enligt CVE ( men bedöms samtidigt som mindre trolig eftersom publiceringsplattformens kontakt med omvärlden är hårt styrd av den yttre och inre brandväggen samt att den endas tillåter kommunikation med identifierade parter. Fördelarna bedöms uppväga nackdelarna i detta läge men detta kan förstås omprövas i framtiden. SSLProxyEngine on SSLInsecureRenegotiation on Tillåt alla SSL-protokoll samt angivna ciphers. Dessa kan specificeras ner till ett fåtal beroende på framtida klienter. Om alla anges ökar chanserna för en konsument att hitta ett cipher som denne kan använda i samband med handskakningsprocessen: SSLProtocol all SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL Följande inställningar i konfigurationsfilen pekar ut vilket certifikat som plattformen ska använda sig av för identifiering gentemot en konsument, vilken nyckelfil som ska användas, utpekning av certifikatskedja och truststore: SSLCertificateFile pekar ut det PEM-formaterade SITHS-certifikatet som Apache använder för presentation gentemot konsumenter. SSLCertificateFile "<installationskatalog>/conf/ssl/siths/pptest.huvudman.se.pem" SSLCertificateKeyFile pekar ut certifikatets nyckelfil. Sid 27/57

28 SSLCertificateKeyFile "<installationskatalog>/conf/ssl/siths/pptest.huvudman.se.decrypted.ke y" SSLCertificateChainFile pekar ut certifikatet. SSLCertificateChainFile "<installationskatalog>/conf/ssl/siths /pptest.huvudman.se.pem" Publiceringsplattformen använder SSLCertificateFile och SSLCertifikateKeyFile för identifiering gentemot konsumenten. SSLProxyMachineCertificateFile används för identifiering gentemot producenten i detta fall den regionala tjänsteplattformen. SSLProxyMachineCertificateFile "<installationskatalog>/conf/ssl/siths/pptest.huvudman.se.certandkey.p em" SSLCACertifcateFile innehåller de utgivare (CA) av certifikat som publiceringsplattformen ska lita på. SSLCACertificateFile "<installationskatalog>/conf/ssl/siths/truststore-siths-testv3-testv4- v3.pem" Reverseproxy Reverseproxy-funktionen i Apache aktiveras genom att inkludera följande moduler dessa följer med vid installationen men måste laddas separat i konfigurationsfilen. LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule setenvif_module modules/mod_setenvif.so Deaktivera ProxyRequests och använd istället ProxyPass för proxyhanteringen. ProxyRequests skulle kunna användas eftersom miljön är hårt kontrollerad och åtkomst endast ges till utvalda klienter men funktionaliteten går att få genom ProxyPass och denna är att betrakta som säkrare. ProxyRequests Off ProxyPreserveHost On Nedanstående inställning kan verka lite konstig eftersom den tillåter åtkomst för alla konsumenter som anropar denna virtuella host. Åtkomsten för produktionsmiljön hanteras dock i den yttre brandväggen; där endast anrop från esb.ntjp.sjunet.org samt qa.esb.ntjp.sjunet.org tillåts eller bör tillåtas. Åtkomst till publiceringsplattformen kan begränsas med nedanstående inställningar. Initialt kan det vara smidigt att tillåta anrop från alla maskiner men detta bör givetvis begränsas Sid 28/57

29 framförallt i produktionsmiljön. Där styrs givetvis åtkomsten, som tidigare nämnts, även av reglerna i brandväggarna. <Proxy *> Order deny,allow Deny from all Allow from all # Exempel på begränsad åtkomst (ersätter Allow from all ovan) #Allow from XXX.XXX.XXX.20 #Allow from ntptest.huvudman.se </Proxy> Följande konfigurering visar ett exempel på en hantering av utåtgående anrop d v s när anropet kommer från den regionala tjänsteplattformen till publiceringsplattformen och ska vidare till den nationella tjänsteplattformen alternativt till annan producent. ProxyPass /out/ ProxyPassReverse /out/ <Location /out/> SSLVerifyClient require SSLVerifyDepth 1 SSLOptions +StdEnvVars +ExportCertData </Location> Anropet av tjänsten föregås av en baseuri i det här fallet /out/ som gör att publiceringsplattformen kan fånga upp anropet och skickar detta vidare till angiven adress; Det innebär exempelvis att följande anrop från den lokala tjänsteplattformen fångas upp: Adressen omvandlas till följande av publiceringsplattformen: På motsvarande sätt konfigureras anrop som kommer från den nationella tjänsteplattformen och ska vidare till den regionala tjänsteplattformen. Konfigureringen nedan visar grundinställningen d v s där / används som baseuri. I detta fall kommer anrop till publiceringsplattformen att skickas vidare till den regionala tjänsteplattformen rtptest.huvudman.se. Den regionala tjänsteplattformen lyssnar på baseuri /vp och port 443 varför detta måste anges (porten Sid 29/57

30 behöver inte anges i detta fall eftersom 443 är default för HTTPS-trafik men anges för tydlighetens skull): ProxyPass / ProxyPassReverse / <Location /> # Skicka med klientens certifikat i HTTP-header. # Detta läses av den regionala tjänsteplattformen. Nationella # tjänsteplattformen skickar certifikatet i x-vp-auth-cert # RequestHeader unset SSL_CLIENT_CERT RequestHeader set x-vp-auth-cert "%{SSL_CLIENT_CERT}s" SSLVerifyClient require SSLVerifyDepth 1 SSLOptions +StdEnvVars +ExportCertData </Location> Konfigureringen av Location / säger att klientens certifikat ska skickas med till den lokala tjänsteplattformen via HTTP-header. Notera raden: RequestHeader set x-vp-auth-cert "%{SSL_CLIENT_CERT}s" Detta för att den regionala tjänsteplattformen ska kunna verifiera konsumenten d v s den nationella tjänsteplattformen mot sitt truststore samt certifikatets angivna HSAID i tjänstekatalogen. Om certifikatet inte skickas vidare kommer publiceringsplattformens certifikat att användas istället och transparensen av publiceringsplattformen försvinner. Vidare sätts SSLVerifyClient till require för att tvinga fram en verifiering av konsumenten. Certifikatkedjans djup d v s hur långt ner certifikatet ska verifieras i kedjan sätts till 1 (eller valfritt djup) och StdEnvVars samt ExportCertData används för att skicka med attribut samt certifikatets innehåll till den lokala tjänsteplattformen. Dessa inställningar kan vara föremål för justering beroende på huvudmannens miljö och önskemål. Nedan följer ett exempel på en konfiguration av ett proxyanrop där en exakt match på hela URI krävs för att anropet ska skickas vidare: <Location /scheduling/getalltimetypes/1/rivtabp20> Skillnaden mellan denna definition av Location och de tidigare är att denna pekar ut exakt en tjänst och endast om konsumentens anrop matchar hela denna kommer anropet skickas vidare Sid 30/57

31 till tjänsten. De tidigare konfigurationerna använde endast baseuri som parameter för att avgöra om och vart anropet skulle skickas. På detta sätt kan tjänster exponeras en och en om så önskas. Alternativt görs alla tjänster som körs på den lokala tjänsteplattformen tillgängliga. Det går givetvis också att kombinera dessa ytterligare genom att skapa ett location-block som innehåller baseuri samt en del av adressen t.ex: <Location /scheduling/> Konfigurering av produktionsmiljön sker på motsvarande sätt som testmiljön. Det enda som egentligen skiljer mellan dessa är vilken IP-adress som publiceringsplattformen lyssnar på för inkommande anrop, servernamn, de certifikat som används, behöriga klienter (IP-adresser) och vilka utgivare som betraktas som tillförlitliga. Inkommande anrop till PPTest skickas vidare till adressen rtptest.huvudman.se:443/vp. Den regionala tjänsteplattformen i detta exempel lyssnar och tar emot anrop på denna adress: ProxyPass / ProxyPassReverse / Lastbalansering Lastbalanseringsfunktionen aktiveras genom att ladda följande moduler i konfigurationsfilen: LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule status_module modules/mod_status.so Tidigare i kapitlet Reverseproxy skickades anropen vidare direkt till rtptest.huvudman.se/vp men genom att aktivera lastbalanseringsfunktionen i Apache kan vi istället skicka anropen vidare till vårt kluster vpcluster. ProxyPass ProxyPassReverse / balancer://vpcluster/ / balancer://vpcluster/ Klustret definieras enligt nedan. BalanceMember pekar ut de tillgängliga regionala tjänsteplattformarna. <Proxy balancer://vpcluster> # Kluster # Notera att medlem nr 2 är satt som disabled (status=d) # vid omstart av apache. # BalancerMember BalancerMember status=d Sid 31/57

32 #ProxySet lbmethod=bytraffic ProxySet lbmethod=byrequests #ProxySet lbmethod=bybusyness </Proxy> Inställningen för ProxySet lbmethod används för att styra lastbalanseraren hur denna ska fördela lasten. Mer information om dessa finns på apache hemsida. Lastbalanseraren kan styras via en websida om så önskas. För att aktivera den funktionen definierar vi en Location där Balancer-manager används. Denna ingår vid installationen av Apache. # Manager för hantering av lastbalanserare (t.ex. för stänga # av maskiner i klustret). # <Location /balancer-manager> SetHandler balancer-manager Order Deny,Allow Deny from all Allow from # Tillåt åtkomst endast direkt från maskinen </Location> Sid 32/57

33 Tjänstekatalogen Tjänstekatalogen innehåller information om vilka tjänster som är tillgängliga och vem som har behörighet att anropa dessa. Tjänsterna måste först installeras i tjänsteplattformen och sedan konfigureras i tjänstekatalogen för att vara åtkomliga för anrop. Konfigurering av informationen i tjänstekatalogen sker via ett webbgränssnitt. Detta nås via adressen där maskinnamn ersätt med namnet där tjänstekatalogen är installerad alternativt localhost om sidan anropas direkt från maskinen. Figur 16: Tjänstekatalogens administratörsgränssnitts huvudsida Sid 33/57

34 Följande delar kan konfigureras via gränssnittet: Namn RIV-TA profiler Tjänstekontrakt Tjänstekomponenter (prod/kons) Logiska adressater Logiska adresser Anropsbehörigheter Beskrivning Används för att särskilja versioner av RIV-TAspecifikationen Namnrymder som används för definition och separation av tjänster Här definieras samtliga konsumenter och producenter som ska ha tillgång till och nås av tjänsteplattformen. Logiska och faktiska adresser. Logiska adressater som knyts mot en logisk adress samt anropsbehörighet. Logiska adresser där RIV-TA-profil, tjänstekontrakt, logisk adress och tjänsteproducent samt tillgänglighet definieras. Definition av tjänstekonsumenters behörigheter: koppling görs mellan konsument, kontrakt och logisk adressat Namnrymder definieras för varje tjänst. I namnrymden ingår även ett versionsnummer vilket gör det möjligt att köra fler versioner av en tjänst samtidigt. Exempel: urn:riv.insuranceprocess:healtreporting:registermedicalcertifikate:1:r ivtabp20 urn:riv.insuranceprocess:healtreporting:registermedicalcertifikate:3:r ivtabp20. Syftet med namnrymden är differentiera tjänsters namn och versioner samt att förtydliga vilket område/domän de verkar inom. Sid 34/57

35 Konfigurering av regionala tjänsteplattformens tjänstekatalog Kommande bilder går igenom exempel på inställning i den regionala tjänstekatalogen. Tjänsten som konfigureras heter GetAllTimeTypes och tillhör tidbokningstjänsterna. En konsument i det här fallet den lokala nationella tjänsteplattformen i testmiljön (som används för simulering av nationella anrop) kommer att anropa den regionala tjänsteplattformen med en angiven logisk adressat. I exemplet nedan används det HSAID som mammografiavdelningen har i huvudmannens organisationsträd i HSA-katalogen; SE CH. Figur 17: Upplägg av logisk adressat Sid 35/57

36 Går vi in på inställningarna för den logiska adressaten visas definierade anropsbehörigheter samt adresser till de upplagda tjänsterna. Anropsbehörigheterna och adresserna till tjänsten GetAllTimeTypes är markerade i bilderna. Figur 18: Anropsbehörighet till tjänsten GetAllTimeTypes Sid 36/57

37 Figur 19: Logisk adress till tjänsten GetAllTimeTypes Sid 37/57

38 Den logiska adressen för tjänsten visar att denna kopplar samman en RIVTA-profil, ett tjänstekontrakt och en tjänsteproducent. Tjänsteproducenten är den plats där den faktiska anropsadressen till producenten lagras. Namnet på producenten är definierad som Producent:Scheduling med anledning av att mottagande system svarar på samtliga anrop från de tjänster som ingår i tidbokningstjänsterna. Alla tjänster anropar således samma producentadress i just det här fallet. Figur 20: Logisk adress Sid 38/57

39 Producenten i detta exempel är inställd på att anropa en mocktjänst, d v s en tjänst som har skapats baserat på tjänstens WSDL-fil av verktyget SoapUI. Figur 21: Producentens adress. Anrop till den virtuella tjänsten kommer att skickas vidare till denna adress Sid 39/57

40 Anropsbehörigheterna för adressen kopplad till den logiska adressaten pekar ut en konsument som identifierar sig med HSATEST2-C6G. Detta är alltså konsumentens certifikats HSAID vilket hämtas från serialnumber i certifikatet. I vårt fall är detta den lokala nationella tjänsteplattformen som identifierar sig med detta certifikat. Anropsbehörigheten pekar ut att denna rättighet gäller den logiska adressaten samt tjänstekontraktet och att denna rättighet gäller under fem år. Figur 22: Tjänstekonsumentens anropsbehörigheter Sid 40/57

41 Konfigurering av lokala nationella tjänsteplattformens tjänstekatalog Den lokala nationella tjänsteplattformen (NTPTest) används i detta exempel för att anropa tjänsten GetAllTimeTypes hos den regionala tjänsteplattformen. Detta sker genom att en konsument (SoapUI) anropar den lokala nationella tjänsteplattformen, som i sin tur anropar den regionala tjänsteplattformen (RTPTest1/RTPTest2) via publiceringsplattformen (PPTest). Anropet går sedan vidare till den tidigare nämnda mocktjänsten. Följande bilder visar konfigureringen i den lokal nationella tjänsteplattformens tjänstekatalog. Den logiska adressaten som används i NTPTest är den samma som i den regionala tjänsteplattformen. Konsumenten måste ange den logiska adressaten i samband med anropet till tjänsten och denna måste konfigureras på motsvarande sätt som hos den regionala tjänsteplattformen. Figur 23: Logisk adressat - samma som i den regionala tjänsteplattformen Sid 41/57

42 Bilderna nedan visar anropsrättigheter och logisk adress för tjänsten se markeringar i bilderna. Figur 24: Anropsbehörighet Sid 42/57

43 Figur 25: Logisk adress Sid 43/57

44 Den logiska adressen pekar ut RIVTA-profilen, det aktuella tjänstekontraktet och vilken producent som skall kopplas. I detta exempel är producenten namngiven till Producent:Scheduling:GetAllTimeTypes I den nationella tjänsteplattformens fall kommer producenten alltid ha en ett-till-ett koppling mellan den nationella tjänsten och den regionala tjänsten. Det är först i den regionala tjänsteplattformen som denna relation kan ändras till en många-till-en koppling om den slutliga producenten kan svara på alla anrop. Figur 26: Logisk adress Sid 44/57

45 Den angivna adressen i detta exempel är satt till Hosten pptest.ltdalarna.se indikerar att anropet ska skickas från den lokala nationella tjänsteplattformen till publiceringsplattformen i testmiljön. Denna adress motsvarar den publika adress som huvudmannen använder mot sjunet (exempelvis rp.huvudman.sjunet.org) och som publiceringsplattformen i DMZ lyssnar på. Publiceringsplattformen kommer att ta emot detta anrop och adresskonvertera denna baserat på inställningarna i konfigurationsfilen (se kapitlet om publiceringsplattform). Figur 27: Anropet skickas till publiceringsplattformen Sid 45/57

46 Anropsrättigheterna för tjänsten i den lokala nationella tjänsteplattformen gäller konsumenten med HSAID HSATEST2-C9X, vilket är certifikatet som utgivits för consumertest.ltdalarna.se i testmiljön. Detta certifikat används av SoapUI när denna ska anropa tjänsten. Figur 28: Anropsbehörigheter för konsumentens HSAID Uppdatering av tjänsteplattformens cache Tjänsteplattformen läser in tjänstekatalogen i sin interna cache vid uppstart. Vid förändring av innehållet i tjänstekatalogen måste denna cache uppdateras för att ändringen ska slå igenom. Detta kan göras genom att starta om tjänsteplattformen alternativt genom att anropa en permanent tjänst via följande adress: Tjänsteplattformen återkopplar med texten: Vagval cache reset result = true Sid 46/57

47 Anslutningshantering Färdigpaketerade tjänster Följande kapitel kommer att beskriva hur tjänstekontrakt hämtas, konfigureras och paketeras till färdiga tjänster att installera i tjänstekatalogen. Detta manuella arbete kommer dock ersättas av färdigpaketerade tjänster som kan hämtas ner från skltpservices-projektets hemsida på adressen I skrivande stund saknas dock ett flertal av dessa paketeringar. Installation av tjänstekontrakt Tjänstekontrakten finns tillgänglig via adressen Kontrakten levereras i komprimerade zip-filer och valda kontrakt laddas ner lokalt av huvudmannen. Tjänster som ska köras på tjänsteplattformen paketeras i jarfiler (Java ARchive). Innan kontrakten kan paketeras i dessa måste tjänsten konfigureras. Tjänsten Tidbokning innehåller nedanstående katalogstruktur. Under /schemas/interactions/getalltimetypesinteraction återfinns schemafiler och WSDL-filer som beskriver tjänsten i fråga. Sid 47/57

48 Figur 29: Exempel på innehåll Innehållet i arkiven kan se lite olika ut beroende på när de skapades och vem som paketerade innehållet men grundläggande är att följande filer måste finnas: Filtyp WSDL XSD Beskrivning Fil som beskriver respektive tjänst. I exemplet SCHEDULING finns tjänsterna CancelBooking, GetAllTimeTypes, GetAvailableDates, GetAvailableTimeslots m fl Schemafiler som beskriver typer och förhållanden mellan dessa. Vanligtvis paketeras dessa i en katalog som heter schemas eller tjanstekontrakt beroende på hur gammal tjänsten är. De senare versionerna av tjänster använder vanligtvis schemas med underliggande interactions där samtliga tjänster har en egen underkatalog. Oavsett vilken katalogstruktur som valts så måste denna beskrivas i konfigurationsfilen för tjänsten. Filen måste ha namnet tp-virtuell-tjanst-config.xml eftersom tjänsteplattformen är konfigurerad att leta efter filer i arkiven med det namnet vid uppstart. Exemplet nedan visar ett urklipp från konfigurationsfilen för tjänsten scheduling- GetAlltimeTypes. Detta visar hur en tjänst konfigureras genom skapa en modell som innehåller den aktuella tjänsten. I exemplet heter modellen Scheduling-model och innehåller tjänsten GetAllTimeTypes. Sid 48/57

49 <model name="scheduling-model"> <service name="scheduling/getalltimetypes"> <inbound> <cxf:inbound-endpoint address= " wsdllocation= "classpath:/schemas/interactions/getalltimetypesinteraction/getalltimetypesinter action_1.0_rivtabp20.wsdl" servicename="getalltimetypesresponderservice" namespace= "urn:riv:crm:scheduling:getalltimetypes:1:rivtabp20" proxy="true" payload="envelope" synchronous="true" protocolconnector="vpproducerconnector" /> </inbound> <outbound> <pass-through-router> <outbound-endpoint address="vm://vagval-router" synchronous="true" transformer-refs="scheduling-rivtabp20"/> </pass-through-router> </outbound> </service> </model> Rekommendationen är att varje tjänst paketeras i en jarfil med tillhörande konfigurationsfil. Det är fullt möjligt att paketera alla tjänsterna i en enda jarfil om så önskas. Problem kan dock uppstå om en av tjänsterna släpps i en ny version och ska ersätta den tidigare driftsatta versionen. I det fallet måste jarfilen som innehåller den gamla versionen av tjänsten modifieras och driftsättas på nytt. Tjänsten i detta exempel är namnsatt till scheduling/getalltimetypes och definierar en inbound (en ingående kö) och en outbound (utgående kö). Inbound definierar en inbound-enpoint där ett antal propertyvärden sätts: Property adress servicename wsdllocation namespace Beskrivning Adressen till tjänsten när denna är driftsatt i tjänsteplattformen Namnet på tjänsten Var beskrivningsfilen för tjänsten finns. Detta beror förstås på katalogstrukturen och den fullständiga sökvägen måste anges I vilken namnrymd som tjänsten ska befinna sig Sid 49/57

50 Outbound använder en s.k. pass-through-router, vilket innebär att tjänsten i sig inte gör något med meddelanden som kommer in via inbound. Dessa skickas helt enkelt direkt vidare till passthrough-routern. Routern definierar sedan en s.k. outbound-endpoint på adressen vm://vagvalrouter. Detta är ingången till meddelandehanteringen som utförs av tjänsteplattformen (se definition av tjänsten lite längre ner). Konfigurationsfilens uppgift är att bestämma hur tjänsten ska adresseras samt att styra meddelandet till tjänsteplattformens vägvalsfunktion (vm://vagval-router). Denna använder sedan informationen från tjänstekatalogen för att skicka vidare meddelandet. Adressattributens värden för tp.host, tp.port och tp.baseuri hämtas från tjänsteplattformens konfigurationsfil. Aktuell beskrivning för hur tjänster ska paketeras finns beskrivet på projektets hemsida men i stora drag gäller följande: 1. Packa upp den hämtade zipfilen med tjänsterna 2. Skapa en ny katalog 3. Kopiera WSDL-filen för tjänsten med bibehållen katalogstruktur till den nya katalogen 4. Kopiera tillhörande schemafiler med bibehållen katalogstruktur till den nya katalogen. 5. Skapa en fil med namnet tp-virtuell-tjanst-config.xml i den nya katalogen. 6. Kopiera mallen nedan till filen och ersätt följande placeholders: a. <MODELNAMN> - mot ett unikt modelnamn för tjänsten (valfritt) b. <SERVICE> - mot ett unikt servicenamn för tjänsten (valfritt) c. <TJANSTENAMN> - mot ett unikt namn på tjänsten d. <WSDLNAMN> - mot namnet på WSDL-filen inklusive hela sökvägen e. <SERVICENAME> - mot det servicenamn som återfinns i WSDL-filen. f. <NAMESPACE> - mot det namnspace som återfinns i WSDL-filen i form av targetnamespace. 7. Packa hela innehållet i den nya katalogen till en jarfil: a. jar cvf <filnamn>.jar * 8. Kopiera jarfilen till tjänsteplattformens katalog för tjänster 9. Starta om tjänsteplattformen för att driftsätta tjänsten Mall för tjänstens konfigurationsfil vp-virtuell-tjanst-config.xml: Sid 50/57

51 <mule xmlns=" xmlns:xsi=" xmlns:spring=" xmlns:cxf=" xmlns:https=" xsi:schemalocation=" <model name="<modelnamn>-model"> <service name="<service>-service"> <inbound> <cxf:inbound-endpoint address=" wsdllocation="classpath:/<wsdlnamn>" servicename="<servicenamn>" namespace="<namespace>" proxy="true" payload="envelope" synchronous="true" protocolconnector="vpproducerconnector" /> </inbound> <outbound> <pass-through-router> <outbound-endpoint address="vm://vagval-router" synchronous="true" /> </pass-through-router> </outbound> </service> </model> </mule> Verifiering av tjänsten görs enklast med verktyget SoapUI (se kapitlet Övriga verktyg). Sid 51/57

52 Verifiering av tjänst SoapUI kan användas för att generera anrop och mocktjänster (tjänster som svarar på anrop) genom att den aktuella tjänstens WSDL-fil pekas ut. I detta fall gäller detta alltså tjänsten GetAllTimeTypes. WSDL-filen för denna ligger under schemas/interactions/getalltimetypesinteraction och heter GetAllTimeTypesInteraction_1.0_rivtabp20.wsdl. Bilden nedan visar SSL-konfigureringen av SoapUI där konsumentens certifikat pekas ut (consumertest.ltdalarna.se.p12) och motsvarande inställningar för mocktjänsten. I detta exempel är dock SSL-konfigureringen för mocktjänsten deaktiverad och HTTP-protokollet används vid anropet från den regionala tjänsteplattformen till tjänsten. Se den regionala tjänsteplattformens inställningar i tjänstekatalogen i föregående kapitel ( Figur 30: Konfigurering av SoapUI:s SSL-parametrar Sid 52/57

53 Mocktjänstens svar (Response 1) består av ett genererat SOAP-meddelande. I detta exempel har svaret modifierat så att attributet <urnl:tiletypename> innehåller texten FUNGERADE!. Figur 31: Modifiering av mocktjänstens svar Sid 53/57

54 Anropet (Request 1) som ska skickas till den lokala nationella tjänsteplattformen har genererats av SoapUI men innan detta kan skickas måste adressen samt den logiska adressaten SE CH anges. Den logiska adressaten kan skrivas in direkt i meddelandet <add:to>se ch </add:to> alternativt låter vi verktyget göra detta i runtime. Bilden nedan visar SoapUI då denna funktion har nyttjats notera Enable/Disable WS-A addressing och HSAID i fältet To. Figur 32: Anropsadress samt logisk adressat (HSAID) i wsa:to -attributet Sid 54/57

55 Svaret på anropet redovisas nedan. Figur 33: Returnerat svar på anropet Sid 55/57