Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Anchor | ||||
|---|---|---|---|---|
|
Indledning
Nærværende dokument indledes med en kort overordnet beskrivelse af, i hvilken kontekst SOSI -Gateway
Design og arkitektur
Indhold
Indledning
Gateway (SOSI-GW) indgår på NSP-platformen – Kontekst for SOSI-GW
Arkitektur .
I resten af dokumentet beskrives design og 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
Version | Dato | Beskrivelse | Forfatter |
1 | 21-06-2016 | Første version, udarbejdet med udgangspunkt i Arkitektur og design for SOSIGW 1.0 | OBJ |
...
| Table of Contents |
|---|
Version | Dato | Beskrivelse | Forfatter |
1 | 21-06-2016 | Første version, udarbejdet med udgangspunkt i Arkitektur og design for SOSIGW 1.0 | OBJ |
| Anchor | ||||
|---|---|---|---|---|
|
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:
Netværkskomponent Anvendersystemets kald til NSP går i praksis til en netværkskomponent, som kaldes via HTTPS. Denne komponent validerer kaldet og det medsendte FOCESklientcertifikat i forhold til en whitelist. Kun godkendte forespørgsler sendes videre herfra til SOSI-GW.
Security Token Service Når et id-kort skal signeres med føderationens certifikat, kalder SOSI-GW STS'en. Herefter indsætter SOSI-GW id-kortet i en cache. Ved efterfølgende kald fra
anvendersystemet erstattes det medsendte id-kort med det signerede id-kort fra cachen, inden viderestilling til den relevante NSP service Hvis anvendersystemet har angivet Passthrough header, eller der sendes et id-kort med sikkerhedsniveau > 1, foretages ingen erstatning. .
Afkoblingskomponent Som udgangspunkt kaldes der videre til den relevante NSP service igennem en afkoblingskomponent kaldet DCC (Decoupling Component).
Afkoblingskomponenten vil ud fra beskedens SOAP action afgøre hvilket konkret endpoint, der skal kaldes.
NSP services Den konkrete NSP service vil oftest blive kaldt igennem DCC. Det er dog muligt for
anvendersystemet at specificere den ønskede endpoint-URL selv i et tag'et "To" i SOAP-headeren WSAddressing. Hvis dette er tilfældet vil SOSI-GW kalde det specificerede endpoint udenom DCC.
Såfremt SOSI-GW placeres efter DCC i stedet for før, vil DCC tilføje en WsAddressing SOAP-header med "To" udfyldt. SOSI-GW vil i dette tilfælde derfor altid kalde NSP service endpoint direkte. Et sådant setup anvendes decentralt i regionerne.
For yderligere information om, hvorledes SOSI-GW indgår i NSP platformen, henvises til dokumentet "SOSIGW Guide til anvendere".
| Anchor | ||||
|---|---|---|---|---|
|
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.
| HTML |
|---|
<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.
...
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:
Netværkskomponent Anvendersystemets kald til NSP går i praksis til en netværkskomponent, som kaldes via HTTPS. Denne komponent validerer kaldet og det medsendte FOCESklientcertifikat i forhold til en whitelist. Kun godkendte forespørgsler sendes videre herfra til SOSI-GW.
Security Token Service Når et id-kort skal signeres med føderationens certifikat, kalder SOSI-GW STS'en. Herefter indsætter SOSI-GW id-kortet i en cache. Ved efterfølgende kald fra
anvendersystemet erstattes det medsendte id-kort med det signerede id-kort fra cachen, inden viderestilling til den relevante NSP service Hvis anvendersystemet har angivet Passthrough header, eller der sendes et id-kort med sikkerhedsniveau > 1, foretages ingen erstatning. .
Afkoblingskomponent Som udgangspunkt kaldes der videre til den relevante NSP service igennem en afkoblingskomponent kaldet DCC (Decoupling Component).
Afkoblingskomponenten vil ud fra beskedens SOAP action afgøre hvilket konkret endpoint, der skal kaldes.
NSP services Den konkrete NSP service vil oftest blive kaldt igennem DCC. Det er dog muligt for
anvendersystemet at specificere den ønskede endpoint-URL selv i et tag'et "To" i SOAP-headeren WSAddressing. Hvis dette er tilfældet vil SOSI-GW kalde det specificerede endpoint udenom DCC.
Såfremt SOSI-GW placeres efter DCC i stedet for før, vil DCC tilføje en WsAddressing SOAP-header med "To" udfyldt. SOSI-GW vil i dette tilfælde derfor altid kalde NSP service endpoint direkte. Et sådant setup anvendes decentralt i regionerne.
For yderligere information om, hvorledes SOSI-GW indgår i NSP platformen, henvises til dokumentet "SOSIGW Guide til anvendere".
...
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 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.
...
Figur 3 : SOSI-GW intern arkitektur
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 | ||
|---|---|---|
|
...
|
Figur 3: SOSI-GW intern arkitektur
| Anchor | ||||
|---|---|---|---|---|
|
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 | ||||
|---|---|---|---|---|
|
Som led i understøttelsen af rullende opgraderinger, påhæftes alle delte datatyper, dvs id-kort og dynamisk konfiguration, et versionsnummer.
| HTML |
|---|
<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.
...
SOSI-GW's primære funktionalitet stilles til rådighed gennem Webservices. Funktionaliteten er delt op i to dele: Services til at håndtere id-kort (oprette, signere og nedlægge) og en proxyservice.
Proxyservicen er et generisk endpoint, der står for at videresende requests fra en klient til et andet endpoint mens der også tilføjes et signeret id-kort. Når proxyservicen anvendes, foretages der ikke nogen validering af SOAPbody, og ligeledes checkes headeren kun for felter, der er nødvendige for at SOSI-GW kan fungere.
Alle services bygger på den allerede definerede form for id-kort fra DGWS, hvilket betyder, at data sendes som SAMLassertions. Ved samtlige kald til SOSI-GW, checkes om kalderen, identificeret ved en IP-adresse og en shared secret, har adgang til at benytte SOSI-GW. Der benyttes altså kun standarder, der allerede er i anvendelse (WSAddressing, SAML m.v.).
| Anchor | ||||
|---|---|---|---|---|
|
...
- Unikt brugerid i form af en SAMLassertion med <saml:NameID>
- WSAddressing headers i henhold til http://www.w3.org/Submission/wsaddressing/ Et optionelt id-kort. Dette fjernes inden dispatch og erstattes evt. af det cachede kort.
Returværdier:
- "200" (OK) på HTTP niveau, og som indhold det uændrede svar fra den ønskede service.
- "500" (Error) på HTTP niveau, hvilket kan skyldes:
- Den ønskede service returnerede denne fejl.
- Den ønskede service er ikke konfigureret på listen over kendte endpoints.
- Manglende eller ugyldige argumenter i SOAPheaderne, f.eks. manglende WSaddressing. Der findes ikke et gyldigt signeret Id-kort i SOSI-GW.
...
Denne benyttes til eksplicit oprettelse af et id-kort, klar til signering. Servicen kaldes af en klient for at etablere en session for en bruger, så der kan sendes signerede requests til andre services.
Servicen kræver et partielt id-kort, som SOSI-GW skal opbevare i signeret tilstand. I SOAPbody sendes derfor en SAMLassertion med samme indhold som for implicit oprettelse. Servicen returnerer den digestværdi som klienten skal signere sammen med en URL, der kan anvendes af en browser. Der skelnes ikke mellem URLrequests og WSrequests.
Usignerede id-kort fjernes automatisk fra serverne hvis der ikke er modtaget en signeret digest inden et vist interval. Dette interval er konfigurerbart.
| Anchor | ||||
|---|---|---|---|---|
|
Denne metode benyttes til at tilføje et signeret digest til det cachede idkort i SOSI-GW. Argumenter til dette kald er NameID, SignatureValue og brugerens offentlige nøgle. SOSI-GW lader herefter STS'en signere id-kortet, checker at signaturen er gyldig, og gemmer det i sin cache.
| Anchor | ||||
|---|---|---|---|---|
|
...
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 | ||||
|---|---|---|---|---|
|
Denne metode fjerner det signerede id-kort for en bestemt bruger. Som argument kræves NameID.
| Anchor | ||||
|---|---|---|---|---|
|
Der er udstillet to snitflader til at tilgå id-kort, begge som webservices. Den ene service udstiller den fulde funktionalitet, og kan passende beskyttes, så den kun kan tilgås fra bestemte fagsystemer.
Den anden webservice udstiller kun håndtagene requestIdCardForSigning og SignIDCard. Denne webservice er lavet, så disse håndtag kan udstilles til at bredere publikum, eksempelvis gennem SignOn Biblioteket.
| Anchor | ||||
|---|---|---|---|---|
|
...