1. Hvad er NSP

Den Nationale Service Platform er en teknisk platform, der sammen med en mængde standarder og aftaler gør det muligt at udbyde et antal services til offentlige og private it-systemer. I dette dokument vil de vigtigste elementer af NSP blive gennemgået og forklaret.

1.1. Den tekniske platform

NSP platformen består af en Linux distribution med en Wildfly applikationsserver. Alle komponenterne på platformen kører ovenpå denne applikationsserver og anvender en MariaDB database som persistentlag. Foran Wildfly applikationsserveren er der en loadbalancer. Valget af Wildfly dikterer at alle komponenter er skrevet i programmeringssproget Java (eller andre sprog der kan afvikles i en Java VM), der er dog ingen krav til hvilke sprog anvendere af platformen skal benytte.

1.2. Webservices

De eksternt vendte services på NSP udstilles for nuværende som SOAP/XML webservices typisk som identitetsbaserede web services, der overholder “Den Gode Web Service” (DGWS) eller OIO-IDWS standarderne. Du kan læse mere om DGWS hhv. OIO-IDWS her:

• "Den Gode WebService (DGWS)" fra MedCom.
• Anvendelsen af OIOIDWS i nationale tjenester på sundhedsområdet

Disse sider redegør også for en række af de sikkerhedshensyn, overordnede sikkerhedsværn og hjælperedskaber, der er udviklet til NSP.

Alle forespørgelser og svar sendes som SOAP-XML over HTTP protokollen. Nogle af de webservices som identitetsservicen (STS) udbyder er dog undtaget fra reglen om DGWS. I NSP regi er SEAL.Java og SEAL.Net blevet udviklet for at hjælpe både anvendere og udstillere af services. SEAL pakker de mange XML og sikkerhedsstandarder ind i simple metoder, og sikrer en uniform serialisering og deserialisering af forespørgelser og svar.

1.3. Sundhedsdatanettet

NSP er placeret på sundhedsdatanettet og adgang hertil kræver derfor en godkendelse fra MedCom. Anvendelsen af Sundhedsdatanettet gør at konfidentialiteten og integriteten af forespørgelser og svar er sikret. Se evt. ”Kom på NSP – kort forløbsbeskrivelse".

1.4. Distribueret platform

NSP er ikke blot en enkelt platform, men derimod flere instanser distribueret rundt omkring i landet. Der findes en Central NSP (cNSP), regionale NSP'er (dNSP) og en såkaldt BackOffice instans. De regionale og den centrale NSP er stort set ens, men deres anvendere er forskellige. Hver region har sin egen NSP som blandt andet anvendes af hospitalerne, hvorimod den centrale NSPs anvendere f.eks. er lægepraksiser og plejehjem. Denne distribuerede tilgang betyder, at der er et flow af data fra BackOffice platformen til både cNSP og dNSP. F.eks. kommer opdateringer til stamdata ind i BackOffice fra flere kilder for derefter at flyde ud på NSP'erne.

1.5. Miljøer

Ud over produktionsmiljøet findes der fire testmiljøer som anvendere kan få adgang til. Adgang kræver en aftale med NSP-operatøren samt oprettelse af testcertifikater mv. En guide til tilslutningsforløbet kan ses i " Adgang til fælles testmiljøer".

2. Hvem styrer NSP

Den Nationale Service Platform (NSP) ejes og styres af Sundhedsdatastyrelsen (SDS). Alle opgaver på NSP udliciteres efter gældende EU-regler og er fordelt på et par håndfulde it-firmaer. NSP opereres af Sundhedsdatastyrelsen med bistand fra Capgemini A/S og driftes af Netic A/S. Support til anvendere og udstillere leveres af IBM, Netic A/S og Arosii A/S. Komponenterne på NSP ejes af SDS, men er udviklet af flere forskellige leverandører.

3. Sikkerhed på NSP

En af de vigtigste aspekter af NSP er den sikkerhedsmodel, der er lagt over alle komponenter på platformen. For at kalde en komponent på NSP skal en anvender medsende et id-kort signeret af en identitetsudbyder i hvert kald. De vigtigste aspekter af sikkerhedsmodellen gennemgås i de følgende afsnit, og den samlede model er beskrevet i Den Gode Webervice.

3.1. Certifikater

Sikkerheden på NSP bygger på certifikater udstedt af Nets DanID. Der findes 3 forskellige slags certifikater som kan bruges på NSP:

• Medarbejdercertifikater (MOCES)
• Virksomhedscertifikater (VOCES)
• Funktionscertifikater (FOCES).

Et certifikat består af en offentlig og en privat nøgle der tilsammen gør det muligt at signere et id-kort, således at en serviceudstiller kan verificere identiteten af anvenderen.

3.1.1. Medarbejdercertifikater

MOCES certifikater udstedes til en enkelt person ansat ved en virksomhed og repræsenterer dennes relation til virksomheden. Hvert medarbejdercertifikat har et entydigt CVR/RID- nummer der er opbygget af virksomhedens CVR-nummer, samt et ressource identifikationsnummer. Dette CVR/RID-nummer indgår i ejerinformationen i certifikatet.

3.1.2. Virksomhedscertifikater

VOCES certifikater udstedes til selve virksomheden og er ikke knyttet til nogen person. Virksomhedens CVR-nummer indgår i ejerinformationen i certifikatet.

3.1.3. Funktionscertifikater

FOCES certifikater udstedes til en applikation, en enhed, en proces eller en service hos en virksomhed. De bruges primært til automatiske batch processor. Virksomhedens CVR-nummer indgår i ejerinformationen i certifikatet. NSP anbefaler anvendelsen af FOCES certifikater set i forhold til VOCES.

3.2. Infrastruktur (Nets og test/prod føderation)

Certifikater udstedt af Nets til brug på NSP hører enten til under testmiljøet eller produktionsmiljøet. Et certifikat kan kun bruges i det miljø, det er udstedt til.

3.3. Id-kort

Et id-kort er et XML-dokument der indeholder informationer om den person, virksomhed eller applikation, som foretager en forespørgsel mod en NSP-service. Id-kortet medsendes som en del af SOAP-headeren i alle kald, der foretages mod en komponent på NSP. Id-kortet anvendes af serviceudbyderen til at verificere identiteten af anvenderen, samt til at undersøge om vedkommende er berettiget til at få adgang til servicen. Der er to slags id-kort på NSP, et brugerid-kort og et systemid-kort. Brugerid-kortet anvendes sammen med et medarbejdercertifikat og systemid-kortet anvendes sammen med et virksomhedscertifikat eller et funktionscertifikat. Et id-kort indeholder blandt andet følgende oplysninger:

• Anvenderidentitet - En streng der bruges til at identificere subjektet
• Gyldighed - Den periode hvor id-kortet er gyldigt
• Virksomhedsoplysninger - Blandt andet CVR-nummer
• Brugeroplysninger - Blandt andet CPR-nummer
• Digest - Base64 enkodning af en SHA1 hashing af den kanoniske form af id-kortet      OBS → SHA3?
• Signature - Base64 enkodning af RSA signering af digestet
• Certificate - Den offentlige nøgle i det certifikat der blev brugt til signering

Ovenstående er illustreret i den følgende figur.

3.4. Føderation og ombytning af id-kort

I stedet for at alle komponenter på NSP skal kunne verificere alle de certifikater som er udstedt til samtlige anvendere, er der indført en føderation hvor anvenderens id-kort bliver signeret af en identitetsudbyder (STS). Anvendelsen af en identitetsudbyder er skitseret nedenfor

• Anvendersystemet bygger et id-kort og signere det med eget certifikat.
• Id-kortet sendes til STS der tjekker korrektheden af udvalgte dele af id-kortet, samt signaturen
• STS opbygger et nyt id-kort med de samme informationer og signere det med et certifikat der stoles på i hele føderationen
• STS sender det nye id-kort retur til anvendersystemet
• Anvendersystemet indsætter nu det nye id-kort i alle fremtidige forespørgelser mod NSP-komponenter
• NSP-komponenten verificerer at id-kortet er signeret af føderationens certifikat og stoler herefter på udvalgte dele af id-kortet

4. Hvad findes der på NSP

4.1. Hjælp til anvendere

Ud over komponenter der udstiller kernefunktioner fra forskellige forretningsområder, er der to komponenter på NSP'en, der hjælper anvendere med at kalde andre komponenter. De to komponenter er afkoblingskomponenten (DCC) og gatewayen (GW).

4.1.1. Afkoblingskomponenten

I stedet for at kalde de forskellige komponenters webservices direkte, tilbyder afkoblingskomponenten at fungere som en softwarerouter for anvenderen. Komponenten har en konfiguration der indeholder en mapning mellem SOAP Actions og endpoints (Se f.eks. mapningen for cNSP prod her Inventory - cnsp DCC ). På den måde er komponenten i stand til at viderstille et kald ud fra værdien af HTTP-headeren. Det anbefales at anvendere altid kalder komponenternes webservices gennem afkoblingskomponenten.

4.1.2. Gatewayen

For at anvendere af NSP kan tilbyde Single Sign-on til slutbrugerne, er det nødvendigt at hvert enkelt it-system ikke skal udstede et id-kort for den samme bruger. Gatewayen tilbyder derfor at holde en cache af id-kort som alle anvendere kan deles om. Når en slutbruger logger på et it-system og udfører en handling der kræver et id-kort, sendes forespørgslen gennem gatewayen, der indsætter det korrekte id-kort og vidersender til den valgte webservice. Hvis cachen ikke indeholder et gyldigt id-kort for slutbrugeren må it-systemet oprette et nyt, som herefter gemmes i cachen. Gatewayen anvender WSAddressing standarden når den skal afgøre hvor en forespørgsel skal sendes videre til.

4.1.3. Forespørgsel

Følgende er en kort gennemgang af hvordan anvendelsen af DCC og GW kan foregå fra eksempelsystemet ABC til eksempelservicen XYZ:

1. Annie logger på ABC og vil se information, som skal hentes fra en NSP-service.
2. ABC laver et usigneret id-kort med Annies CPR-nummer som identifikation
3. ABC sender et forespørgsel til DCC med SOAP Actionen http://nsi.dk/xyz/2013/08/09/MinService i HTTP-headeren
4. DCC tilføjer WSAddressing elementerne "To" og "Action" og sender forespørgelsen videre til GW
5. GW har ikke et valid id-kort for Annies CPR-nummer og sender derfor en fejlbesked tilbage
6. ABC åbner en browser med den URL som indgår i fejlbeskeden
7. Annie taster kodeordet for sit medarbejdercertifikat i browseren og får derved lagt et signeret id-kort i GW cachen
8. ABC gentager kaldet fra 2) der igen vidersendes af DCC
9. GW skifter det usignerede id-kort i forespørgelsen ud med det id-kort i cachen, der er signeret med føderationens certifikat
10. GW vidersender forespørgelsen til XYZ
11. ABC modtager svar fra XYZ og Annie slipper for at skrive sit kodeord igen ved næste kald fra ABC eller andre systemer der anvender GW

Hvis ABC ikke havde ønsket at åbne en browser for at få signeret sit id-kort udstiller gatewayen også webservicemetoder, som kan bruges til at få oprettet et id-kort direkte i cachen.

4.2. Stamdataregistre

NSP importerer stamdata fra et antal nationale registre og tilbyder adgang hertil gennem Stamdata-komponentens services. Følgende stamdataregistre er tilgængelig på NSP:

Anvendes sammen med basis produktet kopiregisterservicen. Stamdataregistrenes struktur ses her: Stamdataregistre og tilhørende datatyper.

 

Registre der indgår i Fælles Stamkort

4.3. Forretningsservice

Følgende forretningsservice er tilgængelige på en NSP:

For yderligere information henvises der til "NSP services"

4.4. Basisservice

Følgende basisservice er tilgængelige på NSP:

For yderligere information henvises der til "NSP services"

4.5. Støtteservice

Følgende støtteservice til testformål er tilgængelige på NSP:

5. Hvilke krav stilles der til komponenterne

5.1. Husregler

Da der er mange leverandører af komponenter til NSP, er der blevet etableret et sæt husregler, der beskriver en række krav, som stilles til udviklingen og dokumentationen af nye komponenter. Ideen med husreglerne er at skabe en homogen platform, hvor mange forskellige komponenter kan co-eksistere og fungere i et driftsmiljø. Tilsvarende stille der krav om dokumentation Dokumentationskrav til NSP-platformen

5.2. Seal.Java

Da snitfladerne mod STS'en og selve føderationens struktur er defineret i Seal, anbefales det at komponentleverandører anvender Seal.Java til at verificere anvenderes id-kort samt til eventuelle kald til STS'en.