Denne note er rettet mod personer der skal forstå hvorledes forespørgsler mod STS behandles i relation til diagnosticering af support henvendelser. Noten forventes at skulle udvides eller suppleres af andet dokument, som adresserer behov for både indkommende support henvendelser samt support ved tilslutning af eksempelvis lægepraksissystemer.
Ved behandling af en forespørgsel om udstedelse af ID-kort hos en STS gennemgås en række skridt. Forløbet er skitseret forsimplet nedenfor, med de skridt der har primær relevans i forhold til diagnosticering af udstedelse. Hvert skridt kan føre til en afvisning af forespørgslen, mens succesfuld verifikation leder til signering og dermed udstedelse af et ID-kort.
![]()
Ved succesfuld udstedelse af et STS signeret ID-kort returneres et SOAP svar fra STS indeholdende relevante ID-kort attributter (SAML assertions), dvs. både verificerede (f.eks CVR) og berigede (f.eks. CPR), samt øvrig information jævnfør DGWS.
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope ...> <soapenv:Header> <wsse:Security id="AAABL0ncNMXd26QUzOR4JlNPU0k="> <wsu:Timestamp> <wsu:Created>2011-04-12T15:17:41</wsu:Created> </wsu:Timestamp> </wsse:Security> </soapenv:Header> <soapenv:Body> <wst:RequestSecurityTokenResponse Context="www.sosi.dk"> <wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion:</wst:TokenType> <wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken> <wst:Status> <wst:Code>http://schemas.xmlsoap.org/ws/2005/02/trust/status/valid</wst:Code> </wst:Status> <wst:Issuer> <wsa:Address>TESTSTS</wsa:Address> </wst:Issuer> </wst:RequestSecurityTokenResponse> </soapenv:Body> </soapenv:Envelope> |
Ovenstående eksempel viser en del af et svar indeholdende et STS signeret ID-kort. I eksemplet er namespace erklæringer samt alle ID-kort attributter fjernet af hensyn til overskuelighed. Vigtige elementer ved diagnosticering er:
På tilsvarende vis leverer en STS ved afvist forespørgsel et SOAP svar (Fault) indeholdende yderligere information om fejlen.
Nedenstående eksempel viser (igen uden namespace erklæringer) elementerne i svaret der bruges i forbindelse med diagnosticering:
Det er kombinationen af faultcode, faultactor og faultstring som identificerer fejlen, hvor faultstring typisk indeholder den nødvendige information for nærmere fejlsøgning.
Faultcode værdier skal ikke betragtes som entydige fejlkoder, men skal ses i sammenhæng og bør betragtes som en gruppering af de fejltyper der kan opstå ved behandling af kald til tjenester på en STS:
Faultactor værdier
Eksempel på afvist forespørgsel
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope ...> <soapenv:Header> <wsse:Security id=""> <wsu:Timestamp> <wsu:Created>2011-04-12T15:17:39</wsu:Created> </wsu:Timestamp> </wsse:Security> </soapenv:Header> <soapenv:Body> <soapenv:Fault> <faultcode>wst:InvalidRequest</faultcode> <faultstring>The request was invalid or malformed</faultstring> <faultactor>dk:sosi:sts</faultactor> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> |
Ved nogle fejl kan faultstring indeholde dynamiske informationer som f.eks. autorisationskoder mv. Disse informationer kan anvendes af det kaldende system hvis systemet ikke selv har mulighed for at slå informationerne op i f.eks. Stamdata komponenten.
Det skal bemærkes at en fremtidig opdatering ef DGWS eller en overgang til en anden standard kan betyde at disse informationer ikke længere er inkluderet i faultstring.
De følgende afsnit beskriver en delmængde af de fejlsituationer, man som anvender kan komme ud for i forbindelse med udstedelse af ID-kort mod en STS. Beskrivelserne består af:
I forbindelse med fejlsøgning sammenholdes den konkrete SOAP fejl med de beskrevne STS svar ved hjælp af faultcode, faultactor og faultstring.