Page History
Navitabs | ||||
---|---|---|---|---|
| ||||
Bemærk: Nedenstående sider kræver login.
Denne "Kom Godt i Gang Guide" omhandler brug af SOSI Gateway. Guiden er beregnet til it-faglige personer som skal til eller er i gang med at udvikle systemer, der skal integrere med NSP. Det anbefales at Platformsintroduktion og STS - Signering læses inden denne guide.
Bemærk: Nedenstående sider kræver login.
...
SOSI-GW - Design- og arkitekturbeskrivelse
...
...
Guide til anvendere: DGWS læses inden denne guide.
Table of Contents |
---|
Numbered Headings | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Release notesRelease 2.0.7
Release 2.0.6
Release 2.0.5 Rettelser til integrationstests
Release 2.0.4
Release 2.0.3
Release 2.0.2
Release 2.0.1
I konfigurationsfilen sosigw-staticconf.properties, skal sts url(er) i property runtimeconfig.general.sts.service.url ikke længere slutte på /SecurityTokenService. Release 2.0.0
Introduktion til SOSI |
...
Table of Contents |
---|
Numbered Headings | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
GatewaySOSI Gateway er en cache af aktive id-kort signeret af STS'en, samt en proxy som erstatter usignerede id-kort i forespørgelserne med disse aktive id-kort. I stedet for at en bruger bliver afkrævet at taste koden til sit medarbejdercertifikat i alle de systemer som vedkommende skal anvende i løbet af dagen, så kan SOSI Gateway tilbyde, at det kun er ved anvendelse af det første system hver dag, at certifikatet skal anvendes. Hvis alle systemerne anvender SOSI Gateway korrekt vil der blive lagt et signeret id-kort i cachen ved første anmodning, og herefter vil dette id-kort blive brugt i alle andre forespørgelser. Dette sker ved at systemerne sender et usigneret id-kort med en identifikation af brugeren med i alle forespørgelser, SOSI Gateway erstatter dette id-kort med det passende fra cachen. Identifikationen af brugeren sker ved brug af dennes personnummer og betyder at ansvaret for at det korrekte id-kort bliver anvendt flyttes ud til slutsystemerne. SOSI Gateway er kun ment som en proxy for forespørgelser, der kræver bruger-id-kort signeret med et MOCES certifikat. VOCES og FOCES certifikater kan ikke bruges sammen med SOSI Gateway.
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen. AnvendelseI dette afsnit findes en kort oversigt over de skridt et system skal tage for at anvende SOSI Gateway. I de følgende hovedafsnit vil hvert skridt i anvendelsen af SOSI Gateway blive gennemgået i detaljer.
AdgangSOSI Gateway er tilgængelig på alle NSP installationer. På cNSP fungerer SOSI Gateway som Kommunernes Gateway og er sat op foran DCC. På dNSP installationer er SOSI Gateway placeret efter DCC. Der er i praksis ingen adgangskrav til SOSI Gateway, men det er dog muligt for operatøren at konfigurere en whitelistning i fremtiden. Explicit loginFørste gang en bruger har brug for at tilgå en service på NSP, laver systemet et opslag i SOSI Gateway, for at se om der allerede ligger et aktivt id-kort i cachen. Dette opslag udføres med operationen " Hvis der ikke ligger et aktivt id-kort i cachen bygges der et nyt usigneret id-kort efter reglerne beskrevet i guiden STS - Signering, og dette sendes til SOSI Gateway via operationen " Hvis der allerede ligger et aktivt id-kort i cachen, så kan proxy servicen bruges direkte og slutbrugeren behøves ikke tillade adgang til sin private nøgle, da der ikke skal underskrives et nyt id-kort. Implicit loginEn alternativ måde at anvende SOSI Gateway er ved blot at kalde gennem proxien og så reagere på den Match id-kortI alle de fleste kald til SOSI Gateway skal der gives et usigneret id-kort med i SOAP Headeren. Elementet
Hvis en bruger har flere autorisationer (og derved kan have flere aktive id-kort) kan det være nødvendigt at anvende en kombineret nøgle til Ud over at bruge IdentitetsserviceSOSI Gateway fungerer som en cache af id-kort og tilbyder derfor operationer til at få udstedt et id-kort via STS'en. I de følgende underafsnit vil disse operationer blive gennemgået. Identitetsservicen i SOSI Gateway er tilgængelig på adressen getValidIdCardDenne operation finder et id-kort i cachen, der matcher det NameId der findes i SOAP Headeren i forespørgelsen. Hvis der findes et aktivt id-kort returneres dette som en SAML Assertion. En af anvendelsesmulighederne med resultatet af denne operation er at undersøge hvor lang tid der er til et aktivt id-kort udløber. Bemærk at det kun er SAML elementer der returneres, alle XML Signature elementer er fjernet fra resultatet. requestIdCardDigestForSigningDenne operation erstatter et eventuelt tidligere id-kort i cachen med det usignerede id-kort i forespørgelsen. Derefter laves en SHA-1 digest af id-kortet som sendes retur til anvenderen. Ud over en digest sender SOSI Gateway også en URL til en webside hvor en Java Applet kan anvendes til at signere id-kortet. Hvis denne løsning vælges skal anvendersystemet ikke kalde " signIdCardDen digest, som blev dannet af SOSI Gateway ved kaldet til " Det usignerede id-kort i cachen kombineres nu med signaturen og certifikatet og sendes til STS, der ombytter det med et id-kort der er signeret med føderationens certifikat. Dette id-kort lægges nu i cachen og er klar til at blive brugt igennem proxyservicen. createIdCardFromBSTAnvendes til omveksling af et bootstrap token til et idkort. Det resulterende idkort gemmes i idkort-cachen med det indgående bootstraptokens SubjectNameID som nøgle, medmindre der i det indkommende kald er angivet et ”sosi:SubjectNameID” claim. Idkortet returneres med alle XML Signature elementer fjernet. logoutDenne operation fjerner slutbrugerens id-kort fra SOSI Gateway cachen.ProxyserviceProxyservicen i SOSI Gateway fungerer stort set som en helt normal proxy, bortset fra at den udskifter det usignerede id-kort i forespørgelsen med et STS signeret id-kort fra cachen. Følgende underafsnit er en gennemgang af de vigtige detaljer i den behandling af forespørgelsen som proxien foretager, herunder hvordan den endelige webservice identificeres. Proxyservicen i SOSI Gateway er tilgængelig på adressen Udskiftning af id-kortHvis anvenderen ikke ønsker at få udskiftet id-kortet i forespørgelsen kan dette angives med SOAP headeren " Som beskrevet tidligere så vil SOSI Gateway returnere en Identifikation af webserviceSOSI Gateway anvender et subset af WS-Addressing til at identificere den webservice, der skal kaldes gennem proxien. Følgende elementer fra WS-Addressing læses i SOAP headeren:
Forespørgelse mod webserviceNår SOSI Gateway har identificeret den webservice, som forespørgelsen skal sendes til, sendes forespørgelsen dertil og svaret sendes uændret retur til anvendersystemet. EksemplerTil denne guide hører et kodeeksempel der viser hvordan man kan få lagt et id-kort i cachen, og hvordan man kalder gennem proxy servicen. Eksemplerne kan hentes via Subversion på følgende adresse: Eksemplerne er lavet som et Maven projekt med et fælles modul og et modul for hver guide. Eksemplerne til denne guide ligger i modulet GW og hedder IdCardCacheExample.java. Klasserne er lavet som unittests og kan afvikles direkte i en hvilken som helst IDE der understøtter JUnit 4. Eksemplerne har indlejret en WSDL fil som anvendes af JAX-WS/JAXB til at generere XML entiteter og service stubbe. Den aktuelle WSDL kan altid hentes på adressen https://wsdl.nspop.dk/sosigw/service/sosigw?wsdl eller sammen med koden på adressen https://svn.nspop.dk/public/components/sosi-gw/latest/code/etc/wsdl/sosigw.wsdl TestdataI modulet common ligger et antal Java Keystore filer der hver indeholder et enkelt certifikat. I eksemplerne til denne guide anvendes kun et enkelt af disse certifikater:
IdCardCacheExampleEksemplerne i denne fil gennemgår de anvendelsesmuligheder som SOSI Gateway stiller til rådighed. Eksemplerne findes i to versioner: en hvor JAX-WS service snitflader anvendes og en hvor JAXB og DOM objekter serialiseres til en streng og sendes som et HTTP requests. Alle metoderne har indlejrede kommentarer som forklarer hvert skridt i eksemplet. authorizationExampleWithJAXWS og authorizationExampleWithJAXBAndDOM I disse eksempler lægges der et id-kort i SOSI Gateway cachen. Først bygges et nyt usigneret id-kort med slutbrugerens personnummer som NameId. Dette id-kort sendes med i alle forespørgelser mod SOSI Gateway da NameId identificere slutbrugeren. explicitProxyExampleWithJAXWS og explicitProxyExampleWithJAXBAndDOM I disse eksempler lægges der først et id-kort i cachen hvorefter en service på en NSP komponent kaldes. Kaldet til servicen går gennem SOSI Gateway og indeholder et usigneret id-kort med samme NameId som det id-kort der blev lagt i cachen. SOSI Gateway proxy servicen sørger for at bytte det usignerede id-kort ud med et STS signeret id-kort. implicitProxyExampleWithJAXWS og implicitProxyExampleWithJAXBAndDOM I disse eksempler kaldes en service direkte gennem SOSI Gateway uden først at logge ind. Den fejl der kommer tilbage anvendes så til at få lagt et id-kort i cachen og servicen kaldes herefter igen. |
...