...
| 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 finns Java. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. | jAFlexibilitetFlexibilitet |
| K-6 | Virtualiseringsplattformen ska ha stöd för teknisk monitorering. 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 | 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 med automatiserade last- och robusthets-tester. 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-10 | All utveckling av VP ska baseras på portabla, komponentbaserade byggen enligt en väl beskriven produktstruktur. | Flexibilitet |
| K-11 | Virtualiseringar ska kunna skapas mha en enkel instruktion. Detta utifrån en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt och därefter kunna skapa paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen. |
...
| 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. |
| VP013 | Avsändaren saknar rättighet att lägga till headern x-rivta-original-serviceconsumer-hsaid. | |
| VP014 | Anropsförmedlingen för den logiska adressaten har givit upphov till rundgång mellan tjänsteplattformar. Rapportera felet till tjänsteplattformsförvaltningen. |
Förtydligande av specifika krav
...
Anrop mot VP sker via HTTPS. Detta protokoll är HTTP över SSL/TLS och stödjer klient autentisering autentisering av klienten med hjälp av klientens X509 certifikat. Detta kallas även för ”mutual authentication”, förklaras vilket 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.
...
Dvs, den regionala tjänsteplattform på producent-sidan kommer att agera på liknande sätt som den nationella tjänsteplattformen:
- Den skickar oxå också 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.
...
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 är 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.
...
- 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.
- NotNotera: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
x-vp-auth-cert"
- NotNotera: SKLTP's implementation av VP har standardiserat namnet på denna http-header till "
- Vidare måste oxå också 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 säkerställa 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.
...