...
Ö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].
de övergripande kraven samt ges en identitet för senare uppföljning i SAD:en.
| Krav Id | Beskrivning | Typ |
|---|---|---|
| AK-1 | Krav - Administration av systemförändringar ska vara minimal | |
| AK-2 | Krav - Anslutningspunkter | |
| AK-3 | Krav - Administration av organisationsförändringar ska vara minimal | |
| AK-4 | Krav – Meddelande format | |
| AK-5 | Krav - Hantering av RIV-TA profilerFö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. | |
| AK-6 | 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. | |
| AK-7 | ÖppenhetVP levereras som öppen källkod under licensen LGPL. | |
| AK-8 | Krav - felhantering Felmeddelande som orsakas i virtualiseringsplattformen ska rapporteras som SOAPFault till tjänstekonsumenten, samt loggas. ID i SOAPFault ska finnas i logfilen för korrelering. Felsituationer som är förutsägbara baserade på inkoncistens 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 som orsaken och vad som behöver göras. | |
| AK-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. | |
| AK-10 | 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 byggenT-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. |
...
| 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 |
Säkerhet
Säkerheten i VP 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.
...
Förtydligande av specifika krav
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.
Auktorisation av
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.
...