Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

Krav IdBeskrivningTyp
FK-1Autentisering för HTTPS ska ske via mutual authentication i två led eller fler led för virtualiseringspattformenSäkerhet
FK-2Auktorisation för HTTPS ska ske via det HSA_id ett anropande system presenterar i certifikatets "subject"Säkerhet
FK-3Autentisering 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-4VP 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-7Felsituationer 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-9VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar samt till anropande system. 
FK-10All 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-13VP 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-14VP 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-15VP ska per tjänst kunna konfigurera om keep-alive skall användas i kommunikationen. 
FK-16VP ska stödja "RIV-TAs frivilliga anvisning angående status för anrop till aggregerande tjänster". 

Standardiserade felkoder
Ankare
VP-felkoder
VP-felkoder

...