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
_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

...

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.

...

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. 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

<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.

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 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.

...

i forbindelse 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.

...

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 fordel 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 dette i visse tilfælde kan betragtes som et brud på sikkerhedenen 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 fordel 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 dette i visse tilfælde kan betragtes som et brud på sikkerheden.

createIdCardFromBST

Denne metode omveksler et bootstrap token til et id-kort.

Input er en omvekslingsbesked med indlejret bootstraptoken, som viderestilles i uforandret form til SOSI-STS’ens BST2SOSI snitflade. Se evt. STS anvenderdokumentationen for mere information om denne.

Det resulterende idkort gemmes i idkort-cachen og returneres (uden signaturer).

Idkortet in cachen er signeret og kan derfor benyttes af proxyservicen.

Fejlbeskeder fra STS'en videregives uforandret til brugeren af denne service.

Anchor
_Toc13669 _Toc13669

logout

...