Indledning

Nærværende dokument indledes med en kort overordnet beskrivelse af, i hvilken kontekst SOSI Gateway (SOSI-GW) indgår på NSP-platformen.
I resten af dokumentet beskrives design og arkitektur Arkitektur for SOSI-GW komponenten.Intern arkitektur
Tilstandsdeling imellem clustermedlemmer
Versionsstyring af delte data
Konfiguration
Administrationskonsol
Logning
Samtidighed
Load balancing
Afvikling på en enkelt maskine
Anvendte teknologier og komponenter
Webservice API
Oversigt over metoder tilgængelige som webservices
Proxyservice
Håndtering af implicit Id-kort oprettelse ved proxy-requests
requestIdCardDigestForSigning
signIdCard
getValidIdCard
logout
Tilgang til services til at håndtere ID-Kort
HTTP API

Anchor

...

Nærværende dokument indledes med en kort overordnet beskrivelse af, i hvilken kontekst SOSI Gateway (SOSI-GW) indgår på NSP-platformen.
I resten af dokumentet beskrives design og arkitektur for SOSI-GW komponenten.

Anchor
_

...

Toc13650

_Toc13650 _Toc13650

NSP-platformen – Kontekst for SOSI-GW

Sikkerhedsmodellen omkring kald til NSP services er baseret på Den Gode Webservice (DGWS), hvilket indebærer at der skal findes en SOAP-header med et signeret SOSI id-kort, sikkerhedsniveau 4.
Hvis anvendersystemer skulle kalde en NSP service direkte, ville alle anvendersystemer dermed være nødt til at håndtere signering af SOSI id-kort, hvilket kan være komplekst.
Det er her SOSI-GW kommer ind i billedet. I stedet for at alle anvendersystemer kalder NSP service endpoints direkte, kaldes i stedet igennem en central SOSI-GW kaldet "NSP Gateway". Signering af SOSI idkort og viderestilling til konkrete endpoints håndteres dermed kun ét sted.

NSP arkitekturen består, udover SOSI-GW, af et antal øvrige komponenter. Figur 1 illustrerer i hvilken kontekst SOSI-GW er placeret på den centrale NSP platform (SSL variant af cNSP):

Figur 1: SOSI-GW kontekst på NSP platform Komponenterne i arkitekturen er følgende:

...

Den grundlæggende arkitektur for SOSI-GW 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.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-79f8e2e2-697f-48d4-a9e5-26c11ec8fad5.html" name="test" height="640" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

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.
Hver server vil være bestykket med en servlet container (NSP benytter JBoss 6 og Wildfly 8.2) samt en lokal MySQL database server. Den lokale database anvendes udelukkende til at opsamle log-entries samt til lokal konfiguration. En knude i nettet kræver at begge komponenter (servlet container og database server) er kørende for at være funktionelle.
Til opsamling og søgning på audit logs opstilles en log-merger server, som ligeledes er bestykket med en lokal MySQL database.

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.
Hver server vil være bestykket med en servlet container (NSP benytter JBoss 6 og Wildfly 8.2) samt en lokal MySQL database server. Den lokale database anvendes udelukkende til at opsamle log-entries samt til lokal konfiguration. En knude i nettet kræver at begge komponenter (servlet container og database server) er kørende for at være funktionelle.
Til opsamling og søgning på audit logs opstilles en log-merger server, som ligeledes er bestykket med en lokal MySQL database.
Figur 2 nedenfor skitserer SOSI-GW løsningen bestående af et antal gateway servere (sosi-gw1, … sosi-gw3) og en central database til opsamling og fletning af audit logs (log-merger).

Figur 2: Cluster med tre SOSI-GW servere.

...

Image Removed
Figur 3: SOSI-GW intern arkitektur
Figur 3 viser den interne Figur 3 viser den interne arkitektur i SOSI-GW. Løsningen består af en kerne, der anvender SOSISeal til at håndtere id-kort. Id-kort distribueres over en fælles cache, der drives af multicasting på lokalnettet.
Konfiguration og logning gemmes i en lokal JDBC database. Ovenpå kernen ligger tre snitflader, nemlig webservices (JAX-WS), http til browserbaseret signering samt GWT (Google Web Toolkit) til administration.

Anchor
_Toc13652 _Toc13652

Intern arkitektur

Image Added
Figur 3: SOSI-GW intern arkitektur

Anchor
_Toc13653 _Toc13653

Tilstandsdeling imellem clustermedlemmer

De servere, der indgår i et cluster, kommunikerer indbyrdes via et distribueret, delt hukommelseområde, realiseret via UDP multicast på lokalnettet. Herigennem overføres løbende opdateringer i form af oprettelse, opdatering og nedlæggelse af id-kort.
Udover id-kort, bruges clusteret også til at synkronisere konfigurationsændringer, der er foretaget igennem administrationskonsollen.
Multicast benyttes endvidere som discovery mekanisme, dvs. som måden hvorpå clustermedlemmer fastlægger hvilke øvrige medlemmer clusteret indeholder på et givet tidspunkt. Dette betyder, at der ikke er behov for manuel konfiguration i forbindelse med at en server tilføjes eller fjernes.

...

med at en server tilføjes eller fjernes.

Anchor
_Toc13654 _Toc13654

Versionsstyring af delte data

Som led i understøttelsen af rullende opgraderinger, påhæftes alle delte datatyper, dvs id-kort og dynamisk konfiguration, et versionsnummer.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/ff381ec5-2fe4-48f7-b856-8033b0cba54e.html" name="test" height="520" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Som led i understøttelsen af rullende opgraderinger, påhæftes alle delte datatyper, dvs id-kort og dynamisk konfiguration, et versionsnummer. Software-opgraderinger, der involverer modifikationer af de delte datatyper, 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.
Der understøttes kun det aktuelle og det forrige format. Ved en forskel på mere end ét versionsnummer af beskedformatet, kan der ikke kommunikeres. Ved opstart undersøger en server om beskeder afsendt af andre servere er i et af de to understøttede formater. Hvis dette ikke er tilfældet afbrydes opstarten.

...

• Når et id-kort er ved at blive signeret af en bruger gennem browserbaseret 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 at 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 skalerbarhed. 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 timeoutniveau (i DGWS termer). Nogle services kræver f.eks. at id-kort er underskrevet for hvert request, og denne situation skal håndteres i klienten. Klienten er derfor nødt til at kunne afgøre, om id-kortet er for gammelt til at kunne bruges. Dette kan afgøres ved at benytte getValidIdCard, der returnerer brugerens id-kort.

...