SOSI-GW. Tilbudsbeskrivelse

SOSI-GW Tilbudsbeskrivelse Region Syddanmark Trifork A/S Margrethepladsen 3 DK-8000 Århus C Denmark Phone: +45 8732 8787 Fax: +45 8732 8788 www.trifork.com

Indhold 1. Overordnet om SOSI GW...3 1.1. Arkitektur og designvalg...4 1.2. Yderligere muligheder i SOSI GW...5 1.3. I relation til Det Fælles Medicingrundlag...6 1.4. Sikkerhedsovervejelser...8 2. Løsningsbeskrivelse...11 2.1. Arkitektur for SOSI GW...11 2.2. Webservice API...17 2.3. HTTP API...21 2.4. Audit Logning...22 2.5. Licenser...23 2.6. Svartider...24 2.7. Nødvendig hardware...24 2.8. Dokumentation...26 3. Test...28 4. Hovedtidsplan...30 4.1. Risikoelementer...30 5. Kravmatrix...32 Side 2 af 38

1. Overordnet om SOSI GW Formålet med SOSI GW er at flytte ansvaret for signering af SOSI id kort fra de enkelte klienter til en central service. Denne service kan modtage requests og automatisk vedhæfte et signeret id kort inden requests sendes videre til de endelige endpoints, og dermed behøver de enkelte klienter ikke at bekymre sig om at implementere SOSI id kort selv. I mange tilfælde er der krav om at køre på sikkerhedsniveau 4, som defineret i Den Gode WebService (DGWS), hvilket betyder at den enkelte bruger selv skal have underskrevet id kortet med den personlige digitale signatur. Dette ændres ikke af SOSI GW, da der stadig er behov for, at brugeren selv signerer id kortet. Måden det foregår på er, at SOSI GW holder selve id kortet men får en underskrift fra brugeren. Underskriften kan enten komme via en klient, fx implementeret i Java, eller via en browserapplet, der kan signere kortet via en normal browser. Anvendes browser metoden, behøver de enkelte klienter heller ikke at kende til brugerens certifikater eller signeringen af id kort, og skal i stedet kun bekymre sig om at håndtere requests på den rette måde. Når et id kort først er signeret, gemmes det i SOSI GW indtil det udløber. Det resulterer i noget, der ligner Single Signon, da brugeren kun en enkelt gang bliver bedt om at signere id kortet. Det har været et designmål for løsningsforslaget, at SOSI GW skal være let og billig at skalere, og at konfigurationen af de enkelte servere skal være så enkel som muligt. Derudover skal den naturligvis understøtte de krav der er i forhold til at håndtere id kort, samt sikre at adgangen til SOSI GW er kontrolleret og begrænset på den bedst mulige måde. Side 3 af 38

Der har i designet af løsningen været fokus på ikke at have noget single point of failure. Det betyder, at alle servere i systemet skal kunne tages ned uden at det påvirker resten af komponenterne, og dermed er grundlaget for en skalerbar løsning lagt. Der er i løsningen også lagt vægt på, at den skal kunne fungere i alt fra de simpleste konfigurationer til de største. Det vil sige, at det er muligt at køre SOSI GW på en enkelt maskine, der har sin egen database, og derefter tilføje flere maskiner til systemet, og disse vil automatisk blive en del af den samlede SOSI GW. Denne tilgang er valgt fremfor en løsning baseret på fx clustering af databaser og J2EE containere, da den er simplere og billigere at installere og vedligeholde, og når løsningen fra starten er designet til at køre i et distribueret miljø, er nedbrud ikke en kritisk hændelse, under forudsætning af at der kører flere maskiner i clusteret. Når der i det følgende skrives SOSI GW menes der det samlede system, uanset hvor mange maskiner det måtte bestå af. Designet betyder også, at SOSI GW understøtter både det scenarie hvor en gateway installeres decentralt til at betjene et enkelt system, og det hvor en gateway installeres mere centralt til at betjene en lang række systemer. Det er altså muligt at foretage en afvejelse af, om administrationen af SOSI GW skal ligge tæt på brugerne af systemet eller mere centralt. 1.1. Arkitektur og designvalg Løsningen implementeres i Java 5, og vil være baseret på et almindeligt Servlet 2.4 api. Det betyder, at en J2EE kompatibel server ikke er nødvendig, men løsningen vil naturligvis være Side 4 af 38

fuldt kompatibel med J2EE 1.4, dog under forudsætning af, at serveren afvikles under Java 5 [Krav 23]. De enkelte servere vil have brug for en lokal database, og til dette formål anbefales PostgreSQL, der er en open source database server, der leverer meget høj performance og sikkerhed mens den på den anden side er let at installere og vedligeholde. Der er dog ikke krav om typen af SQL server, og dermed kan løsningen benyttes på en vilkårlig SQL server. Alle servere har samme status, og der er ingen central koordination. Det betyder at serverne indbyrdes udveksler informationer om id kort og konfiguration, og dermed er ingen af serverne essentielle for at SOSI GW kører [Krav 24]. Servicelaget til SOSI GW, som implementerer funktionalitet til eksplicit at forespørge og oprette id kort, implementeres i Apache Axis2. Dette er en af de mest populære webservicestakke, og erfaringen har vist at den er meget pålidelig. Axis2 er en stor opgradering fra Axis1, og indeholder mange nye muligheder og performanceforbedringer. Ved proxy requests, altså de requests, der skal hæftes id kort på og sendes videre, streames data direkte fra klienten gennem SOSI GW til det endelige endpoint. Dette medfører, at selvom der sendes meget store filer, vil SOSI GW ikke blive belastet ved at skulle hente hele filen ind i hukommelsen på én gang, lige som XML parsing af hele dokumentet kan undgås. Det administrative interface implementeres som en webgrænseflade i GWT 1.4 (Google Web Toolkit). GWT er beregnet til at lave Ajax baserede webgrænseflader, som programmeres direkte i Java og derefter oversættes til Javascript. Det gør det meget let at lave især administrative grænseflader, der har hurtigt feedback og generelt opfører sig som normale desktopapplikationer. 1.2. Yderligere muligheder i SOSI GW Det primære fokus med SOSI GW er at gøre det lettere at implementere klienter, da de ikke behøver at bekymre sig om certifikater og signering. Der er dog andre anvendelsesmuligheder, som kunne være interessante at overveje: SOSI GW som performanceovervågning. Når alle requests til endpoints går gennem gatewayen, er det en oplagt mulighed at der laves tidsmålinger på, hvor længe requests tager at lave. Især tiden fra et request sendes til et endpoint til det kommer tilbage igen kan være interessant for at få et samlet overblik over, hvor langsomme eller hurtige andre services er. SOSI GW som policy enforcement. Hvis der i den lokale organisation er opstillet regler for, hvem der må kalde hvilke services, ville SOSI GW kunne checke disse regler inden requests sendes videre og sørge for, at reglerne overholdes. Side 5 af 38

SOSI GW som content router. Lige som klienter gerne vil undgå at håndtere certifikater og signering, kunne de undgå at skulle finde frem til det endelige endpoint. Gatewayen kunne i stedet stå for at kommunikere med fx en UDDI server, som bestemmer hvor de enkelte endpoints befinder sig. I så fald skulle klienterne blot sende beskeder til SOSI GW med en beskrivelse af den ønskede service, og gatewayen ville så selv finde frem til det korrekte endpoint. 1.3. I relation til Det Fælles Medicingrundlag I forbindelse med Det fælles medicingrundlag vil SOSI GW spille en vigtig rolle. En SOSI gateway kan være med til at fremskynde og øge anvendelsen af Det fælles medicingrundlag, og mindske omkostningerne herved. EPJ-system SEAL EPJ-system Lægepraksissystem SOSIgateway Medicinprofilen Det fælles medicingrundlag SEAL PEM, Receptserver Lægepraksissystem SEAL 1.3.1. Det fælles medicingrundlag Det fælles medicingrundlag er en kommende udvidelse af Medicinprofilen, som kommer til at håndtere samtlige ordinationer fra praksislæger, speciallæger, de fleste ordinationer ved ambulant behandling, og desuden de ordinationer ved indlæggelse på sygehus, som er relevante ved og efter patientens Side 6 af 38

udskrivning. Det fælles medicingrundlag er datamæssigt tæt integreret til Medicinprofilens øvrige delsystemer. I Det fælles medicingrundlag udstilles der en række web services på sundhedsdatanettet, som blandt andet gør det muligt for aktørerne at oprette, læse og ændre ordinationer på en patients medicinkort, desuden at sende recepter til apoteket (via receptserveren) til udlevering, eller notere hvilke effektueringer som lægen selv har foretaget. Fælles for alle disse handlinger er at der udveksles personfølsomme data, og det er derfor et krav at der anvendes medarbejdercertifikater (OCES) til unik identificering af brugeren. I Det fælles medicingrundlag benyttes Den gode web service og SOSI biblioteket. 1.3.2. EPJ og lægepraksissystemer I den anden ende af systemlandskabet findes en række forskellige EPJ og lægepraksissystemer. Disse er de primære brugersystemer på Det fælles medicingrundlags web services. EPJ og lægepraksissystemer er karakteriseret ved at være forskellige systemer, udviklet af forskellige ITleverandører i forskellige teknologier og generationer. Samtidigt er der en stor variation i kompleksitet. På grund af dette brede udvalg af systemer, og idet de tidligere amter er samlet i fem regioner, er det en stor udfordring at implementere Den gode web service i samtlige EPJ og lægepraksissystemer. Der er udviklet et sæt komponenter til Java og.net (hhv. SEAL Java og SEAL.NET), som til dels kan gøre opgaven simplere, såfremt et af disse sprog anvendes. SEAL komponenterne skal dog integreres i applikationen, og det er derfor mest oplagt at anvende disse i regioner hvor der kun findes et enkelt EPJ system, eller hos lægepraksissystemleverandører der alene er ansvarlige for deres ene system. 1.3.3. SOSI GW Formålet med en SOSI GW er at opnå den krævede unikke identificering af brugeren, uden at skulle foretage ændringer i en lang række systemer. SOSI GW vil specielt i regioner hvor der findes en række forskellige EPJ systemer, der alle skal anvende Det fælles medicinkorts web services. Desuden vil SOSI GW også være relevant at anvende ved EPJ og lægepraksissystemer der er udviklet i en teknologi hvor SEAL komponenterne ikke kan Side 7 af 38

anvendes, eller ved systemer hvor man ikke er interesseret i at ændre i den eksisterende implementation. 1.3.4. Triforks rolle I udviklingen af specifikationerne til Det fælles medicingrundlag har Trifork spillet en vigtig rolle og bidraget med nøglepersoner i processen. Desuden har Trifork afgivet bud på opgaven med udvikling af Det fælles medicingrundlag. Uanset Lægemiddelstyrelsens valg af leverandør forventes det at Trifork vil være involveret i processen, enten som leverandør eller alternativt med en rådgivende rolle i processen, en rolle som Trifork også har haft tidligere i forløbet. 1.4. Sikkerhedsovervejelser SOSI GW er beregnet til at berige webservice requests med ekstra sikkerhedsinformation, der entydigt identificerer en konkret bruger. Da denne berigelse sker delvist automatisk, er det vigtigt at selve SOSI GW er beskyttet på en passende måde, så misbrug ikke finder sted. I det følgende er en klient defineret som det program, der kommunikerer med SOSI GW. Konkret kan det enten være en server eller en tyk klient. Da der ikke er nogen sikkerhedskontekst etableret mellem klienterne og SOSI GW, forudsætter et højt sikkerhedsniveau at der er fuld tillid mellem klienterne og SOSI GW. Det betyder, at systemet ikke tager højde for tilfælde hvor en klient sender ugyldig information som fx et forkert bruger id. Adgangen til SOSI GW begrænses via IP filtre og shared secret pr. klient [Krav 1]. Det betyder at hver klient skal konfigureres med en nøgle, som er genereret af serveren, og som skal medsendes i alle requests. Denne løsning er valgt fremfor normale X509 certifikater, da den er simplere at implementere og bidrager med den samme sikkerhed. Kravspecifikationen nævner Single Signon (SSO) som et af argumenterne for at implementere SOSI GW. SSO opstår her ved at bruger id altid sendes med i requests mod SOSI GW, og hvis der allerede eksisterer et gyldigt id kort, så anvendes det uden at brugeren spørges om signering igen. Dette fungerer kun fordi bruger id anvendes som sessions nøgle, og dette id er kendt på tværs af applikationer. Brugen af bruger id som nøgle har den ulempe at det ikke er hemmeligt, og hvis der skulle opstå den situation at der kommer uautoriseret adgang til netværket, er det simpelt at indsætte et andet bruger id i requests. Et alternativ til dette, men som ødelægger SSO, ville være at lade kald, der opretter id kort, returnere et tilfældigt sessions id for den forespurgte bruger, og så bruge dette id som sessions nøgle i stedet. Endelig ville en mulighed være at koble løsningen op på et eksisterende SSO system i organisationen. Side 8 af 38

Dette kræver dog, at SSO systemet understøtter SSO på webservices også, hvilket kun understøttes af enkelte systemer. I forhold til datatransport mellem klienter og SOSI GW er spørgsmålet om der skal anvendes kryptering eller ej, enten i form af WS Security eller SSL. Brug af WS Security vil ikke øge sikkerheden i forhold til SSL, da der er tale om point to point kommunikation, og der er ikke behov for uafviselighed. Under forudsætning af at netværket er sikkert, vil SSL heller ikke være nødvendigt. I de normale webservice kald transporteres der ikke noget hemmeligt det vil kun være i det tilfælde, at der anvendes unikt session id og krypteringen bidrager derfor ikke med noget. Et sted giver det dog mening at køre SSL, nemlig i forbindelse med browserbaseret signering. Her er der en risiko for, at browseren står på et usikkert net, og det er derfor relevant at beskytte kommunikationen mellem browseren og SOSI GW. Sikkerheden mellem SOSI GW og de enkelte endpoints beror på transportsikkerhed. Det forudsættes altså at forbindelserne ikke kan aflyttes. Der kan benyttes SSL til kommunikationen, men indførelsen af SOSI GW gør at brugen af klientcertifikater mellem serviceaftager og udbyder ikke længere er muligt, da der ikke længere er direkte kontakt mellem aftageren og udbyderen. Skal SOSI GW understøtte at services kræver klientcertifikater, kræver det en udvidelse af SOSI GW, så der pr. endpoint kan konfigureres et klientcertifikat. Vi antager dog at kommunikationen med serviceudbydere sker over Sundhedsdatanettet, og dermed er bekyttet tilstrækkeligt. En del af den endelige leverance er en sikkerhedsvejledning [Krav 31], som vil beskrive kravene til netværkssikkerhed. Dette dokument vil indeholde en række forskellige scenarier samt en beskrivelse af sikkerhedsaspekterne ved hvert scenarie. Et af disse scenarier er skitseret nedenfor. Side 9 af 38

I dette tilfælde er der tre forskellige netværk involveret: Det lokale netværk, hvor brugernes arbejdsstationer er placeret, et netværk hvor de lokale servere er placeret, og endelig Sundhedsdatanettet hvor de enkelte endpoints er placeret. Hvert netværk har forskellige sikkerhedskrav og niveauer, og sikkerhedsvejledningen vil bl.a. beskrive, hvad disse krav indebærer. Side 10 af 38

2. Løsningsbeskrivelse I de følgende afsnit beskrives den løsning, som Trifork foreslår. Løsningen er baseret på de principper, der er nævnt i indledningen og opfylder de tekniske krav fra kravspecifikationen. 2.1. Arkitektur for SOSI GW Den grundlæggende arkitektur er baseret på et cluster af servlet containere. Der er tale om en symmetrisk løsning, hvor alle servere i clusteret er identiske i opsætning og konfiguration. Clustering funktionaliteten opnås på applikationsniveau, der er derfor ikke krav om clustering support i den benyttede servlet container. Den nedre grænse for cluster størrelse vil være en enkelt server, den øvre grænse i princippet ubegrænset. Der understøttes rullende opdatering, load balancering og fail over ved en clusterstørrelse på 2 eller flere [Krav 24, Krav 29]. Hver server vil være bestykket med en servlet container (fx Tomcat) og en lokal PostgreSQL DBMS. Til opsamling og søgning på audit logs opstilles en log merger server, som ligeledes er bestykket med en lokal PostgreSQL DBMS. Figuren nedenfor skitserer SOSI GW løsningen bestående af et antal gateway servere (sosi gw1,.., sosigw3) og en central database til opsamling og fletning af audit logs (log merger). Side 11 af 38

DNS Round Robin el. HTTP load balancer DNS Round Robin el. HTTP load balancer sosi-gw1 sosi-gw1 DB sosi-gw2 sosi-gw2 DB sosi-gw3 sosi-gw3 DB JGroups kanal JGroups kanal konf konf log-merger log-merger DB Id-kort Id-kort 2.1.1. 2.1.2. Tilstandsdeling imellem clustermedlemmer De servere, der indgår i et cluster kommunikerer indbyrdes via et distribueret, delt hukommelseområde, realiseret som en JGroups kanal. JGroups er et open source produkt, der tilbyder pålidelig multicast kommunikation, som afhængig af sin konfiguration kan benytte både IP multicast og TPC/IP som transportmekanisme. Herigennem overføres løbende opdateringer i form af id kort oprettelse, opdatering og nedlæggelse. Udover id kort, bruges JGroups kanalen også til at synkronisere konfigurationsændringer, der er foretaget igennem administrationskonsollen. JGroups kanalen benyttes endvidere som discovery mekanisme, dvs. som måden hvorpå clustermedlemmer fastlægger hvilke øvrige medlemmer clusteret indeholder på et givet tidspunkt. Det betyder, at der ikke vil være behov for nogen manuel konfiguration i forbindelse med at en server tilføjes eller fjernes. Side 12 af 38

2.1.3. Intern arkitektur Administrationsinterface GWT Browser baseret underskrift Webservices Axis2 SOSI-GW kerne SOSI Seal Servlet 2.4 container Versionet fælles tilstand Konfiguration Logning JGroups Figuren ovenfor viser den interne arkitektur i SOSI GW. Løsningen består af en kerne, der anvender SOSI Seal [Krav 19] til at håndtere id kort. Id kort distribueres over en fælles cache, der som udgangspunkt drives af JGroups. Konfiguration og logning gemmes i en lokal JDBC database. Ovenpå kernen ligger tre snitflader, nemlig webservices, http til browserbaseret signering samt GWT til administration. JDBC 2.1.4. Versionsstyring af delt data Som led i understøttelsen af rullende opgraderinger, påhæftes alle delte data typer et versionsnummer. Software opgraderinger, der involverer modifikationer af de delte datatype, må understøtte både det nye og det gamle format, og fortsætte med at udgive data i det forrige format indtil det detekteres, at der ikke længere er cluster medlemmer, der kræver dette. [Krav 24, Krav 29] Der understøttes kun det aktuelle og det forrige format, ved en forskel på mere end et versionsnummer af beskedsformatet, kan der ikke kommunikeres. Ved opstart checker servere om beskeder afsendt af andre servere er i et af de to understøttede formater, og afbryder ellers opstarten. Side 13 af 38

2.1.5. Konfiguration Den statiske, filbaserede konfiguration af SOSI GW applikationen holdes på et minimum for at undgå omstændig kopiering af konfiguration, og for lettere at kunne honorere kravet om rullende opdateringer mm. Formodentlig vil behovet for statisk konfiguration kunne dækkes af en id for den benyttede JGroups kanal samt diverse JGroups netværks parametre samt JDBC parametre til at tilgå hhv. den lokale og den fælles log database. Al anden konfiguration lægges i den lokale database på de enkelte servere og udveksles via JGroups kanalen. Konfigurationen persisteres i den lokale database på alle servere i SOSI GW clusteret. Konfigurationsdata gemmes altid som et komplet hele, der er forsynet med et tidsstempel, der identificerer og sammenbinder sammenhørende konfigurationsdata. Det er ikke påtænkt, at administrationskonsollen skal betjene mere end én samtidig bruger, men der laves ikke nogen explicit sikring af, at dette overholdes. Derimod håndteres evt. konflikter ved at lade den yngste konfiguration vinde. En vilkårlig server i clusteret kan servicere administrationskonsollen. Når administratoren markerer at konfigurationsændringer skal gemmes, distribueres de nye konfigurationsdata på JGroups kanalen, og alle servere persisterer konfigurationen i den lokale database. Når en server startes, sammenlignes tidsstemplet på de persisterede konfigurationsdata med den version, der kan aflæses via JGroups, og den nyeste af de to benyttes. En konsekvens af den anvendte strategi vil være, at det vil være ukompliceret at pakke løsningen som fx et VMware image, hvilket vil lette opsætningen af yderligere SOSI GW servere. Administrationskonsol Administration af et SOSI GW cluster foretages via en webbaseret administrationskonsol. Grænsefladen er baseret på GWT (Google Web Toolkit), af hensyn til brugeroplevelsen. Administrationskonsollen vil indeholde flg. funktioner: Bootstrap mode, hvor gateway funktionalitet er slået fra, men hvor adgangsbegrænsning er baseret på filbaseret brugernavn/password. Dette mode benyttes kun under installationsprocessen. Opsætning og visning af white lists, hvor tilladte klienter sættes op og identificeres. Opsætning og visning af service positivliste, hvor services som må kaldes på vegne af klienter sættes op og identificeres. Id kort revokering, hvilket giver mulighed for at fremsøge et id kort på baggrund af et bruger id, Side 14 af 38

og efterfølgende revokere dette, dvs. fjerne id kortet fra den delte cache. Søgning i audit logs. Administrationskonsollen giver mulighed for at foretage simple søgninger i auditloggen, fx baseret på bruger id og/eller tidsrum. Oversigt over hvilke servere, der pt. er til stede i clusteret. Styre adgang til interfacet selv. Dette sker ved at give brugere adgang på baggrund af certifikater. Konfiguration af timeoutværdier Visning af den statiske konfiguration (JDBC, JGroups) [Krav 14, Krav 15, Krav 16] Alle funktionerne i webinterfacet kan udføres uden genstart eller nedlukning af systemet, og når ændringerne er gemt slår de automatisk igennem på hele clusteret [Krav 14]. Adgangen til administrationsinterfacet er begrænset, så kun tilladte brugere får adgang. Adgang sker via certifikatlogin, som også baseres på en OpenCert applet. Via administrationsinterfacet er det muligt at konfigurere hvilke personer, identificeret ved PID/RID, der har adgang til at benytte interfacet [Krav 17]. 2.1.6. Logning Audit logning foretages lokalt på de enkelte servere i clusteret. Persistering af log elementer foretages i en asynkron afkoblingstråd, således at gateway funktionaliteten kan afvikles optimalt. Audit logs persisteres lokalt i de decentrale databaser, der er installeret på alle SOSI GW servere [Krav 22]. Med et konfigurerbart interval sender hver enkelt server opsamlede logs til den centrale log merger database server. Dette foregår via jdbc adgang til log mergerens database. Når data er committet på logmerger databasen, slettes disse lokalt. Dette betyder, at selvom log mergeren ikke er dupleret, mistes der ikke auditlogs hvis log mergeren er ude af drift. I det øjeblik log mergeren er reetableret, vil akkumulerede auditlogs automatisk blive overført. De data som er overført til log mergeren bør sikres med passende disk spejlings og backup strategier. Søgning i auditlogs foregår på log mergerens database via administrationskonsollen eller som alternativ via et generisk SQL værktøj (PgAdmin, DbVisualizer el. lign.) direkte på databasen. I en minimal ikke redundant konfiguration kan log merger og SOSI GW server køre på den samme host, (evt. under samme DBMS). Side 15 af 38

Brugen af en central log mens der logges direkte til lokale logs gør, at den centrale log kan undværes i kortere eller længere perioder. Dermed er der ikke nogen faste afhængigheder mellem serverne, og SOSI GW går ikke ned hvis den centrale log forsvinder. Konsekvensen er, at den centrale log ikke viser realtidsoplysninger, da der kan gå et stykke tid fra en hændelse sker til den optræder i den centrale log. Det betyder også, at skulle en af serverne stoppe helt med at fungere, så kan logbeskeder gå tabt. Det anbefales dog, at der også på de enkelte servere køres med spejlede diske, og derfor skal det gå meget galt før noget går helt tabt. Ud over den beskrevne logning, som fungerer som audit logning, vil der også internt blive foretaget logning via log4j. Denne logning sker kun lokalt på de enkelte maskiner, og er beregnet til at overvåge og debugge systemet. 2.1.7. Revokationskontrol Der foretages revokationskontrol af brugercertifikater når id kort signeres. Herefter sker der løbende kontrol af de cachede id kort. Revokationslisten caches i konfigurerbare tidsrum, ligesom intervallet mellem den løbende kontrol kan konfigureres [Krav 21]. 2.1.8. Samtidighed Metoderne til at oprette, signere og fjerne id kort implementerer ikke nogen form for låsning, da det vil være uhensigtsmæssigt dyrt at implementere. Det betyder, at hvis to klienter på samme tid bestiller et nyt id kort for den samme bruger, så vil kun en af dem kunne signere det endelige id kort, nemlig den klient, der bestilte sidst. Det antages at der ikke foretages samtidige kald fra den samme bruger, og at problemet derfor ikke er relevant. 2.1.9. Load balancing For at distribuere load til de servere, der indgår i et SOSI GW cluster, er der behov for at opsætte en loadbalancing mekanisme. Dette er ikke en del af leverancen, men det kunne fx bestå i en DNS roundrobin løsning, en tcp load balancer (fx Linux Virtual Server) eller en http load balancer. Der er ikke behov for understøttelse af session affinity eller lign., da alle servere har adgang til alle cachede id kort via den delte JGroups kanal [Krav 24]. Der vil være behov for at enten den anvendte load balancer eller (i tilfældet DNS round robin) Side 16 af 38

klienterne forsøger igen i tilfælde af at en server ikke kan nås. I tilfælde, hvor det ønskes at kommunikation imellem klient og SOSI GW foregår over ssl (fx den genererede URL til signeringsapplet), skal der enten opsættes en SSL terminering foran SOSI GW serverne eller også skal det være muligt for de individuelle SOSI GW servere at kunne uddele en URL, der rammer en specifik server. 2.1.10. Afvikling på en enkelt maskine Det er muligt at afvikle SOSI GW på en enkelt maskine uændret, da systemet selv vil detektere at der kun er et medlem af clusteret. Det vil også være muligt at fravælge JGroups funktionaliteten via den statiske konfiguration, da det i dette tilfælde vil påføre et unødvendigt (om end minimalt) overhead. Det vil fortsat være muligt at køre log mergerens database på samme eller en anden maskine. 2.2. Webservice API SOSI GW's primære funktionalitet stilles til rådighed gennem Webservices. Funktionaliteten er delt op i to dele: Services til at håndtere id kort (oprette, signere og nedlægge) og en proxy service. Proxy servicen er et generisk endpoint, der står for at videresende requests fra en klient til et andet endpoint mens der også tilføjes et signeret id kort. Når proxy servicen anvendes, foretages der ikke nogen validering af SOAP body, og ligeledes checkes headeren kun for felter, der er nødvendige for at SOSI GW kan fungere [Krav 3]. Alle services bygger på den allerede definerede form for id kort fra DGWS, hvilket betyder, at data sendes som SAML assertions. Ved samtlige kald til SOSI GW, checkes det om kalderen, identificeret ved en ip adresse og en shared secret, har adgang til at benytte SOSI GW. Der benyttes altså kun standarder, der allerede er i anvendelse (WS Addressing, SAML m.v.) [Krav 20]. 2.2.1. Oversigt over metoder tilgængelige som webservices. proxy requestidcarddigestforsigning signidcard getvalididcard Side 17 af 38

logout 2.2.2. Proxy service Proxy tager et generisk SOAP request og tilføjer ID kort til headerne. For at gøre dette, skal klienten medsende sessions identifikation i form af et bruger id. Bruger id'et transporteres i en SAML assertion i stil med DGWS' id kort, hvor det eneste benyttede felt er <NameID>. Når requestet er modtaget, og brugerens id kort er vedhæftet, sendes requestet direkte videre til det endelige endpoint. Krav 2 specificerer, at SOSI GW skal understøtte opgradering af niveau 1 til 4. Niveau 1 er defineret i DGWS, og betyder at der kommer et usigneret id kort med brugernavn. Til requests hvor der allerede eksisterer et signeret id kort, ignoreres alt andet indhold end <NameID> feltet, og kortet erstattes med det, der opbevares af serveren. I de tilfælde, hvor der ikke eksisterer et kort i forvejen fejler operationen [Krav 2]. Servicen tager ikke argumenter direkte, da SOAP body indeholder det, der skal sendes videre til den endelige aftager. Til gengæld kræves det, at requests er udstyret med en header, der indeholder følgende: Unikt bruger id i form af en SAML assertion med <saml:nameid> WS Addressing headers i henhold til http://www.w3.org/submission/ws addressing/ Et optionelt id kort. Dette fjernes inden dispatch og erstattes evt. af det cachede kort. Returværdier: 200 (OK) på HTTP niveau, og som indhold det uændrede svar fra den ønskede service. 500 (Error ) på HTTP niveau, hvilket kan skyldes: Den ønskede service returnerede denne fejl. Den ønskede service er ikke konfigureret på listen over kendte endpoints. Manglende eller ugyldige argumenter i SOAP headerne, f.eks. manglende WS addressing. Der findes ikke et gyldigt signeret Id kort i SOSI GW. I fejltilfældene sendes en beskrivelse af fejlen i <fault> elementet, dels som kodede værdier, og dels Side 18 af 38

som læselig tekst i henhold til DGWS. Hvordan NameID tilføjes til SOAP beskeden er op til klienten selv, men det vil formentligt være smartest at skubbe ansvaret for det ned i den webservice stak, der anvendes. Det vil kunne holde selve klient api'et fri for at skulle håndtere SOAP headers, og i stedet lade stakken håndtere det internt. Det samme vil gøre sig gældende i forhold til WS Addressing headers. Disse er ikke en del af standardprofilerne, og skal ligeledes tilføjes eksplicit. WS Addressing er nødvendigt for at identificere det endelige endpoint for den forespurgte service. Nogle services understøtter dog ikke WS Addressing endnu, og da nogle webservice stakke sætter mustunderstand= 1 på WS Addressing headers, vil disse kald umiddelbart fejle når de når til endpointet. Derfor understøtter SOSI GW en filtreringsmekanisme, så WS Addressing headers automatisk kan fjernes inden et request sendes videre. Hvorvidt headers skal fjernes konfigureres pr. endpoint. WS Addressing understøttes i øvrigt kun til at finde endpoint det forudsættes at svaret sendes tilbage på samme kanal som requestet kom. SOSI GW understøtter derfor ikke at der svares på en ny service, som klienten selv udstiller. Endelig understøtter SOSI GW heller ikke, at svar kommer tilbage fra endpoint på andre kanaler [Krav 4, Krav 5]. 2.2.3. Håndtering af implicit Id kort oprettelse Hvis der er et tilstrækkeligt udfyldt id kort i requestet, mens der ikke findes et signeret id kort i SOSI GW, bliver der oprettet et nyt usigneret id kort. Fra det fremsendte id kort benyttes data fra afsnittene Obligatoriske system og organisationsoplysninger og Eventuelle brugeroplysninger, jævnfør Den Gode Webservice. Digest af id kortet samt signing url sendes retur til klienten i en ny SOAP header. Det er op til klienten at inspicere fejlbeskeder og headers for at afgøre om den skal præsentere brugeren for en signeringsdialog, enten indbygget i klienten, eller gennem start af en browser mod den returnerede url [Krav 2a]. Det skal bemærkes, at denne implicitte oprettelse af id kort har den konsekvens, at den etablerede kontrakt mellem klienten og den oprindelige serviceudbyder bliver brudt, da der pludselig kan opstå tilfælde, som ikke var planlagt oprindeligt. Konkret betyder det, at en klient genereret ud fra en WSDLfil ikke vil være forberedt på alle fejlmulighederne, og at de nye situationer derfor bliver svære at håndtere. Iflg. DGWS er de eneste tilladte returkoder fra en service 200 (OK) eller 500 (fejl). I det aktuelle tilfælde med implicit login, skal der hæftes noget mere på svarene for at skelne mellem en normal Side 19 af 38

servicefejl og det tilfælde, hvor det ikke er muligt at kalde servicen pga. manglende id kort. Især ved autogenererede klientstubbe bliver det problematisk, da de genererede klasser ikke er beregnet på at håndtere disse tilfælde. Endelig har implicit oprettelse den svaghed, at hvis der ikke er oprettet et id kort inden et request, så skal det fulde request alligevel sendes til SOSI GW, som straks derefter vil afvise det. Især ved store requests, fx hvis der sendes billeder, vil dette være et stort spild. Da håndteringen af implicitte oprettelser er komplicerede at håndtere på klientsiden, anbefales det, at der også udvikles nøjagtige vejledninger i, hvordan klienterne implementeres korrekt i forskellige frameworks. Dette tilbud indeholder kun dokumentation af selve SOSI GW og de tilhørende interfaces praktikker for, hvordan svar håndteres overlades til klienterne. 2.2.4. requestidcarddigestforsigning Denne benyttes til eksplicit oprettelse af et Id kort, klar til signering. Servicen kaldes af en klient for at etablere en session for en bruger, så der kan sendes signerede requests til andre services. Servicen kræver et partielt id kort, som SOSI GW skal opbevare i signeret tilstand. I SOAP body sendes derfor en SAML assertion med samme indhold som for implicit oprettelse. Servicen returnerer den digest værdi som klienten skal signere sammen med en URL, der kan anvendes af en browser. Der skelnes ikke mellem URL requests og WS requests [Krav 6, Krav 9]. Usignerede id kort fjernes automatisk fra serverne hvis der ikke er modtaget en signeret digest inden et vist interval. Dette interval er konfigurerbart. 2.2.5. signidcard Denne metoder benyttes til at tilføje et signeret digest til det cachede id kort i SOSI GW. Argumenter til dette kald er NameID, SignatureValue og brugerens offentlige nøgle. SOSI GW lader herefter STS'en signere id kortet, checker at signaturen er gyldig, og gemmer det i sin cache [Krav 7, Krav 8]. 2.2.6. getvalididcard Denne metode henter id kortet for en specifik bruger. Argumentet er NameID for brugeren, og returværdien er brugerens id kort eller en fault. Metoden er et supplement til de metoder, der er angivet i kravspecifikationen, men er nødvendig for at håndtere to tilfælde pænt: Side 20 af 38

Når et id kort er ved at blive signeret af en bruger gennem browser baseret signering, er der ikke noget feedback der fortæller klienten hvornår brugeren er færdig med signeringen. Klienten har derfor to muligheder: Poll serveren periodisk via denne metode eller lad brugeren manuelt indikere når processen er færdig. Metoden erstatter [Krav 10a], som havde samme effekt, bare med et blokerende kald til serveren. Det blokerende kald har den ulempe, at det optager serverressourcer i længere tid, og kan derfor være en hindring for høj skalabilitet. Til gengæld bliver en del af ansvaret flyttet til klienten, der aktivt skal checke for id kort, men dette er vurderet som den bedre løsning. Det andet tilfælde er det, hvor en webservice kræver et andet timeout niveau (i DGWS termer). Nogle services kræver fx, at id kort er underskrevet for hvert request, og denne situation skal håndteres i klienten. Klienten er derfor nødt til at kunne se, om id kortet er for gammelt til at kunne bruges, og det kan ses ved at benytte getvalididcard, der returnerer brugerens id kort. Et tredje tilfælde er det, hvor en klient selv står for at kontakte en service, men ikke vil håndtere opbevaringen af id kort og kommunikationen med STS. Her kan klienten få det underskrevne id kort fra SOSI GW og selv vedhæfte det i en besked der skal sendes. Hvis der ikke eksisterer noget id kort for brugeren, returneres der en fault. Denne fault angiver status for brugerens id kort: Enten kan en bruger være i gang med signering, og der kan derfor med god mening prøves igen lidt senere, eller også er der slet ikke oprettet noget id kort, og det giver derfor ikke mening at prøve igen, før et nyt id kort er bestilt. Metoden kan i øvrigt konfigureres fra serveren, så selve id kortets signerede digest ikke sendes med ud, da det i visse tilfælde kan betragtes som et brud på sikkerheden. 2.2.7. logout Denne metode fjerner det signerede id kort for en bestemt bruger. Som argument kræves NameID [Krav 11]. 2.3. HTTP API En del af SOSI GW's funktionalitet sker gennem et normalt HTTP API for at understøtte, at normale browsere kan komme i kontakt med systemet for at signere digests. Det sker ved at klienten får svar på Side 21 af 38

et request om at oprette et nyt id kort, enten eksplicit eller implicit, og bruger den url, der kommer ud af det, til at sende til en browser. For at understøtte proxy/nat mellem browserne og SOSI GW, er det muligt at konfigurere host adressen for SOSI GW og dermed gøre det muligt at sende requests gennem en proxy på det lokale netværk. Browseren åbner adressen og bliver præsenteret for en Java applet, der kan bruges til at signere digestværdien fra det nye id kort. Adressen er en engangsadresse, der er identificeret af en lang og tilfældigt genereret tekststreng, og som kun er gyldig i max 30 sekunder. Serveren genererer herefter en ny URL, som bruges af appletten til at sende svaret. Denne URL er gyldig i 60 sekunder, hvilket betyder at brugeren skal have signeret inden dette tidsrum. Sker det ikke, vil der fremkomme en fejlmeddelelse når brugeren prøver at signere. På siden med appletten vil tiden være angivet. Gyldighedsperioderne kan konfigureres i administrationsinterfacet [Krav 10, Krav 12, Krav 13]. Den URL baserede signering baseres på OpenSign, der er en Java applet, som implementerer browserbaseret signering. Resultatet af denne applet er en XML repræsentation af signaturen, struktureret i forhold til W3C's XML Signature skema. 2.4. Audit Logning For at sikre systemets performance og skalabilitet logges der, som allerede nævnt, to steder: Hos den enkelte server og på en central loghost. Ved hver handling til systemet skrives til en lokal log, og med passende intervaller synkroniseres denne log til en central log, som giver et samlet overblik over hvilke hændelser, der har været foretaget. Der logges følgende: Proxy requests: Tidspunkt, NameID, System id, ip for afsender, endpoint, IDCardID (kortets unikke id Service requests: Tidspunkt, NameID, System id, ip for afsender, operation, status (OK/ERR) URL requests: Tidspunkt, NameID, System id, ip for afsender, status (OK/ERR) Desuden logges alle ugyldige requests, både Webservice requests og requests der stammer fra den browser baserede signering. Side 22 af 38

2.5. Licenser De valg af open source komponenter vi vælger at bygge SOSI GW på har betydning for hvilken licens SOSI GW selv kan vælge udgives under. Vi har derfor gennemgået licenserne for disse og deres afhængigheder af andre komponenter, dog ikke for Apache projekter, da de alle benytter Apache 2.0 licensen. Komponent Licens URL Apache Axis2/Java Apache 2.0 http://ws.apache.org/axis2/ Apache Commons Apache 2.0 http://commons.apache.org/ Apache Tomcat Apache 2.0 http://tomcat.apache.org/ Google Web Toolkit Apache 2.0 http://code.google.com/webtoolkit/ PostgreSQL (server + jdbc) BSD license http://www.postgresql.org/ JGroups GNU LGPL http://www.jgroups.org/ Opensign GNU LGPL http://www.openoces.org/opensign/ SOSI Seal (SOSI biblioteket) GNU LGPL / CPL http://sosi.dk/ [Krav 19] BC Mail Bouncy Castle license http://www.bouncycastle.org/java.htm l Apache XML Security Apache 2.0 http://xml.apache.org/security/ BC jce Bouncy Castle license http://www.bouncycastle.org/java.htm l Alle disse licenser er ret liberale og tillader et ret frit valg af open source licens til SOSI GW [Krav 18]. Da PostgreSQL ikke er en integreret del af produktet kan man se bort fra dens licens i valget. Oplagte valg er Apache 2.0 og GNU LGPL, da de begge tillader andre at bygge videre på SOSI GW, inklusiv mulighed for at indbygge hele eller dele af SOSI GW i closed source produkter. Alternativt kan GPL benyttes, hvis man ønsker forhindre indbygning i closed source produkter. Se http://www.gnu.org/philosophy/license list.html for en diskussion af licenserne. Side 23 af 38

2.6. Svartider 2.6.1. Gateway operationen proxy I [krav 26] omtales svartider for proxy, baseret på måling af tiden fra et request er modtaget til det er afsendt igen med signeret id kort i, for beskeder på 4kb. Vi vil naturligvis leve op til denne målemetode og de svartidskrav der forudsættes. Men vi mener at et mere præcist mål for SOSI GW performance er at måle tiden fra den komplette SOAP header er modtaget, til den nye SOAP header inkl. signering er afsendt. Baggrunden er at SOSI GW ikke har behov for at se på eller ændre i SOAP body, og derfor med fordel kan kopiere den råt stream to stream, som beskrevet tidligere. 2.6.2. Administrationsinterfacet Administrationsinterfacet benyttes gennem en browser. Der vil være en vis opstartstid til at logge på og starte applikationen, men derefter er de fleste handlinger lokale i browseren, og forventes derfor at være væsentligt hurtigere end de 10 sekunder, som er kravet. Der er dog enkelte handlinger, der kan have behov for at benytte løbende fremdriftsvisning, som beskrevet i [krav 27]: Fremsøgning af log linjer ud fra ikke optimerede kriterier. Fremsøgning af liste af id kort ud fra andet kriterie end CPR nr. Bemærk at begge funktioner ikke er krævet af kravspecifikationen, men de virker rimelige og kan implementeres som option. 2.7. Nødvendig hardware Følgende er forudsætningerne for dimensioneringen. Bemærk at tiderne ikke siger noget om svartider, da de kun er pessimistisk anslået til brug for dimensionering. Til vurderingen er benyttet tider for sosiseal, som kan aflæses på sosi.dk for en 3GHz single core cpu [Krav 28]. 10.000 kald af proxy i timen, jævnt fordelt [Krav 26]. Ukrypteret over HTTP Behandlingen i SOSI GW bruger 100 ms cputid. Hvert kald tager 10 sekunder at besvare for den kaldte service I gennemsnit regnes med 10KB for både request og response. 10.000 kald af getvalididcard i timen, jævnt fordelt. Behandlingen i SOSI GW bruger 50 ms cputid. Side 24 af 38

Svartiden af disse ventes af være 0.5 sekund 1.000 udstedelser af id kort i timen, gennem browser servicen, da den er værst [Krav 25]. Behandlingen i SOSI GW bruger 500 ms cputid. Der afsættes 60 sekunder til brugerens svar. Der downloades en applet + html på ialt 1MB 25.000 gyldige signerede id kort i cachen Et id kort antages at fylde 8kb i gennemsnit (Eksempel i Den Gode Webservice) 2.7.1. Krav til cpu hastighed Samlet anslået cpu forbrug i millisekunder pr. time er 10000*150 + 10000*50 + 1000*500 = 2*1000000 som svarer til 56% af cputiden på en 3GHz single core cpu. Af hensyn til driftstabilitet og for at holde svartiderne nede er det dog bedre at benytte 2 eller flere maskiner, selvom det i gennemsnit er tilstrækkeligt med en. 2.7.2. Krav til RAM Cachen af id kort fylder 25.000*8KB = 200MB. Hvert kald til proxy optager en tråd i 10 sekunder. Der er derfor behov for 100000/3600=27 tråde til dette. Til kald af getvalididcard er der behov for 5*1000/3600=2 tråde til dette. Hver udstedelse af et id kort kræver en tråd til at sende siden med signing applet. Der er derfor behov for 500/3600 = noget under 1 tråd til dette. Samlet forventes et behov på 30 tråde, men med mere ujævn fordeling dimensioneres RAM krav ud fra 500 tråde. En tråd koster typisk 64KB udenfor heap'en i jvm'en. Vi anslår at der også bruges 256KB i heapen til her til transportbuffere og øvrige data. Konfigurationsdata, administrationsadgangen, logning og øvrige data anslåes til højst at kræve 64MB heap. Postgresql er ikke i sig selv ret grådig. Vi anslår 256MB til Postgresql. Samlet anslået højeste forbrug af heap i MB er altså 200 + (500*256/1024) + 64 = 389. En java heap på 512MB er et rimeligt bud. Dertil kommer jvm'ens forbrug uden for heap'en, som anslås til 256MB. Det samlede minimumskrav til maskinen er dermed 1GB RAM, med en anbefaling på 2GB RAM for at efterlade plads til OS og caching af diskblokke. Maskinen til den centrale logdatabase bør ligeledes have 2GB RAM af hensyn til caching af diskblokke. Side 25 af 38

2.7.3. Øvrige krav til hardware Der bør benyttes spejlede diske på maskinerne, da den midlertidige lokale kopi af loggen ellers kan gå tabt ved diskfejl. Med 1KB logoplysninger pr kald forventes der op til 20MB loghændelser pr. time, hvilket giver op til 7GB pr. år på de lokale diske. Ved overførslen til den central logning gemmes data mere normaliseret, men til gengæld indekseret til søgninger, så der anslåes et behov på 3GB pr år og derudover plads til søgeindekser. Bemærk at de decentrale logdatabaser kun vokser markant, hvis den centrale logdatabase er utilgængelig gennem længere tid, men at der bør være reserveret plads til dem netop til det tilfælde. Dertil kommer plads til konfigurationsdata, men de anslås at være neglicible Der transporteres 4*10000 kald hver time af 10KB ialt på maskinernes netværksinterface som webservices, samt 1000 svar af 1MB til browsere. I alt svarer det til omkring 1400 MB pr. time eller 400KB/sekund i gennemsnit. Dertil kommer den interne trafik mellem maskinerne i SOSI GW gruppen, som forventes at være af højst samme størrelsesorden. Der er dermed ikke store krav til netværksbåndbredde, ud over at det gavner den samlede svartid for brugen af SOSI GW at have en hurtig linie. Af hensyn til at holde den interne multicast trafik for sig selv kan det være en fordel at benytte et VLAN til denne. Desuden skal det bemærkes, at der skal transporteres op til 200MB (de 25.000 id kort) til et nyt medlem af cluteret, når dette melder sig ind. Dette kan være endnu en grund til at isolere JGroups trafikken på et separat VLAN, evt også over et internt interface. 2.7.4. Konklusion På baggrund af anlysen onvenfor anbefales at benytte 3 ens maskiner, konfigureret med minimum 2 CPU'er (eller en dual core) på 2GHz 2 GB RAM 20 GB tilgængelig diskplads på i form af 2 diske opsat i et spejl Gigabit switchet net maskinerne imellem på eget VLAN [Krav 28] 2.8. Dokumentation I forbindelse med den endelige leverance, medfølger følgende dokumentation: Dokumentation af servicesnitflader Vedligeholdelsesdokumentation i form af beskrivelse af udviklingsmiljø og projekt og kodestruktur Side 26 af 38

Installations og administrationsvejledning Sikkerhedsvejledning [Krav 30, Krav 31] Side 27 af 38

3. Test Der konstrueres en test klient, der på simpel vis kan konfigureres mht. graden af parallelitet (antal tråde), indlagte forsinkelser imellem afsendelse af requests, procentvis vægtning af de relevante typer af kald (proxykald, samt de forskellige regulære webservice kald). Denne klient benyttes til at drive både skaleringstest, load/stresstest og endurancetest. Derudover kan den samme klient benyttes i forbindelse med aftestning af et clustersetup, dvs. loadbalancering, rullende opgradering og failover. Klienten opsamler statistik vedr. responsetid og throughput (req/s) for en testkørsel. Der konstrueres tillige en webservice stub, der kan illudere en 3. parts webservices. Webservicestubben indlægger en konfigurerbar forsinkelse i behandlingen af requests for at simulere længerevarende kald/høj latency. Det vil være webservicestubbens service interface, der bestemmer payload for de proxykald, der videresendes af gateway en. Dette interface vil som minimum indeholde en operation, der overfører minimale datamængder og en operation, der overfører store mængder data. 3.1.1. Skaleringstest Skaleringstesten foretages ved at måle responsetiden i klienten ved forskellige grader af belastning, og verificere at denne ikke stiger mere end proportionalt med belastningen. Det totale throughput ved de forskellige belastningsgrader måles. 3.1.2. Load/stresstest I forlængelse af skaleringstesten fastslås den belastningsgrad hvor throughput ikke længere stiger som funktion af antal afsendte requests. Det verificeres, at overbelastning ikke fører til fejlbehandlede requests samt at systemet efterfølgende kommer sig uden nogen blivende degradering. Side 28 af 38

3.1.3. Endurancetest Endurancetest foretages ved en længerevarende test, hvor testklienten konfigureres til en belastningsgrad, der ligger et stykke under det overbelastningspunkt, der er identificeret under load/stresstesten. Under endurancetest monitoreres memoryforbrug, antal tråde, og CPU forbrug. 3.1.4. Loadbalancering Loadbalancering aftestes i et miljø med mindst 2 gateway servere. Dette foretages ved at gentage skaleringstest og load/stresstests. Det verificeres at overbelastningspunktet øges i forhold til et miljø bestående af kun én server. Det må forventes, at gevinsten ved at tilføje en server vil være mindre end liniær. Det vil derfor være fordelagtigt at foretage en load/stresstest hvor throughput og overbelastningspunkt identificeres som funktion af antal af servere i gateway clusteret. 3.1.5. Rullende opgradering Der aftestes rullende opgradering i et clustered miljø. Det vil bestå i kontrolleret nedlukning af en server, redeploy af applikation samt genindsættelse i clusteret. Dette foretages samtidig med at testklienten vedligeholder en stabil belastning af clusteret. 3.1.6. Fail over Der testes at de resterende servere i et cluster på korrekt vis kan forsætte håndteringen af indkommende requests hvis en server tages ud af drift uden varsel (fx ved at afbryde netværksforbindelsen til den pågældende server). Det vil være relevant at måle hvordan throughput og responsetider udvikler sig hen over testen. Til udførelsen af performancetests anvendes en række værktøjer, som Trifork alle har gode erfaringer med. Det drejer sig primært om JMeter og Trifork Profiler til eksekvering og måling af tidsforbrug. Endelig kan Performanceguard (fra Premitch, en Trifork partner) inddrages for at måle netværkstrafik. Side 29 af 38

4. Hovedtidsplan Ifølge kravspecifikationen indeholder tidsplanen 4 leverancer: Funktionel testversion d. 1. 11. 2007 Fuldt funktionel version d. 1. 12. 2007 Driftsklar version d. 1. 2. 2008 Endelig aflevering d. 1. 4. 2008 Planen er koordineret med udviklingen af Det Fælles Medicingrundlag, men indeholder en performancetest periode efter 3. leverance. Vi finder det mere hensigtsmæssigt at starte performancetests allerede i løbet af udviklingen af 1. version og afslutte den i forbindelse med afleveringen af 2. version d. 1. 12. 2007. Vi foreslår desuden at Trifork står for afviklingen af performancetest i eget miljø, naturligvis fuldt dokumenteret både med hensyn til testmiljø og resultater. Desuden finder vi at 3. leverance ligger kritisk tæt på starten for pilotdrift for Det Fælles Medicingrundlag, og foreslår derfor at leverancen rykkes frem, så den i stedet finder sted d. 1. 1. 2008. Herefter vil der så være en måned, hvor driftsmiljøet kan klargøres og SOSI GW kan installeres. Hovedtidsplanen ser derfor således ud: Udviklingsstart d. 15. 9. 2007 Funktionel testversion d. 1. 11. 2007 Fuldt funktionel og performancetestet version d. 1. 12. 2007 Driftsklar version d. 1. 1. 2008 Endelig aflevering d. 1. 4. 2008 Tidsplanen forudsætter følgende: At der ikke findes kritiske fejl i SOSI Seal, der gør at udviklingen ikke kan fortsætte. At der findes en installationsklar STS, som kan benyttes i forbindelse med udvikling og test. [Krav 33] 4.1. Risikoelementer Det største risikoelement i løsningen er distribueringen af tilstand via JGroups. Trifork har erfaring med JGroups fra tidligere projekter, herunder Triforks egen applikationsserver, men der vil formentligt alligevel opstå usikkerheder. Dette tackles ved, at der tidligt i udviklingsforløbet indlægges tid til at afprøve JGroups i de konkrete situationer og udføre performancetests. Derved afdækkes eventuelle problemer tidligt i forløbet, og udviklingen kan tilpasses dette. Tidsplanen indeholder allerede tid til at Side 30 af 38