(-- JanRiis - 10-01-2006)
(-- KaareKjelstroem - 20-01-2006)

Har vi opnået, hvad vi gerne ville? Lad os igen se de tekniske målsætninger for SOSI:

Warning: Can't find topic Main.SOSIConcreteTechGoals

Vi har fået etableret en føderation med Single-Sign-On, idet klienter med deres ID kort kan kalde services hos mange forskellige serviceudbydere inden for føderationen uden at skulle "logge ind" hos hver af dem. Omvendt kan hver serviceudbyder nemt afgøre brugerens autenticitet og kan vha. de påtrykte personlige oplysninger på ID kortet foretage en autorisation af brugeren i serviceudbydersystemet.

Alle sikkerhedsmæssige aspekter er håndteret, enten af designet, eller ved forudsætning om anvendelse af SundhedsDataNettet. Designet forholder sig i videst mulig omfang til andre QoS aspekter. F.eks. er IdP'en kun involveret i begyndelsen (autentifikationsprocessen), så antallet af kald reduceres mest muligt. Al kommunikation foregår i størst muligt omfang direkte mellem serviceaftager og serviceudbyder.

Designet er temmelig robust. Den største driftmæssige risiko ligger i et nedbrud hos IdP'en, men da al kommunikation efter udstedelse af ID-kort foregår direkte mellem serviceaftager og -udbyder, kan alle brugere med et gyldigt ID kort fortsætte med at arbejde (indtil ID kortets gyldighedsperiode udløber). Kun klienter, der ikke har et gyldigt ID kort, er forhindret i at kalde services inden for føderationen.

Designet baseres på digitale certifikater, nationalt og internationalt anerkendte standarder. Der er intet i designet der kræver anvendelse af en speciel hardware- eller softwareplatform, så alt i alt må det konstateres, at designet lever op til den tekniske målsætning.

De beskrevne tekniske Use Cases gør en række antagelser om de forskellige aktørers egenskaber. I dette afsnit findes en konsekvensanalyse for hver af aktørerne i designet, for at kunne realisere designet. Konsekvenser markeret med grøn angiver elementer, der er fælles på tværs af serviceaftagere, serviceudbydere og/eller Idp'er.

7.1 Konsekvenser for serviceaftager (f.eks. et medicinmodul)

Serviceaftager skal kunne

1. Sende og modtage web services beskeder over Sundhedsdatanettet.
2. Håndtere private certifikater, f.eks. ved brug af en certifikatserver.
3. Foretage SOSI SAML SOAP baseret autentifikation mod en IdP.
4. Håndtere server ID kort for sig selv, og for de serviceudbydere, der indgår i løsningen.
5. Håndtere personlige ID kort.
6. Signere en besked med en sundhedsprofessionels private nøgle.
7. Verificere en digital signatur givet en signeret besked og den tilhørende offentlige nøgle. Dette skal kunne gøres for signaturer på kuverten såvel som i beskeden.
8. "Kuvertere" en meddelelse, og kunne underskrive denne kuvert digitalt med serviceaftagersystemets private nøgle.
9. Logge alle svar, deres digitale signatur og tilhørende offentlige nøgle (eller en reference dertil). Loggen skal også indeholde data fra kuverten og dennes signatur. Krav til logning ligger uden for SOSI specifikationen og i stedet henvises til Persondataloven (lov nr. 429 af 31. maj 2000) og Patientretstillingsloven (lov nr 546 af 24. juni 2005).
10. Have samme tidsforståelse som de øvrige systemer i komplekset. Alle parter bør være i samme tidszone, og bør følge samme retningslinier for sommer/vintertid.

7.2 Konsekvenser for serviceudbyder (f.eks. Medicinprofilen)

Serviceudbyder skal kunne

1. Sende og modtage beskeder over Sundhedsdatanettet.
2. Foretage SOSI SAML SOAP baseret autentifikation mod en IdP.
3. Have sit eget private certifikat installeret.
4. Håndtere sit eget server ID kort (rekvirering og fornyelse).
5. Signere en besked med sin egen private nøgle
6. Signere en kuvert med sin egen private nøgle
7. Verificere en digital signatur givet en signeret besked og den tilhørende offentlige nøgle.
8. "Kuvertere" en meddelelse og kunne underskrive denne kuvert digitalt med sin private nøgle.
9. Verificere en digital signatur på en kuvert.
10. Logge alle forespørgsler, deres digitale signatur og tilhørende offentlige nøgle (eller en reference dertil). Loggen skal også indeholde data fra kuverten og dennes digitale signatur.
11. Have tidsforståelse som de øvrige systemer i komplekset. Alle parter bør være i samme tidszone, og bør følge samme retningslinier for evt. skift af tidszone (sommer/vintertid).

7.3 Konsekvenser for IdP-systemet

IdP'en skal kunne

1. Sende og modtage beskeder over Sundhedsdatanettet.
2. Have sit eget private certifikat installeret.
3. Signere en besked med sin egen private nøgle
4. Signere en kuvert med sin egen private nøgle
5. Validere et certifikat (OCES, udløbet, CRL)
6. Påtrykke domænespecifikke oplysninger, f.eks. autorisationskode (i dette setup for Sundhedsvæsenet).
7. Udstede ID kort (system og personlige)
8. Verificere en digital signatur givet en signeret besked og den tilhørende offentlige nøgle.
9. "Kuvertere" en meddelelse, og kunne underskrive denne kuvert digitalt med IdP'ens private nøgle.
10. Verificere en digital signatur på en kuvert.
11. Logge alle forespøgsler, deres digitale signatur og tilhørende offentlige nøgle (eller en reference dertil). Loggen skal også indeholde data fra kuverten og dennes signatur.
12. Have samme tidsforståelse som de øvrige systemer i komplekset. Alle parter bør være i samme tidszone, og bør følge samme retningslinier for evt. skift af tidszone (sommer/vintertid).
13. Håndtere et register over serviceudbydernes system ID kort, og skal kunne udlevere et ID kort ved forespørgsel derom fra en part i komplekset (ID card resolving).

TODO: Vi har ikke beskrevet protokollen for ID card resolving

7.4 En SOSI komponent

Da mange af konsekvenserne (de grønne ovenfor) går igen for forskellige aktører i komplekset, og da disse krav til parterne ikke er specielt forbundet til aktøren eller for den sags skyld til Sundhedsvæsenet, er det oplagt at lave en fælles komponent, der kan varetage disse aspekter for alle aktører.

Da de Suns JEE er defacto standarden i Danmark for udviklingen af EPJ-systemer, forventes komponenten i første omgang at blive implementeret i Java. Hvis et behov viser sig, kan det desuden overvejes at lave en .NET udgave.

Komponenten skal overordnet indeholde funktionalitet til at kommunikere med IdP'en, til at håndtere ID-kort, til at håndtere SOSI service kuverter og til basal certifikat behandling.

7.4.1 Kommunikation med IdP

En SOSI IdP kan udstede ID-kort og efterfølgende udlevere udstedte ID-kort. Dette giver anledning til følgende funktioner i komponenten:

1. Authenticate Skab en SAML <AuthnRequest> besked og/eller modtag den som parameter. Send derpå beskeden til IdP'en. Metoden skal kunne håndtere forskellige permutationer af akkreditiver i det tilfælde hvor <AuthnRequest> beskeden ikke medsendes som parameter.
2. AuthnRequest Skab en SAML <AuthnRequest> besked med eller uden digitale signaturer, der i det tilfælde så forventes håndteres andetsteds (f.eks. af en signaturserver).
3. Retrieve Givet et CVR-...-RID-... eller et CVR-...UID-... hentes det tilhørende ID-kort fra IdP.

7.4.2 Håndtering af ID-kort

De ID-kort, en service modtager typisk som følge af et SAML <AuthnRequest> kald har en række operationer tilknyttet:

1. Validate Valider gyldigheden af et ID-kort (udløbstid, signatur, ...)
2. Store Gem ID-kortet i en lokal model
3. Retrieve Hent et eksisterende ID-kort givet CVR-...-RID-... eller et CVR-...UID-...
4. Delete fjern et ID-kort fra den lokale model.
5. Clean Ryd op i den lokale model og fjern udløbne ID-kort. Dette kan evt. også gøres lazy dvs. når det opdages at et ID-kort er udløbet.

7.4.3 Håndtering af kuverter

Når logon er foretaget er der stadig et vist arbejde forbundet med håndteringen af SOSI kuverterne. Komponenten skal derfor stille følgende kuvertfunktionalitet til rådighed.

1. ValidateMessage Valider gyldigheden af en besked, f.eks. et SAML <Response> eller et svar på et webservice kald.
2. CreateEnvelope Laver en SOSI web services konvolut omkring en SOAP body og signerer den.
3. Extract Givet en SOSI konvolut eller SAML <Response> besked, udtrækkes konvoluttens dele som lokale objekter.

7.4.4 Håndtering af certifikater

EPJ klienter vil have behov for en omfattende certifikathåndtering, men serviceudbydere vil typisk ikke skulle benytte mere end et certifikat i kommunikationen. Det giver derfor mening at komponenten også har en basal mængde funktionalitet til håndtering af certifikater og tilhørende private nøgler. Et lokalt keystore til nøglerne forventes etableret:

1. Install Installerer et PKCS12 keystore indeholdende et OCES certifikat og evt. den tilhørende nøgle. Kan dermed også anvendes til import af IdP certifikat f.eks.
2. Remove Afinstallerer et certifikat og den tilhørende private nøgle fra det lokale keystore.
3. Retrieve Henter et nøglepar op fra keystore.
4. Sign Lav en signatur med en privat nøgle
5. Validate Valider en signatur over et givet sæt data. I Java verificeres en signatur sådan her.