...
| Krav Id | Beskrivning | Typ |
|---|---|---|
| K-1 | Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent ska maximalt tillföra 40 millisekunder i exekveringstid, i förhållande till ett anrop utan mellanhand. | Prestanda |
| K-2 | Virtualiseringsplattformen ska stödja gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer. | Skalbarhet |
| K-3 | All kommunikation ska säkras enligt RIV Tekniska Anvisningar Basic Profile 2.0 (https med ömsesidig autentisering). Detta innebär att båda parter skall presentera giltiga certifikat vid upprättandet av en säker förbindelse (sk SSL-handshake). | Säkerhet |
| K-4 | VP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler. | Utökningsbarhet |
| K-5 | VP ska kunna driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. | Flexibilitet |
| K-6 | Virtualiseringsplattformen ska ha stöd för teknisk monitorering av Mule ESB. Detta innebär också riktat stöd för monitorering av svarstider hos tjänsteproducenter och att VP loggar på loggformat lämpliga för övervakning av gängse övervakningsverktyg. | Monitorering |
| K-7 | Virtuella tjänster är tillståndslösa mellan anrop, vilket gör att s.k. fail-over inte behöver införas för att uppnå hög tillgänglighet. Hög tillgänglighet bedöms kunna uppnås genom klustring. | Tillgänglighet |
| K-8 | Virtualiseringsplattformen (VP) ska inte vara beroende av att Tjänstekatalogens (TAK) tjänster för att hämta behörighet och routing är tillgänglig online, vilket medför att VP ska kunna utföra sitt uppdrag även när TAK inte är tillgänglig. | Tillgänglighet |
| K-9 | VP ska levereras som öppen källkod under licensen LGPL. | Flexibilitet |
| K-10 | VP ska leverera en exempelapplikation som visar på ett komplett uppsatt end-to-end-exempel. Detta ger en startpunkt för de som vill testköra och praktiskt skapa sig en förståelse av VP. | Flexibilitet |
| K-11 | VP ska levereras med automatiserade last- och robusthetstester. Plattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig. | Prestanda |
| K-12 | All utveckling av VP ska baseras på portabla, komponentbaserade byggen enligt en välbeskriven produktstruktur. | Flexibilitet |
| K-13 | Virtualiseringsplattformen ska inte ha egna protokoll, utan använder samma protokoll som föreskrivs av vården för samverkan mellan tjänster. | Interoperabilitet |
| K-14 | Virtualiseringar ska kunna skapas mha 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. |
Funktionella krav
Detaljerade krav på funktionalitet i Virtualiseringsplattformen.
| Krav Id | Beskrivning | Typ | |
|---|---|---|---|
| FK-1 | Autentisering för HTTPS ska ske via mutual authentication i två led eller fler led för virtualiseringspattformen | Säkerhet | |
| FK-2 | Auktorisation för HTTPS ska ske via det HSA_id i anropande systems certifikats ett anropande system presenterar i certifikatets "subject" | Säkerhet | |
| FK-3 | Autentisering och Auktorisation för HTTP ska ske genom användning av information i HTTP-headersheader. Här krävs också extra verifiering av anslutande part, som gås igenom mer nedan. | Säkerhet | |
| FK-4 | Stödja VP ska stödja "RIV-TAs frivilliga anvisning angående http header för att ange ursprunglig avsändare". | ||
| AKFK-5 | Hantering VP ska hantera olika versioner av RIV-TA profilerFör version 1.0 av virtualiseringsplattformen levereras inte stöd för , dvs en ö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. | ||
| AKFK-76 | 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. | Felhantering | |
| FK-7 | Felsituationer som är förutsägbara baserade på | inkoncistensinkonsistens 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, se standardiserade felkoder nedan. | Felhantering |
| AKFK-68 | Felhantering Alla former av fel kan ska kunna spåras i efterhand då dessa loggas persistent. Loggnivån är även konfigurerbar ska vara 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 | Felhantering | |
| FK-9 | VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar samt till anropande system. | ||
| FK-510 | All intern kommunikation skall mellan SKLTP-komponenter ska gå via HTTP | ||
| FK-611 | Virtuella tjänster skall ska paketeras separat , samt och 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. Kunna driftsätta en ny virtuell tjänst så att den blir tillgänglig för tjänstekonsumenter mha enkla instruktioner. | ||
| Reset cache TAK | |||
| Reset cache HSA | mha enkla instruktioner. | ||
| FK-12 | VP ska under drift kunna hämta och uppdatera sin konfiguration från en Tjänstekatalog (TAK). Detta innebär att VP ska ha en cache med TAK konfiguration som uppdateras vid ett lyckat anrop. | ||
| FK-13 | VP ska under drift kunna hämta och uppdatera sin HSA konfiguration från en lokalt inläst HSA-fil. Detta innebär att VP ska ha en cache med HSA konfiguration som uppdateras vid ett lyckat anrop. |
Standardiserade felkoder
| Ankare | ||||
|---|---|---|---|---|
|
...
Förtydligande av specifika krav
FK-1, Autentisering via certifikat
Autentisering av en tjänstekonsument skall ske genom att säkerställa att certifikatet är utställt av en betrodd CA samt att identiteten för tjänstekonsumenten hämtas från certifikatets "subject" del och där närmare bestämt från fältet serialNumber som anger ett HSA-Id.
...
Detta innebär att en tjänsteproducent autentiserar anropande VP genom att lita på den CA som är utställare av VP's certifikat.
FK-2, Auktorisation av anropande system
Allt underlag för behörighetsbeslut finns lagrat i TAK. VP använder denna information för att auktorisera anropande tjänst mot den tjänst man vill nå. Anropande tjänsts identitet hämtas från det klient certifikat som används när man upprättar kommunikationen. I bilden nedan visas stegvis hur behörigheten kontrolleras vid ett anrop.
...
Här auktoriserar den nationella VP tjänstekonsumentens anrop till den regionala VP. Därefter auktoriserar den regionala VP anropet till tjänsteproducenten. Tjänsteproducenten auktoriserar inkommande anrop från den regionala VP t.e.x med ACL-funktionalitet.
FK-3 Intern HTTP kommunikation
Bakom en reverse proxy, på ett känt nätverk 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
FK-4, 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.
...
- Typiskt terminerar man inkommande https/ssl-anrop i lastbalanseraren eller reverse-proxy och måste därmed skicka in klient-certifikatet i en separat http-header så att VP kan extrahera HSA-ID't från det certifikatet.
- Not: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
x-vp-auth-cert"
- Not: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
- Vidare måste oxå lastbalanseraren/reverse-proxy skicka vidare ev http-headern för ursprunglig avsändare, ”
x-rivta-original-serviceconsumer-hsaid", om den är med i inkommande anrop.- För att VP skall kunna säkerställ att denna header kommer från en betrodd avsändare måste också lastbalanseraren/reverse-proxy skicka in ip-adressen för den som anropat lastbalanseraren/reverse-proxy i en separat http-header.
Intern kommunikation
Bakom en reverse proxy, på ett känt nätverk vill man minimera kommunikationsoverhead så mycket som möjligt. För att stödja detta kan SKLTP komponenter ansluta till VP genom att bifoga information om avsändare, logisk tillhörighet och ip-adress.
- x-vp-sender-id = http-header med avsändarens identitet, motsvarande det som står i certifikatet vid https/ssl-anrop
- x-vp-instance-id = http-header med Id som måste stämma överens med id på den VP som ansvarar för routing och behörighet inom en viss logisk gruppering av SKLTP komponenter
- ip-adress = avsändarens ip adress, för att säkerställa att endast betrodda ip-adresser används
K-3, Mutual Authentication med SSL
I en kommunikation måste båda parterna presentera giltiga certifikat. Se bild och text nedan för en förenklad förklaring.
...