Page History
...
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 |
...
- 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.
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å 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 | ||||
|---|---|---|---|---|
|
...