Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Anchor | ||||
|---|---|---|---|---|
|
SOSI-Gateway
Design og arkitektur
Indhold
Indledning
NSP-platformen – Kontekst for SOSI-GW
Arkitektur for SOSI-GW
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 |
| 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. 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.
| Anchor | ||||
|---|---|---|---|---|
|
...
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 | ||||
|---|---|---|---|---|
|
...
- 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.
| Wiki Markup |
|---|
\\
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.
...
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 | ||||
|---|---|---|---|---|
|
...