Denne "Kom Godt i Gang Guide" omhandler brug af NSP Gateway (herefter: NGW) også tidligere kendt under betegnelsen 'Kommunernes Gateway', som nu er et forældet begreb. Guiden er beregnet til it-faglige personer som skal til eller er i gang med at udvikle systemer, der skal integrere med NSP. Findes ingen erfaring med eller kendskab til SOSI-sikkerhedsmodellen (ID-kort mv.) anbefales det at læse Platformsintroduktion inden denne guide. Endvidere bør der være fortrolighed med alle aspekter beskrevet i dokumentationen omhandlende SOSI-GW - Leverancebeskrivelse og DCC - Kom Godt i Gang og den dokumentation disse refererer til.


OBS: Denne guide  er under revision - dele af indholdet mangler opdatering.

 Bemærk:


  1. SOSI-GW og NGW understøtter som udgangspunkt alene offentlige myndigheder. Dog kan private løsninger til sundhedspersoner i en overgangsperiode anvende SOSI-GW/NGW. På længere sigt vil SOSI-GW blive udfaset i forbindelse med overgangen fra DGWS/SOSI til det kommende IDWS XUA. Private løsninger til sundhedspersoner kan anvende SOSI-GW indtil udfasning ifm. endelig overgang til IDWS XUA.
  2. Den kommende IDWS XUA profil understøttes ikke af NGW/GW. Selve arkitekturen i IDWS-XUA dikterer at en cache ikke er brugbar, da disse kun er gyldige i meget kort tid og er specifikke for hvert enkelt servicekald. Derfor anbefales at NGW/GW kun anvendes i en overgangsperiode. Det anbefales i stedet at kalde DCC direkte på cNSP/dNSP og man står selv for at opbevare id-kortet i eget system. 

 




1. Funktion

NGW er en særlig udgave af en centralt kørende SOSI-GW, som stilles til rådighed for f.eks. danske kommuner, regioner eller andre organisationer der ønsker en central placeret SOSI-GW, hvor der også stilles garanti for isolation mellem den enkelte kommunes eller regions ID-kort-instanser tilhørende de enkelte brugere. Dette sikres i praksis ved hjælp af en partitioneret cache i NGW, som er opdelt, hvor nøglen på de individuelle indgange i cachen er en sammensat værdi af et specifikt HTTP header element samt NameID fra ID-kortet. Hvordan denne cache er præcis er konfigureret for den enkelte anvender af NGW afgøres ifbm. indgåelse af en aftale om brug af NGW.

2. Topologi

Topologisk er NGW placeret øverst på cNSP komponentstakken. Denne topologi kan ses her:


ngw topologi


Anvendersystemer ses til venstre og NGW og NSP services ses til højre. Anvendere er placeret udenfor SDN, men har adgang til NGW gennem en SDN-aftale. Mellem disse systemer flyder trafik på et ikke nærmere bestemt medium. Trafik der kommer ind gennem NGW kan forlade denne ad én af to veje:

  1. gennem DCC og videre til en NSP service; vist som 1. og 2.
  2. direkte fra NGW til en NSP service; vist som a.

Dette er uddybet i afsnit 3.2.

3. Anvendelse

NGW har en række karaktertræk til fælles med SOSI-GW, hvad angår virkemåde og kaldsemantik. Der eksisterer dog også undtagelser, som er beskrevet i nærmere detalje i følgende afsnit.

3.1. Adgang

Det er et krav at anvendere benytter TLS ved forbindelse til NGW. I praksis vil det være med benyttelse af HTTPS, i alle kald, under anvendelse af et FOCES klient-certifikat, som tilhører anvenders organisation. Dette certifikat valideres mod en whitelist i en netværkskomponent, der topologisk er placeret udenfor og før NGW. Kun certifikater der godkendes her vil få adgang til NGW. Et succesfuldt kald til en NSP-komponent gennem NGW over DCC ser overordnet således ud:


ngw adgang


Ved "detailbehandling af SOAP request" skal forstås bl.a. det arbejde NGW gør for at håndtere ID-kort ifht. den partitionering som er konfigureret, der sikrer isolation mellem ID-kort instanser.

Ved fund af følgende uregelmæssigheder ifbm. validering af kaldet returneres en passende reaktion fra Netværkskomponenten:

  • der findes intet felt "serialNumber" i FOCES klient-certifikatet, så forbindelsen afbrydes øjeblikkeligt
  • CVR og/eller FID i FOCES klient-certifikatet mangler, så forbindelsen afbrydes øjeblikkeligt
  • der er uoverensstemmelse mellem CVR i HTTP header, X-NSI-Kunde-CVR eller X-NSI-Kommune-CVR, og det whitelistede CVR fundet udfra FOCES klient-certifikatet. Der gives en HTTP statuskode 403 tilbage til kalder.
  • der er ingen whitelisting af CVR fundet i FOCES klient-certifikatet og der gives en HTTP statuskode 403 tilbage til kalder.


3.2. WS-Addressing

Som udgangpunkt flyder alle SOAP-requests fra NGW gennem DCC til en NSP-service. Da NGW er placeret før DCC er det unødvendigt at angive en target-URI (i "To"-feltet) i WSA-headeren i SOAP-requestet, da dette alligevel kommer forbi DCC'en og denne på baggrund af SOAP-action (i "Action"-feltet) i WSA-headeren afgør, hvor til SOAP-requestet skal forwardes. Undtagelsesvis kan target-URI angives i WSA-headeren i SOAP-requestet, hvis der er givet explicit instruktion herom i en specifik sammenhæng (kræver dialog og godkendelse hos SDS). Disse forskellige router er illustreret på topologi-diagrammet i afsnit 2, hvor routen der udgøres af "1." og "2." går gennem DCC og routen der udgøres af "a." går direkte fra NGW til en NSP-service, dvs. uden om DCC.

3.3. Passthrough

I visse tilfælde er det nødvendigt, at sende forespørgsler gennem NGW, som flyder gennem denne uden nævneværdig intervention af NGW og ID-kortet i SOAP-requestet derfor slipper gennem NGW intakt. Dette kan være nødvendigt i de tilfælde, hvor ID-kortet er signeret med andet end et MOCES-certifikat, fordi en NSP-komponent, der befinder sig bagved NGW, har krav om andet. Denne opførsel kaldes 'passthrough'. Til dette formål er introduceret et SOAP-header element, defineret som <sosigw:PassThrough/>, der kan indsættes i SOAP-requestet og styre opførsel. SOAP-header elementet placeres i namespace http://sosi.dk/gw/2007.09.01. Når NGW har konstateret, at der er tale om et passthrough-request fjernes passthrough-elementet fra SOAP-requestet inden det sendes videre ind mod NSP. Den netop beskrevne mekanisme muliggør, at NGW nu kan videresende et SOAP-request med ID-kort på ethvert niveau, uden intervention.

Der eksisterer en yderligere mulighed for passthrough af ID-kort på visse niveauer uden brug af <sosigw:PassThrough/> element. Denne mulighed er aktiv, hvis NGW er konfigureret til at lade SOAP-request med et korrekt signeret ID-kort flyde igennem uændret. Da kravet her er et signeret ID-kort vil denne mulighed kun være tilgængelig med SOAP-requests indeholdende et ID-kort på niveau 3 eller 4. Anvender bør i dette tilfælde allerede være informeret om, at passthrough-modellen uden SOAP-header element er aktiveret på NGW.

3.4. Sign On

Som en konsekvens af at klientprogrammer er relateret til NGW gennem deres egne backends, som er placeret udenfor SDN, giver det kun mening at udføre explicit sign on på NGW. Årsagen til dette er, at den adresse-information der returneres fra NGW ved implicit sign on, som skal bruges til at kontakte NGW mhp. signering af ID-kort er ubrugelig for klientprogrammer, da disse er på et andet netværk.


4. Kodeeksempler

Da der deles store dele af SOSI-GW med NGW kan et par kodeeksempler til SOSI-GW også bruges til at forstå, hvilken fremgangsmåde der kan benyttes på NGW. Navnlig kan eksemplerne explicitProxyExampleWithJAXWS og explicitProxyExampleWithJAXBAndDOM i guiden til SOSI-GW benyttes. Disse kan med lille indsats modificeres til at benytte HTTPS, indsætte de nødvendige HTTP-headers, m.v.


5. Referencer

Det kan være en fordel at kende til SOSI-GW kodebasen, som NGW er en specialisering af. Denne findes offentlig tilgængelig her:

Kode-repository indeholder bl.a. service interface beskrivelser. Samme sted findes også projektets dokumentation fra komponentleverandøren, på samme niveau i repository, som koden.


Til brug for opbygning af bl.a. ID-kort og parsning af dette findes Seal.Java og Seal.Net bibliotekerne. De respektive repository-baser findes her:

Herunder findes også komponentleverandørens dokumentation. Der skal gøres opmærksom på at der i foråret 2016 er igangsat et moderniseringsprojekt på Seal.NET, hvor dette projekt forventeligt ændres radikalt og bringes på niveau med Seal.Java både hvad angår funktionalitet, modernitet og dokumentation. Befinder man sig på en ældre version af .NET (<= 3.5) bør man have rigtig gode grunde til at lade være med at integrere med den kommende udgave af Seal.NET. Denne vil sandsynligvis blive baseret på .NET 4.5 eller 4.6. Er man ny anvender kan det betale sig at vente på færdiggørelsen af næste version af Seal.NET.


5.1. Endpoints

Der eksisterer en række endpoint til brug for bl.a. test:

Ligeledes findes samlingen af interface beskrivelser her:






  • No labels