...
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 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-header. Här krävs också extra verifiering av anslutande part, som gås igenom mer nedan. | Säkerhet |
FK-4 | VP ska stödja "RIV-TAs frivilliga anvisning angående http header för att ange ursprunglig avsändare". | |
FK-5 | VP ska hantera olika versioner av RIV-TA profiler, dvs en översättning mellan olika RIVTA-versioner (transformering mellan olika kuverterings- och säkerhetsmodeller). | |
FK-6 | 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å inkonsistens 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 |
FK-8 | Alla former av fel ska kunna spåras i efterhand då dessa loggas persistent. Loggnivån ska vara konfigurerbar för att kunna spara extra mycket spårningsinformation. | Felhantering |
FK-9 | VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar samt till anropande system. | |
FK-10 | All intern kommunikation mellan SKLTP-komponenter ska gå via HTTP | |
FK-11 | Virtuella tjänster ska paketeras separat och därmed kunna driftsättas separat i VP 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. | |
FK-14 | VP ska per tjänst kunna konfigurera ett separat time-out värde. Är inget time-out värde angivet skall ett defaultvärde användas(konfigurerbart). | |
FK-15 | VP ska per tjänst kunna konfigurera om keep-alive skall användas i kommunikationen. | |
FK-16 | VP ska stödja "RIV-TAs frivilliga anvisning angående status för anrop till aggregerande tjänster". |
Standardiserade felkoder
Ankare | ||||
---|---|---|---|---|
|
...