STS Anvenderdokument i. STS Anvenderdokument

Størrelse: px
Starte visningen fra side:

Download "STS Anvenderdokument i. STS Anvenderdokument"

Transkript

1 i STS Anvenderdokument

2 ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME N

3 iii Indhold 1 Introduktion Målgruppen Snitflader Arkitektur overblik STS-signering af id-kort Snitflade Struktur af forespørgsel og svar Behandlingen af en forespørgsel om signering af id-kort Check id-kort Check certifikat Check systemoplysninger Check brugeroplysninger Signér id-kort Billetomveksling: id-kort til OIOIDWSH-token Snitflade Behandling af forespørgsel om veksling af id-kort til OIOIDWS-H token Check om id-kort er af bruger-type Check om id-kort er gyldig i tid Check om id-kort er gyldig ifht. audience Fremstil token Billetomveksling: OIOSAML assertion til id-kort Snitflade Struktur af forespørgsel og svar Behandling af forespørgsel Indhold af en OIOSAML assertion Billetomveksling: id-kort til OIOSAML assertion Snitflade Struktur af forespørgsel og svar Normalisering af audience Behandling af forespørgsel Konfiguration Referencer 12 A STS 1.1 til 1.3 migrering 12 B STS 1.3 til 2.0 migrering 13 C STS 2.0 til 2.1 migrering 13

4 1 / 13 1 Introduktion Nærværende dokument henvender sig til nuværende og kommende anvendere af STS (Security Token Service), ITS (Identity Token Service) samt OIOSAML Billetomveksling og formålet med dokumentet er, at give hjælp til disse i arbejdet med integration mod STS og ITS. Dette sker ved en overordnet gennemgang af de udstillede services og beskrivelse af specifikke elementer, der er væsentlige for at opnå en basal forståelse på anvenderniveau. Gennemgangen kan være understøttet af ekstern dokumentation. STS og relaterede services udstilles som webservices og i produktion altid på sundhedsdatanettet, hvilket kræver separat tilslutning. 1.1 Målgruppen En typisk anvender af STS eller ITS, som kan drage nytte af dette dokument er karakteriseret ved eksempelvis, at være leverandør af et lægepraksissystem eller leverandør af et fagsystem implementeret på et hospital, f.eks. et laboratoriesystem eller et medicineringssystem. Id-kort spiller en central rolle for single-signon scenariet, der understøttes af STS, og det er en absolut nødvendighed med en god forståelse af begreberne for at arbejde med STS. Id-kortet anvendes ifm. autentifikation og autorisation af en bruger, der opererer på sundhedsdatanettet via en serviceaftager. Specifikationen af DGWS [A3] har en god og uddybende beskrivelse af, hvordan et id-kort er konstrueret og kan anvendes i praksis. 1.2 Snitflader STS indeholder i alt 5 snitflader som beskrives nedenfor: Adresse Sikkerhedsniveau Beskrivelse /sts/services/securitytokenservice Niveau 3-4 STS-signering af id-kort. Benyt NewSecurityTokenService hvis muligt. /sts/services/newsecuritytokenservice Niveau 3-4 STS-signering af id-kort. Erstatter samtidig NameId til et kanonisk format (nødvendigt hvis id-kortet skal veksles til OIOSaml). /sts/services/identitytokenservice Niveau 4 (MOCES) Ombytter STS-signeret id-kort til OIOIDWS-H token rettet mod et specifikt audience /sts/services/sosi2oiosaml Niveau 4 (MOCES) Ombytter STS-signeret id-kort til OIOSaml-token rettet mod et specifikt audience, f.eks. sundhed.dk /sts/services/oiosaml2sosi Niveau 5 Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart hvor sikkerhedsniveauerne er som angivet i Den Gode Webservice. Anvenderes tilgang til STS vil ofte være med hjælp fra Seal.Java [A2] eller Seal.NET [A3], som er biblioteker der bl.a. hjælper til med at understøtte brugen af DGWS [A4] og håndtere sikkerhedsaspekterne. Der eksisterer fyldig dokumentation for begge offentliggjorte biblioteker med beskrivelser af anvendelsen af disse. En tredje mulighed er en proprietær løsning mod STS, hvor kaldet skal overholde DGWS. Indirekte tilgang er også mulig gennem SOSI-DCC eller SOSI-GW [A5], men det dokumenteres ikke her. Bemærk at der kan være yderligere sikkerhedschecks udført af NSP-platformen, f.eks. whitelisting af CVR numre. Dette dokumenteres ikke her.

5 2 / Arkitektur overblik Figur 1: STS afhængigheder og eksterne snitflader STS leverede signerede id-kort og omvekslinger af disse. Hertil benyttes et mindre antal eksterne services til verifikation af oplysnigner i id-kort, herunder signatur, cpr-nummer og autorisationsoplysninger. Endvidere benyttes et keystore indeholdende både STS ens egen nøgle (til signering), samt et antal trustede certifikater (til brug for billetomveksling). 2 STS-signering af id-kort Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services indenfor en føderation [A1] på sundhedsdatanettet. I dette afsnit beskrives de væsentlige faser, som eksisterer ifbm. behandlingen af en forespørgsel til STS. Undervejs vil de væsentlige begreber og elementer, der indgår i en forespørgsel være forklaret. Der henvises endvidere til yderligere dokumentation, hvor det er relevant, så helheden og meningen fremgår. 2.1 Snitflade Anvenderes tilgang til STS vil typisk være med hjælp fra Seal.Java [A2] eller Seal.NET [A3], som er biblioteker der bl.a. hjælper til med at understøtte brugen af DGWS [A4] og håndtere sikkerhedsaspekterne.

6 3 / 13 Et eksempel på hvordan et kald konstrueres med Seal.Java findes i SOSI Programmers Guide ([A2]) under "Use case 1: How to authenticate an ID-card". Afhængig af miljø udstilles tjenesten på: 2.2 Struktur af forespørgsel og svar Der findes ingen offentliggjort wsdl for STS. Det anbefales at kalde via Seal.Java eller Seal.NET som begge stiller API-er til rådighed til at danne velstrukturerede forespørgsler og fortolke svaret. Strukturen for et SOAP request med henblik på signering af id-kort er som følger <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header>... </soapenv:header> <soapenv:body> <wst:requestsecuritytoken Context="www.sosi.dk"> <wst:tokentype>urn:oasis:names:tc:saml:2.0:assertion:</wst:tokentype> <wst:requesttype>http://schemas.xmlsoap.org/ws/2005/02/trust/issue</wst:requesttype> <wst:claims> <saml:assertion IssueInstant=" T14:26:07Z" Version="2.0" id="idcard"> <!-- selv-signeret id-kort her --> </saml:assertion> </wst:claims> <wst:issuer> <wsa:address>thesosilibrary</wsa:address> </wst:issuer> </wst:requestsecuritytoken> </soapenv:body> </soapenv:envelope> Dette vil give anledning til et svar fra STS på formen: <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header>... </soapenv:header> <soapenv:body> <wst:requestsecuritytokenresponse Context="www.sosi.dk"> <wst:tokentype>urn:oasis:names:tc:saml:2.0:assertion:</wst:tokentype> <wst:requestedsecuritytoken> <saml:assertion IssueInstant=" T14:26:07Z" Version="2.0" id="idcard"> <!-- STS-signeret id-kort her --> </saml:assertion> </wst:requestedsecuritytoken> <wst:status> <wst:code>http://schemas.xmlsoap.org/ws/2005/02/trust/status/valid</wst:code> </wst:status> <wst:issuer> <wsa:address>test2-nsp-sts</wsa:address> </wst:issuer> </wst:requestsecuritytokenresponse> </soapenv:body> </soapenv:envelope>

7 4 / Behandlingen af en forespørgsel om signering af id-kort Her fokuseres på den forretningmæssige del, så dokumentation af den trivielle husholdning (serialisering m.m.) bag en forespørgsel er udeladt. Sekvensen er følgende: 1. Check id-kort 2. Check certifikat 3. Check systemoplysninger 4. Check brugeroplysninger 5. Signér id-kort Enhver af disse skridt i sekvensen kan resultere i en fejlsituation, hvorved videre normal processering af forespørgelsen ophører og der svares tilbage til kalder med en fejlbesked. For en mere detaljeret gennemgang af STS fejlsituationer henvises til [A10] Check id-kort Forretningslogikken er består af tre skridt, som på baggrund af id-kortet checker om: 1. Id-kortet er en understøttet version (vha. Seal-biblioteket) 2. Id-kortet er autentifikationsniveau niveau 3 (VOCES/FOCES) eller 4 (MOCES) 3. Id-kortet har korrekt udstedelsestidspunkt og varighed Check certifikat Anvendelsen af et OCES-certifikat er beskrevet i DGWS [A3]. Denne del af sekvensen handler om, at afgøre om OCEScertifikatet [A6] kan accepteres og om certifikatet er gyldigt i føderationen. I praksis undersøges et X.509 v3 certifikat i følgende trin: 1. Afgør om certifikatet er af typen VOCES/FOCES eller MOCES 2. Afgør om certifikatet er gyldigt på kaldstidspunktet 3. Afgør om certifikatet er af samme type som angivet på id-kortet 4. Afgør om certifikatet er tilbagetrukket 5. Afgør om certifikatet er gyldigt i føderationen, dvs. udstedt af samme CA Check systemoplysninger Dette skridt skal afgøre om CVR nummeret er det samme på id-kort og OCES-certifikat Check brugeroplysninger Udføres kun for MOCES-certifikater. Her afgøres om CVR nummeret, som angivet i MOCES-certifikatet, har en relation til brugerens CPR nummer, som angivet på id-kortet. I forbindelse med det spørges et, for STS, eksternt system om denne relation eksisterer. I det tilfælde, hvor brugerens CPR nummer på id-kortet mangler foretages et opslag i det eksterne system udelukkende på baggrund af MOCES-certifikatets oplysninger for at afgøre om en relation eksisterer. Verifikation af CPR Til check af CPR-nummer anvendes DanID s RID-CPR tjeneste, som med subject serial number fra et MOCES certifikat kan slå det tilhørende CPR op. I STS er der to scenarier:

8 5 / 13 a. Id-kort indeholder ikke CPR, hvilket betyder at STS slår CPR op og beriger id-kortet med det fundne. b. Id-kort indeholder CPR, hvorfor STS slår CPR op og bekræfter at de to matcher. Det antages at subject serial number er på formen CVR:xxxxxxxx-RID-yyyyyyyy hvor xxxxxxxx er det 8-cifrede cvr nummer, mens RID kan indeholde vilkårlige tekststrenge, dog uden mellemrum, plus (+) eller komma (,). Såfremt dette er tilfældet, ignoreres den sidste del. Eksempler: CVR: RID Her er er RID= CVR: RID Her er er RID= CVR: RID Her er er RID= Et MOCES signeret id-kort indeholder således altid et verificeret CPR-nummer. Verifikation af autorisation Check af autorisation benytter sig af autorisationsregisteret, og baserer sig på de autorisationsoplysninger der er udfyldt i id-kortet. Mere specifikt anvendes autorisations- og uddannelseskoden til at finde en matchende autorisation: a. Hvis der ikke findes en matchende autorisation sker en af følgende: 1. Hvis autorisationskoden er angivet i autorisationsoplysningerne og ikke er en tom streng, afvises id-kort udstedelsen. 2. Hvis uddannelseskoden er angivet i autorisationsoplysningerne og består af fire heltal, afvises id-kort udstedelsen. 3. Hvis autorisationskoden enten mangler eller er en tom streng og uddannelseskoden enten mangler eller ikke består af fire heltal, fortsættes udstedelsesprocessen. b. Hvis der findes én matchende autorisation beriges id-kortet med oplysningerne. c. Hvis mere end én autorisation findes afvises udstedelsen da en entydig autorisation ikke kan afgøres. En autorisation i autorisationsregisteret matcher autorisationsoplysningerne på id-kortet hvis følgende punkter er opfyldt: a. Autorisationskoden på id-kortet er ikke udfyldt, eller autorisationskoden på ID-kortet er en tom streng, eller autorisationskoden på id-kortet er den samme som autorisationskoden på autorisationen i autorisationsregisteret. b. Uddannelseskoden på id-kortet er ikke udfyldt, eller uddannelseskoden på id-kortet består ikke af fire tal, eller uddannelseskoden på id-kortet er den samme som uddannelseskoden på autorisationen i autorisationsregisteret. bemærk Gælder kun for STS miljøer hvor adgang til autorisationsregiser er konfigureret. Indtil alle STS miljøer har adgang til autorisationsregister kan service udbydere således ikke forlade sig på at autorisationen i et id-kort er verificeret af en STS Signér id-kort I det tilfælde, at sekvensen i alle foregående skridt har været fejlfri oprettes nu et svar, som indeholder en kopi af kalderens id-kort, der signeres med et STS VOCES-certifikat. Dette vil effektivt give gyldighed til id-kortet i føderationen. 3 Billetomveksling: id-kort til OIOIDWSH-token Formålet med ITS er at veksle et STS signeret id-kort til et OIOIDWS-H Identity Token [A7]. Dette token kan efterfølgende anvendes til at opnå adgang til andre systemer i føderationen, hvor et token fungerer som adgangsgiver. Det genererede token bliver typisk anvendt indlejret i en HTTP-URL. Se endvidere [A8]. I dette afsnit beskrives de væsentlige faser der eksisterer ifbm. en forespørgsel til ITS. Undervejs vil de væsentlige begreber og elementer, der indgår i en forespørgsel være forklaret. Der henvises endvidere til yderligere dokumentation, hvor det er relevant, så helheden og meningen fremgår.

9 6 / Snitflade Anvenderes tilgang til ITS vil enten være med hjælp fra Seal.Java/Seal.NET eller en properitær løsning forudsat, at kaldet overholder DGWS. En forespørgsel består basalt set af et SOSI id-kort og et ønsket audience, som bestemmer hvordan det vekslede Identity Token behandles. Et eksempel på hvordan et kald konstrueres med Seal.Java findes i SOSI Programmers Guide ([A2]) under "Use case 5: Request an Identity token from a STS". For Seal.NET anvendere findes der et.net-eksempel på kald af ITS ([A9]). Afhængig af miljø udstilles tjenesten på: 3.2 Behandling af forespørgsel om veksling af id-kort til OIOIDWS-H token Her fokuseres igen på den forretningsmæssige side af sagen og den trivielle husholdning er udeladt fra dette dokument. Sekvensen er følgende: 1. Check om id-kort er af bruger-type 2. Check om id-kort er gyldig i tid 3. Check om id-kort er gyldig ifht. audience konfiguration 4. Fremstil token Check om id-kort er af bruger-type Dette skridt har det simple formål at afgøre om id-kortet er af bruger-typen. Denne information fås fra id-kortet, som er indlejret i forespørgselsen Check om id-kort er gyldig i tid Dette skridt har det simple formål at afgøre om id-kortet er gyldigt i tid udfra id-kortets angivne oprettelsesdato og udløbsdato Check om id-kort er gyldig ifht. audience Audience [A6] begrebet dækker over den service, hvortil det aktuelle token skal udstedes. Audience er en logisk adresse på denne service. Det er defineret en række, parametre for et audience som afgør, hvilke egenskaber det aktuelle audience har. Disse parametre er lokale for ITS og vedligeholdes af driftsoperatøren direkte på databasen. Såfremt der findes en audience konfiguration for det aktuelle audience skal dette skridt afgøre om id-kortet er gyldigt i tid ifht. audience konfigurerede maksimale levetid på et id-kort Fremstil token I det tilfælde at sekvensen i alle foregående skridt har været fejlfri oprettes nu et token vha. Seal.Java, som indlejres i svaret. 4 Billetomveksling: OIOSAML assertion til id-kort Formålet med omvekslingen er at tillade anvendere af NemLogin at kalde foretage DGWS kald, som kræver SOSI id-kort, ved at veksle en eksisterende OIOSAML assertion til et id-kort.

10 7 / Snitflade Anvendere vil typisk bruge Seal.Java eller Seal.Net. En forespørgsel består af en OIOSAML assertion og yderligere attributter, der bruges af STS til at skabe id-kortet. Et eksempel på hvordan et kald til billetomvekslingen konstrueres med Seal.Java findes i SOSI Programmers Guide ([A2]) under "Use case 9: Exchange an OIOSAML assertion to an IDCard at a STS". Afhængig af miljø udstilles tjenesten på: 4.2 Struktur af forespørgsel og svar Der findes ingen offentliggjort wsdl for STS. Det anbefales at kalde via Seal.Java eller Seal.NET som begge stiller API-er til rådighed til at danne velstrukturerede forespørgsler og fortolke svaret. Strukturen for et SOAP request med henblik på signering af id-kort er som følger <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header> <wsa:action wsu:id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/rst/issue< /wsa:action> <wsa:messageid wsu:id="messageid">...</wsa:messageid> <wsse:security mustunderstand="1" wsu:id="security"> <wsu:timestamp wsu:id="ts"> <wsu:created> t15:32:07z</wsu:created> </wsu:timestamp> <ds:signature> <!-- signeret af det kaldende system --> </ds:signature> </wsse:security> </soapenv:header> <soapenv:body wsu:id="body"> <wst:requestsecuritytoken Context="..."> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#samlv2.0</wst:tokentype> <wst:requesttype>http://docs.oasis-open.org/ws-sx/ws-trust/200512/issue</ wst:requesttype> <wst14:actas> <saml:assertion xmlns:xs="http://www.w3.org/2001/xmlschema" ID="..." IssueInstant=" T15:32:06Z" Version="2.0" > <!-- udstedt og signeret af Nem-login --> <!-- NIX pille --> </saml:assertion> <saml:assertion xmlns:xs="http://www.w3.org/2001/xmlschema" ID="..." IssueInstant=" T15:32:07Z" Version="2.0" > <saml:issuer>sts demo</saml:issuer> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" >C=DK,O=Statens Serum Institut // CVR: ,CN=Karl Hoffmann Svendsen, Serial=CVR: RID: </saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches "/> </saml:subject> <saml:attributestatement> <saml:attribute Name="dk:healthcare:saml:attribute:UserSurName" NameFormat=" urn:oasis:names:tc:saml:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xs:string">svendsen</saml:attributevalue> </saml:attribute> <saml:attribute Name="dk:healthcare:saml:attribute:UserGivenName" NameFormat=" urn:oasis:names:tc:saml:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xs:string">karl Hoffmann</saml:AttributeValue>

11 8 / 13 </saml:attribute> <saml:attribute Name="dk:healthcare:saml:attribute:ITSystemName" NameFormat=" urn:oasis:names:tc:saml:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xs:string">sts demo</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> </wst14:actas> <wsp:appliesto> <wsa:endpointreference> <wsa:address>http://sosi.dk</wsa:address> </wsa:endpointreference> </wsp:appliesto> </wst:requestsecuritytoken> </soapenv:body> </soapenv:envelope> Dette vil give anledning til et svar fra STS på formen: <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header> <wsa:action wsu:id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/rst/issue< /wsa:action> <wsa:messageid wsu:id="messageid">...</wsa:messageid> <wsa:relatesto wsu:id="relatesto">...</wsa:relatesto> <wsse:security mustunderstand="1" wsu:id="security"> <wsu:timestamp wsu:id="ts"> <wsu:created> t15:32:07z</wsu:created> </wsu:timestamp> <ds:signature> <!-- signeret af STS --> </ds:signature> </wsse:security> </soapenv:header> <soapenv:body wsu:id="body"> <wst:requestsecuritytokenresponsecollection> <wst:requestsecuritytokenresponse Context="..."> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1# SAMLV2.0</wst:TokenType> <wst:requestedsecuritytoken> <saml:assertion IssueInstant=" T15:27:07Z" Version="2.0" id="idcard"> <!-- STS-signeret id-kort --> <!-- NIX pille --> </saml:assertion> </wst:requestedsecuritytoken> <wsp:appliesto> <wsa:endpointreference> <wsa:address>http://sosi.dk</wsa:address> </wsa:endpointreference> </wsp:appliesto> <wst:lifetime> <wsu:created> t15:27:07z</wsu:created> <wsu:expires> t15:27:07z</wsu:expires> </wst:lifetime> </wst:requestsecuritytokenresponse> <wst:requestedattachedreference> <wsse:securitytokenreference> <wsse:reference URI="#IDCard"/> </wsse:securitytokenreference> </wst:requestedattachedreference> <wst:requestedunattachedreference>

12 9 / 13 <wsse:securitytokenreference> <wsse:reference URI="#IDCard"/> </wsse:securitytokenreference> </wst:requestedunattachedreference> </wst:requestsecuritytokenresponsecollection> </soapenv:body> </soapenv:envelope> 4.3 Behandling af forespørgsel Omvekslingen validerer det medsendte OIOSAML assertion og tilhørende attributter om i følgende skridt: 1. Validér forespørgslens signatur 2. Validér OISAML assertion (signatur, tid og assurance level) 3. Anvender STS forretningslogik til a. validering af CPR nummer b. validering af autorisation 4. Checker at system navn findes 5. Byg og signér SOSI id-kort 4.4 Indhold af en OIOSAML assertion OIOSAML er en specialisering af SAML2.0 standarden profileret til danske forhold. Denne samt en subprofil baseret på OCES certifikater er beskrevet i [A11]. Billetomveksling er kun mulig for OIOSAML assertions dannet på baggrund af MOCES certifikater. Bemærk at mandatory betyder at attributten skal være udfyldt for OIOSaml assertions udstedt på baggrund af MOCES, men ikke nødvendigvis for alle OIOSAML assertions. Følgende attributter anvendes af billetomvekslingen: cvr nummer (mandatory): Anvendes til at danne System info i det udstedte id kort. organisationsnavn (mandatory): Anvendes til at danne System info i det udstedte id kort. certifikat (optionel): Hvis tilstede vedhæftes et digest af certifikatet i det udstedte id-kort og SubjectSerialNumber anvendes til opslag/validering af cpr nummer. cpr nummer (optionel): Hvis tilstede valideres det i sammenhæng med SubjectSerialNumber (cvr-rid). commonname (mandatory): Benyttes til id-kortets UserInfo såfremt forespørslen IKKE er vedhæftet fornavn/efternavn. mail (mandatory): Benyttes til id-kortets UserInfo. uid (mandatory): Skal indeholde SubjectSerialNumber (cvr-rid) for det underliggende MOCES certifikat. Benyttes til validering/opslag af cpr nummer, såfremt certifikatet ikke er vedhæftet. 5 Billetomveksling: id-kort til OIOSAML assertion Formålet med omvekslingen er at tillade anvendere af id-kort at foretage kald i NemLogin federationen, som kræver OIOSAML assertions, ved at veksle et eksisterende id-kort til et OIOSAML assertion.

13 10 / Snitflade Anvendere vil typisk bruge Seal.Java eller Seal.Net. En forespørgsel består af et id-kort og yderligere attributter, der bruges af STS til at skabe et assertion. Et eksempel på hvordan et kald til billetomvekslingen konstrueres med Seal.java findes i SOSI Programmers Guide ([A2]) under "Use case 11: Exchange an IDCard to and encrypted OIOSAML assertion at a STS". Afhængig af miljø udstilles tjenesten på: Det skal bemærkes at ikke alle STS signerede ID-kort kan anvendes til omveksling. Signeringen skal foregå via følgende snitflade: På sigt vil alt funktionalitet i denne flyttes over på den gamle URL. Dette vil kun have betydning for anvendere af den gamle URL, så det anbefaldes at den nye snitflade benyttes i alle sammenhænge. Forskellen mellem de 2 snitflader er at NameID/AlternativeIdentifier vil blive overskrevet i den nye snitflade. Dermed kan anvendere ikke længere bestemme indhold heraf. 5.2 Struktur af forespørgsel og svar Der findes ingen offentliggjort wsdl for STS. Det anbefales at kalde via Seal.Java eller Seal.NET som begge stiller API-er til rådighed til at danne velstrukturerede forespørgsler og fortolke svaret. Strukturen for et SOAP request med henblik på signering af ID-kort er som følger <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header> <wsa:action>http://docs.oasis-open.org/ws-sx/ws-trust/200512/rst/issue</wsa:action> <wsa:messageid>...</wsa:messageid> </soapenv:header> <soapenv:body> <wst:requestsecuritytoken Context="..."> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#samlv2.0</wst:tokentype> <wst:requesttype>http://docs.oasis-open.org/ws-sx/ws-trust/200512/issue</ wst:requesttype> <wst14:actas> <saml:assertion IssueInstant=" T15:12:01Z" Version="2.0" id="idcard"> <!-- STS-signeret ID-kort her --> </saml:assertion> </wst14:actas> <wsp:appliesto> <wsa:endpointreference> <wsa:address>//sundhed.dk</wsa:address> </wsa:endpointreference> </wsp:appliesto> </wst:requestsecuritytoken> </soapenv:body> </soapenv:envelope> Dette vil give anledning til et svar fra STS på formen: <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:...> <soapenv:header> <wsa:action wsu:id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/rst/issue< /wsa:action> <wsa:messageid wsu:id="messageid">...</wsa:messageid> <wsa:relatesto wsu:id="relatesto">...</wsa:relatesto>

14 11 / 13 <wsse:security mustunderstand="1" wsu:id="security"> <wsu:timestamp wsu:id="ts"> <wsu:created> t15:17:01z</wsu:created> </wsu:timestamp> <ds:signature> <!-- signeret af STS --> </ds:signature> </wsse:security> </soapenv:header> <soapenv:body wsu:id="body"> <wst:requestsecuritytokenresponsecollection> <wst:requestsecuritytokenresponse Context="..."> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1# SAMLV2.0</wst:TokenType> <wst:requestedsecuritytoken> <saml:encryptedassertion> <xenc:encrypteddata xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http: //www.w3.org/2001/04/xmlenc#element"> <!-- krypteret med nøgle, så kun sundhed.dk kan dekryptere --> <!-- dette token kan så bruges til autentifikation mod sundhed.dk --> </xenc:encrypteddata> </saml:encryptedassertion> </wst:requestedsecuritytoken> <wsp:appliesto> <wsa:endpointreference> <wsa:address>//sundhed.dk</wsa:address> </wsa:endpointreference> </wsp:appliesto> <wst:lifetime> <wsu:created> t15:17:01z</wsu:created> <wsu:expires> t16:17:01z</wsu:expires> </wst:lifetime> </wst:requestsecuritytokenresponse> </wst:requestsecuritytokenresponsecollection> </soapenv:body> </soapenv:envelope> 5.3 Normalisering af audience Audience (repliesto i forespørgelser) anvendes til at identificere konfigurationen, der bruges under omveksling; krypteringsnøgle og andre parametre vælges herunder. Audience skal tolkes som URI med en normalisering, som beskrives herefter. Denne normalisering bruges ved sammenligninger, dvs. ved opslag af konfiguration. Det er derfor vigtigt at der i forespørgelser anvendes audiences, der kan normaliseres til den rette konfiguration. En general URI ser således ud: <scheme>://<authority><path>?<query>#<fragment> Normaliseringen vil udføre følgende: lower-case af scheme og authority. hvis path blot er /, så vil path delen blive fjernet. query og fragment vil forblive uberørt. Port-angivelse, hvis sådan et findes, ændres heller ikke. Hvis scheme undlades, så vil : (kolon) også blive undladt.

15 12 / Behandling af forespørgsel Omvekslingen validerer det medsendte ID-kort og de tilhørende attributter og udfører følgende skridt: 1. Validér forespørgslens signatur samt trust til det benyttede certifikat. Dette kan være slået fra pga. interoperabilitet med SOSI-GW. 2. Validér ID-kort (trust og udløb) 3. Udvælgelses af audience baseret på normalisering (se Afsnit 5.3) 4. Byg af OIOSAML assertion a. Inkludér bootstrap token (ID-kort), hvis dette er konfigureret for fundne audience. b. Signér assertion. c. Kryptér hele svaret med den for audience konfigurerede offentlige nøgle. 5.5 Konfiguration Anvendere af systemet skal være opmærksom på at omvekslede tokens er rettet mod et modtager system, og vil kun kunne bruges hertil. Det givne modtagersystem skal være registreret og konfigureret i STS. Detaljer om konfigurationer findes i driftsvejledningen. 6 Referencer [A1] SOSI Executive Summary - (forklaring af føderationsbegrebet), Lakeside [A2] The SOSI Library Programmers Guide (version 2.2.6), Lakeside https://svn.softwareborsen.dk/sosi/tags/release-2.2.6/modules/seal/src/site/- SOSI%20programmers%20guide.doc [A3] Seal.NET (version 1.0), SDSD [A4] Den Gode Web Service (version 1.0 og 1.0.1), MedCom [A5] SOSI-GW Subversion repository https://svn.softwareborsen.dk/sosi-gw/ [A6] OCES-certifikatpolitikker (MOCES v4, VOCES v3) https://www.nemid.nu/digital_signatur/oces-standarden/oces-certifikatpolitikker/ [A7] FMKi projektet, Veksling til OIOIDWS-H Identity Tokens, NSI [A8] [A9] [A10] [A11] FMKi projektet, Brugsscenarier for OIODWS-H Identity Tokens, NSI Seal.NET ITS eksempel https://svn.softwareborsen.dk/medcomdgws/trunk/modules/sbo/src/securebrowserlogin.cs STS Fejlsituationer, Arosii A/S OIOSAML, A STS 1.1 til 1.3 migrering I forbindelse med opgradering af systemer, der tidligere har været integreret til og fungeret med STS version 1.1, til at benytte STS version 1.3 er en række forhold, som opmærksomheden bør rettes mod:

16 13 / 13 Autorisations-ID: der er indført et check på brugerens autorisations-id og det afgøres om brugerens rolle og autorisationskode, som angivet på ID-kortet, stemmer overens med lige præcis en tilladelse i lokale autorisationsoplysninger, førend brugeren kan godkendes. Fejlkoder og fejlbeskeder ændres i 1.3. Se [A10] for yderligere oplysninger. Support for whitelisting i STS udgår Introduktion af ITS: den nye service er beskrevet i afsnit 4 Seal.Java opgradering til version 2.1.x B STS 1.3 til 2.0 migrering For eksisterende anvendelser af STS 1.3, bør STS 2.0 ikke kræve ændringer. Introduktion af billetomveksling: den nye service er beskrevet i Afsnit 4 Seal.Java opgradering til version C STS 2.0 til 2.1 migrering For eksisterende anvendelser af STS 2.0, bør STS 2.1 ikke kræve ændringer. Introduktion af ny billetomveksling: den nye service er beskrevet i Afsnit 5 samt introduktion af ny signeringssnitflade, der overskriver NameId feltet. Seal.Java opgradering til version 2.1.6

STS Anvenderdokument i. STS Anvenderdokument

STS Anvenderdokument i. STS Anvenderdokument i STS Anvenderdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.4 2014-07 N iii Indhold 1 Introduktion 1 1.1 Målgruppen...................................................... 1 2 STS 1 2.1 Snitflade........................................................

Læs mere

STS Anvenderdokument. STS Anvenderdokument

STS Anvenderdokument. STS Anvenderdokument STS Anvenderdokument i STS Anvenderdokument STS Anvenderdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2012-12 N STS Anvenderdokument iii Indhold 1 Introduktion 1 1.1 Målgruppen......................................................

Læs mere

STS Fejlsituationer. STS Fejlsituationer

STS Fejlsituationer. STS Fejlsituationer STS Fejlsituationer i STS Fejlsituationer STS Fejlsituationer ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.4 2013-04 N STS Fejlsituationer iii Indhold 1 Introduktion 1 2 Behandling af forespørgsel

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Contents 1 Introduktion 1 2 Arkitekturoverblik 3 2.1 Eksterne snitflader..................................................

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

SOSI STS Testscenarier

SOSI STS Testscenarier SOSI STS Testscenarier Version 1.0.1 Status: Offentliggjort Indholdsfortegnelse 1 Introduktion... 2 1.1 Baggrund...2 1.2...2 1.3 Baggrundsmateriale... 2 1.4 Adgang...2 2 Test af STS Webservice... 4 2.1

Læs mere

Security Token Service. Snitflade OIO WS Trust

Security Token Service. Snitflade OIO WS Trust Security Token Service Snitflade OIO WS Trust Side 1 af 7 Indholdsfortegnelse 1. Versionsnummer... 3 2. Snitfladebeskrivelse... 3 3. Servicebeskrivelse... 3 3.1 Identity provider... 3 3.2 Supported binding...

Læs mere

Den Gode Sårjournal Service MedCom, version W 1

Den Gode Sårjournal Service MedCom, version W 1 Den Gode Sårjournal Service MedCom, version 1.0.0 W 1 Den Gode Sårjournal Service Rettelser... 3 Formål... 4 Funktionalitet... 5 GetSignOnLink... 5 GetNumberOfUnreadNotes... 5 Bilag A: Specificering af

Læs mere

STS Driftsvejledning. STS Driftsvejledning

STS Driftsvejledning. STS Driftsvejledning STS Driftsvejledning i STS Driftsvejledning STS Driftsvejledning ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.1 2012-11 HT STS Driftsvejledning iii Indhold 1 Introduktion 1 2 Konfigurations opdateringer

Læs mere

Ibrugtagning af Fødselsindberetningsservicen på NSP

Ibrugtagning af Fødselsindberetningsservicen på NSP Ibrugtagning af Fødselsindberetningsservicen på NSP Udarbejdet af: NSI Version: 1.0 Dato: 09.07.2013 Indholdsfortegnelse 1 Vejledning til ibrugtagning af Fødselsindberetningsservicen... 3 1.1 Læsevejledning

Læs mere

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet Digital Sundhed Brugerstyringsattributter - Introduktion - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Læsevejledning... 2 3. Aktører... 2 4. Autentifikation...

Læs mere

Teknisk Dokumentation

Teknisk Dokumentation Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...

Læs mere

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in (samt mulighed for FMK tilgang via SOSI STS) 15.marts 2017 /chg Baggrund Private aktører på sundhedsområdet som apoteker,

Læs mere

Det Fælles Medicinkort. IDWS - Snitfladebeskrivelse. Version

Det Fælles Medicinkort. IDWS - Snitfladebeskrivelse. Version Det Fælles Medicinkort IDWS - Snitfladebeskrivelse Version 1.4.0.1 2014-09-18 Versionering Version Dato Forfatter Ændring 1.4.0.1 2014-10-24 FRJ Første udgave af dokumentet Det Fælles Medicinkort IDWS

Læs mere

Guide til NemLog-in Security Token Service

Guide til NemLog-in Security Token Service Guide til NemLog-in Security Token Service Side 1 af 10 18. juni 2014 TG Denne guide indeholder en kort beskrivelse af, hvordan en myndighed eller itleverandør kan benytte NemLog-in s Security Token Service

Læs mere

Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services

Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services Version 1.0 april 2014 Indledning Seal.net er et API som har til formål at lette udviklingen af software som overholder

Læs mere

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation...

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation... Digital Sundhed Brugerstyringsattributter - Politikker - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Identifikation...... 2 2.1. Politik... 2 3. Sundhedsfaglig

Læs mere

Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1

Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1 Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1 MedCom, Den Gode NPN Service ver. 1.0 2 Den Gode NationalePrøveNummer Service MedCom version 1.0 Formål... 5 Introduktion... 5 Ansvar... 6

Læs mere

Valg af webservice standard

Valg af webservice standard Valg af webservice standard Agenda Valg til en serviceorienteret infrastruktur Identitetsbaserede Services, Kåre Kjelstrøm Teknologiske trends og udfordringer Debat, spørgsmål og kritik Skal du lave en

Læs mere

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Sundhedsdatanettets Anatomi UNI-C Router Organisation A Router Router Organisation B Firewall Firewall Linjesikkerhed

Læs mere

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

Den Gode Webservice Bilag Version 1.0-13-07-2006

Den Gode Webservice Bilag Version 1.0-13-07-2006 Bilag Version 1.0-13-07-2006 Bilag 1: Digital signering med XML...37 #1: Opret XML...38 #2: Indsæt indhold i XML...39 #2.a: Udpeg det XML, der skal underskrives...39 #2.b:

Læs mere

LAKESIDE. Sårjournalen. Ændring af sikkerhedsarkitekturen. Version marts 2015

LAKESIDE. Sårjournalen. Ændring af sikkerhedsarkitekturen. Version marts 2015 LAKESIDE Ændring af sikkerhedsarkitekturen Version. 0. marts 0 LAKESIDE A/S Marselisborg Havnevej,. sal DK-8000 Århus C Denmark tlf. + 07 www.lakeside.dk info@lakeside.dk Indledning Formålet med sidste

Læs mere

Ivan Overgaard 11/29/2012

Ivan Overgaard 11/29/2012 NSI Seal.Net Version 2.0 Ivan Overgaard 11/29/2012 Revisionshistorik: Version Dato Ændring Ansvarlig 0.8 29-11-2012 Oprettet IO 1.0 04-04-2013 redigeret IO Seal.Net Page 2 of 23 Version 2.0-29. november

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 SOSI (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 Indhold Hvad og hvem er SOSI Visionen og Missionen Begreber, arkitektur og teknik Hvad er SOSI Projekt initieret og drevet af Ribe- og

Læs mere

DESIGNDOKUMENT (Teknisk dokumentation)

DESIGNDOKUMENT (Teknisk dokumentation) 29. feb.2016 version 1.2 Lægemiddelstyrelsens E2B Bivirkningsservice DESIGNDOKUMENT (Teknisk dokumentation) Dokument historik Version Dato Ændring 1.0 19-06-2014 Final version ifm. idriftsættelse 1.1 29-06-2015

Læs mere

Specifikationsdokument for servicen PID-CPR

Specifikationsdokument for servicen PID-CPR Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 www.nets.dk CVR-nr. 30808460 Specifikationsdokument for servicen PID-CPR Nets DanID december 2016 Side 1-7 Indholdsfortegnelse

Læs mere

ecpr erstatnings CPR Design og arkitektur

ecpr erstatnings CPR Design og arkitektur 1 ecpr erstatnings CPR Design og arkitektur Indhold ecpr erstatnings CPR... 1 Indhold... 2 Formål... 3 Overblik... 4 Snitflader... 4 Komponenter... 5 Webservice... 5 Statuskomponent... 5 Forretningslag...

Læs mere

SOSI STS Dokumentationsoverblik

SOSI STS Dokumentationsoverblik SOSI STS Dokumentationsoverblik - for Sammenhængende Digital Sundhed i Danmark Date: 19. August, 2009 Version: 0.3 Author: Arosii A/S Indholdsfortegnelse 1 Introduktion...3 2 Dokumentationselementer...4

Læs mere

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen -

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - spn@itst.dk Velkommen! Dette er en WORKSHOP Ikke et fintunet kursus!!

Læs mere

STS Installationsvejledning. STS Installationsvejledning

STS Installationsvejledning. STS Installationsvejledning STS Installationsvejledning i STS Installationsvejledning REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.1 2012-11 HT STS Installationsvejledning iii Contents 1 Introduktion 1 2 Forudsætninger 3 2.1 Java..........................................................

Læs mere

Specifikationsdokument for OCSP

Specifikationsdokument for OCSP Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for OCSP DanID A/S 20. januar 2011 Side 1-11

Læs mere

Udvidet brug af personligt NemID i erhvervssammenhæng

Udvidet brug af personligt NemID i erhvervssammenhæng Udvidet brug af personligt NemID i erhvervssammenhæng Side 1 af 10 16. juni 2016 TG Baggrund Digitaliseringsstyrelsen planlægger i samarbejde med Erhvervsstyrelsen at gennemføre nogle ændringer i NemLog-in

Læs mere

Den Gode PatoBank Webservice MedCom, version 1.0

Den Gode PatoBank Webservice MedCom, version 1.0 Den Gode PatoBank Webservice MedCom, version 1.0 W1 Den Gode PatoBank webservice MedCom, ver. 1.0 Del A: Formål og funktionalitet...3 Formål og baggrund...3 Sikkerhedslog...4 Autentifikation...4 Webservice

Læs mere

Præcisering af transportbaseret sikkerhed i Den Gode Webservice

Præcisering af transportbaseret sikkerhed i Den Gode Webservice Præcisering af transportbaseret sikkerhed i Den Gode Webservice 1. Historik...2 2. Indledning...3 3. SSL/TLS baseret netværk...3 4. Sundhedsdatanettet (VPN)...5 5. Opsummering...6 6. Referencer...6 Side

Læs mere

STS Installationsvejledning. STS Installationsvejledning

STS Installationsvejledning. STS Installationsvejledning STS Installationsvejledning i STS Installationsvejledning REVISION HISTORY NUMBER DATE DESCRIPTION NAME 2.2.4 2014-12 JQ STS Installationsvejledning iii Contents 1 Introduktion 1 2 Forudsætninger 3 2.1

Læs mere

Dokumentation af optagelse.dk

Dokumentation af optagelse.dk ApplicationService Indhold Versionsstyring Introduktion Navn URL Formål Sikkerhed Operationer echo() findftuapplicationids(...) findftuapplicationbyid(...) findftuapplicationpdfbyid(...) findftuapplicationenclosurezipurlbyid(...)

Læs mere

FMK-online's brug af SmartFraming

FMK-online's brug af SmartFraming Side 1 af 9 FMK-online's brug af SmartFraming Version 1.1 2011-11-01 Side 2 af 9 Indholdsfortegnelse Indledning...3 Initialisering og login...3 Kontekst Properties...4 user.id.authorizationid...4 userorganization.id.number...4

Læs mere

SOSI STS Designdokument

SOSI STS Designdokument SOSI STS Designdokument - for Sammenhængende Digital Sundhed i Danmark Dato: 3. December, 2009 Version: 0.3 Forfatter: Arosii A/S Indholdsfortegnelse 1 Introduktion...3 2 Arkitekturoverblik...4 2.1 Eksterne

Læs mere

Anbefalede testprocedurer

Anbefalede testprocedurer Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Anbefalede testprocedurer Nets DanID A/S Marts 2014 Side 1-34 Indholdsfortegnelse

Læs mere

SOSIGW. - Administrationskonsol for SOSIGW 1.0.6. Indeks

SOSIGW. - Administrationskonsol for SOSIGW 1.0.6. Indeks SOSIGW - Administrationskonsol for SOSIGW 1.0.6 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Administrationskonsollen... 2 Generel brug af konsollen... 3 Fremsøgning af ID-kort... 3 Søgning

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

Den Gode Webservice. version 1.0.1 W 1

Den Gode Webservice. version 1.0.1 W 1 Den Gode Webservice version 1.0.1 W 1 Indhold Introduktion...3 Tid...4 Tidsangivelse...4 Tidssynkronisering...5 Referencer...6 MedCom. Den Gode Webservice version 1.0.1 2 Introduktion Den Gode Webservice

Læs mere

Specifikationsdokument for OCSP

Specifikationsdokument for OCSP Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for OCSP DanID A/S 3. juni 2014 Side 1-11 Indholdsfortegnelse

Læs mere

Kravspecifikation for SOSI-GW komponenten

Kravspecifikation for SOSI-GW komponenten Kravspecifikation for SOSI-GW komponenten Af: TSO/Lakeside Version: 1.20 1/13 Indhold Indhold...2 Baggrund...3 Overordnet teknisk beskrivelse...3 Om kravspecifikationen...5 Kravenes form...5 A Funktionelle

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

ATP WS Provider Profile

ATP WS Provider Profile ATP WS Provider Profile Author: Integration Expert Team (IET) (IET) Subject: ATP WS provider profile Page 1 of 16 1. Dokumenthistorik ATP WS Provider Profile Revisioner Dato for denne version: 13.11.2014

Læs mere

Specifikationsdokument for servicen PID-CPR

Specifikationsdokument for servicen PID-CPR Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for servicen PID-CPR DanID A/S 3. juni 2014 Side

Læs mere

Kald af PingService via SOAPUI

Kald af PingService via SOAPUI Kald af PingService via SOAPUI Author: Integration Expert Team (IET) Owner: Integration Expert Team (IET) Page 1 of 24 1. Dokumenthistorik Kald af PingService via SOAPUI Revisioner Dato for denne version:

Læs mere

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Side 1 af 5 Vejledning 2. august 2013 NITRI Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Indholdsfortegnelse Formål...2 Virksomhedssignatur...2 Funktionssignatur...3

Læs mere

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0, 13.12.2011 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen... 3 2 Formål

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

SOSI Gateway Komponenten (SOSI GW)

SOSI Gateway Komponenten (SOSI GW) SOSI Gateway Komponenten (SOSI GW) - en security domain gateway Version 1.2 1/8 Indledning Region Syddanmark er udvalgt som pilotregion for projektet Det Fælles Medicingrundlag, og i den forbindelse arbejdes

Læs mere

:55 i/iv BEM 2.0 BEM 2.0. Fælles Medicinkort - Dokumentation -

:55 i/iv BEM 2.0 BEM 2.0. Fælles Medicinkort - Dokumentation - 2016-11-22 09:55 i/iv BEM 2.0 BEM 2.0 Fælles Medicinkort - Dokumentation - http://wiki.fmk.netic.dk/ 2016-11-22 09:55 ii/iv BEM 2.0 http://wiki.fmk.netic.dk/ Printed on 2016-11-22 09:55 2016-11-22 09:55

Læs mere

Certifikatpolitik for NemLog-in

Certifikatpolitik for NemLog-in Side 1 af 9 7. november 2012 Certifikatpolitik for NemLog-in Version 1.2 Dette dokument beskriver certifikatpolitikken for NemLog-in løsningen. Politikken definerer hvilke typer certifikater, der må anvendes

Læs mere

Sikker udstilling af data

Sikker udstilling af data Sikker udstilling af data Digitaliseringsstyrelsen 8. oktober 2012 Thomas Gundel Agenda Baggrund hvorfor udstille data? OWSA Model T Identitetsbaserede Web Services NemLog-in s fuldmagtsløsning OAuth 2.0

Læs mere

Specifikationsdokument for OCSP

Specifikationsdokument for OCSP Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for OCSP DanID A/S 9. marts 2015 Side 1-11 Indholdsfortegnelse

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

Indholdsfortegnelse. Version 1.4. 1 Serviceplatformen - opsætningsguide (Eksterne testmiljø)... 2 1.1 Indledning... 2

Indholdsfortegnelse. Version 1.4. 1 Serviceplatformen - opsætningsguide (Eksterne testmiljø)... 2 1.1 Indledning... 2 Indholdsfortegnelse 1 Serviceplatformen - opsætningsguide (Eksterne testmiljø)... 2 1.1 Indledning... 2 1.2 Forberedelse til anvendelse Serviceplatformen... 2 1.2.1 Medarbejdercertifikat (MOCES)... 2 1.2.2

Læs mere

Den Gode LÆ-blanket Webservice (DGLÆ:WS)

Den Gode LÆ-blanket Webservice (DGLÆ:WS) Den Gode LÆ-blanket Webservice (DGLÆ:WS) MedCom arbejdspapir. Ver 0.2 18-06-2006. HVO Den Gode LÆ-blanket Webservice (DGLÆ:WS)...1 Del A: Formål og funktionalitet...2 Formål (=Usecase)...2 Sagsgangen i

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. AUGUST 2013 Fil: DIADEM - Kom godt igang - Ver 1.7.0.docx Indhold 1.

Læs mere

Den Gode Webservice. En fælles webserviceprofil for sundhedsvæsenet Version 1.0-13-07-2006. Den Gode Webservice

Den Gode Webservice. En fælles webserviceprofil for sundhedsvæsenet Version 1.0-13-07-2006. Den Gode Webservice Den Gode Webservice En fælles webserviceprofil for sundhedsvæsenet Version 1.0-13-07-2006 1 Introduktion...3 Anvendte standarder...5 Internationale standarder...5 Nationale standarder...6 Grundlæggende

Læs mere

Den Gode LÆ Service MedCom, version 1.0 W 1

Den Gode LÆ Service MedCom, version 1.0 W 1 Den Gode LÆ Service MedCom, version 1.0 W 1 MedCom, Den Gode LÆ Service ver. 1.0 2 Den Gode LÆ Service MedCom version 1.0 Formål... 5 Serviceudbyders Ansvar... 6 Tilgængelighed... 6 Funktionalitet... 7

Læs mere

Den Gode Webservice Bilag. Version

Den Gode Webservice Bilag. Version Den Gode Webservice Bilag Version 1.11-18-2-2008 Indhold Bilag 1: Digital signering med XML...3 #1: Opret XML...5 #2: Indsæt indhold i XML...5 #2.a: Udpeg det XML, der skal

Læs mere

Specifikationsdokument for servicen RID-CPR

Specifikationsdokument for servicen RID-CPR Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for servicen RID-CPR Nets DanID A/S januar 2015

Læs mere

Core User Library Repository Service (CULR) danzig 20120119 Poul Henrik Jørgensen

Core User Library Repository Service (CULR) danzig 20120119 Poul Henrik Jørgensen Core User Library Repository Service (CULR) danzig 20120119 Poul Henrik Jørgensen Baggrund En række aktuelle projekter beskæftiger sig med at sikre brugerne Sammenhængende adgang til digitalt materiale

Læs mere

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for SUP-specifikation, version 2.0 Bilag 9 Sikkerhed og samtykke Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af indholdet kan gengives med tydelig kildeangivelse Indholdsfortegnelse 1 Introduktion...

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Grænseflade til afhentning af FTU-ansøgninger på Optagelse.dk

Grænseflade til afhentning af FTU-ansøgninger på Optagelse.dk Grænseflade til afhentning af FTU-ansøgninger på Optagelse.dk Dato 16-09-2015 Version Status 1.0 Gældende Ansvarlig Tobias Thisted Side 2 af 13 Ændringshistorik Version Kapitel/afsnit Beskrivelse 1.0 Hele

Læs mere

Ungebasen. Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem PUBLICPUBLIC PUBLICPUBLICX

Ungebasen. Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem PUBLICPUBLIC PUBLICPUBLICX PUBLICPUBLIC PUBLICPUBLICX Ungebasen Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem 16.06.2014 A414.97.6 [Status] Side 1 af 15 Indhold 1. Indledning...

Læs mere

Trin-for-trin guide: Tilslutning af web service til NemLog-in

Trin-for-trin guide: Tilslutning af web service til NemLog-in Trin-for-trin guide: Tilslutning af web service til NemLog-in Side 1 af 18 18. maj 2015 TG Baggrund og formål I foråret 2014 blev der udarbejdet en fælles sikkerhedsmodel for grunddataprogrammet. Modellen

Læs mere

Det Fælles Medicinkort. Snitfladebeskrivelse for Receptfornyelse og genbestilling. Version 1.4.0

Det Fælles Medicinkort. Snitfladebeskrivelse for Receptfornyelse og genbestilling. Version 1.4.0 Det Fælles Medicinkort Snitfladebeskrivelse for Receptfornyelse og genbestilling Version 1.4.0 2012-11-21 Trifork A/S Margrethepladsen 4 DK-8000 Århus C Denmark +45 8732 8787 Fax: +45 8732 8788 DK www.trifork.com

Læs mere

Civilstyrelsen. Lovtidende. Generisk webservice til søgning af afgørelser - Vejledning. Version: 0.4 2013-09-03

Civilstyrelsen. Lovtidende. Generisk webservice til søgning af afgørelser - Vejledning. Version: 0.4 2013-09-03 Generisk webservice til søgning af Version: 0.4 2013-09-03 Indhold 1 INTRODUKTION... 3 1.1 BAGGRUND... 3 1.2 REQUEST - SØGEKRITERIA... 3 1.2.1 Understøttelse af operatorer i søgekriteria... 4 1.3 RESPONS...

Læs mere

LAKESIDE. Sårjournalen. Afslutningsrapport for ændring af. sikkerhedsarkitekturen. Version juni 2016

LAKESIDE. Sårjournalen. Afslutningsrapport for ændring af. sikkerhedsarkitekturen. Version juni 2016 LAKESIDE Sårjournalen Afslutningsrapport for ændring af sikkerhedsarkitekturen Version 1.0 24. juni 2016 LAKESIDE A/S Marselisborg Havnevej 32, 1. sal DK-8000 Aarhus C Denmark tlf. +45 21607252 www.lakeside.dk

Læs mere

Nets Rettighedsstyring

Nets Rettighedsstyring Lautrupbjerg 10 DK-2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 www.nets-danid.dk CVR-nr. 30808460 Dokumentation: Nets Rettighedsstyring (Attributtjeneste) P. 1-10 Indholdsfortegnelse 1 Introduktion...

Læs mere

Den Gode Webservice. version 1.1, 1-7-2008 W 1

Den Gode Webservice. version 1.1, 1-7-2008 W 1 Den Gode Webservice version 1.1, 1-7-2008 W 1 Indhold Introduktion...3 Anvendte standarder...4 Internationale standarder...5 Nationale standarder...6 Namespaces...6 Grundlæggende arkitektur...6 Kommunikationsmodel...7

Læs mere

Sikkerhed i Stamdatamodulet KOMBIT

Sikkerhed i Stamdatamodulet KOMBIT Sikkerhed i Stamdatamodulet KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Oversigt... 4 3.1 Relevante OCES-detaljer... 4 4 Overholdelse af persondatalov mv.... 5 5 Importer...

Læs mere

DataHub Forbrugeradgangsløsning Spørgsmål og svar

DataHub Forbrugeradgangsløsning Spørgsmål og svar 9. Januar 2013 MEH/MHC DataHub Forbrugeradgangsløsning Spørgsmål og svar Dok 75938-12_v2, Sag 10/3365 1/7 1. Generelt 1.1 I hvilket omfang yder Energinet.dk support til elleverandørerne? Forretningskonceptet

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013Klik her for at angive tekst. NOTAT Bilag 11: Anvenderkrav til adgangsstyring - Støttesystemerne Context handler, Security Token Service og Administrationsmodul (Bilag til dagsordenspunkt

Læs mere

Vilkår vedrørende brug af Støttesystemet Adgangsstyring

Vilkår vedrørende brug af Støttesystemet Adgangsstyring Vilkår vedrørende brug af Støttesystemet Adgangsstyring 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige

Læs mere

ELEKTRONISK INDBERETNING BØRNEDATABASEN VIA DGWS 13/1 2010 VERSION 1.02

ELEKTRONISK INDBERETNING BØRNEDATABASEN VIA DGWS 13/1 2010 VERSION 1.02 ELEKTRONISK INDBERETNING BØRNEDATABASEN VIA DGWS 13/1 2010 VERSION 1.02 Indhold Indhold... 2 Introduktion... 3 Den Gode Webservice... 4 ID Kortet... 4 Signering... 4 BDBChildMeasurementReport webservicen...

Læs mere

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017 Webservice kald System-til-system integration Ny Easy ATP 1. februar 2017 Side 1 of 9 Dokumenthistorik Revisionshistorik Dato for denne revision: 01.02.2017 Dato for næste revision ukendt Revisions Revisions

Læs mere

Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel. KMD Indkomst, P13-5. Version 13.0, 24.09.2015

Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel. KMD Indkomst, P13-5. Version 13.0, 24.09.2015 Snitfladebeskrivelse for WEBService IndkomstEnkeltForespoergsel KD Indkomst, P13-5 Version 13.0, 24.09.2015 Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen...

Læs mere

NemHandel registreringsvejledning. Navision Stat, INDFAK og Nemkonto. Introduktion. Overblik. Side 1 af 15. ØS/ØSY/CPS 7.

NemHandel registreringsvejledning. Navision Stat, INDFAK og Nemkonto. Introduktion. Overblik. Side 1 af 15. ØS/ØSY/CPS 7. Side 1 af 15 NemHandel registreringsvejledning ØS/ØSY/CPS 7. januar 2015 Navision Stat, INDFAK og Nemkonto Dette dokument beskriver den nødvendig EAN registrering på Nemhandelsregistret via NS NHR WEB

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Brugerguide til Stamdatamodulets administrator-gui KOMBIT

Brugerguide til Stamdatamodulets administrator-gui KOMBIT Brugerguide til Stamdatamodulets administrator-gui KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Installation... 4 4 Tilgå Konsollen... 4 5 Opret en ny Serviceaftager... 4 6

Læs mere

Maj 2012. Peter Kristiansen, pkris@nets.eu

Maj 2012. Peter Kristiansen, pkris@nets.eu Overgang til NemID til erhverv Maj 2012 Nets DanID A/S Peter Kristiansen, pkris@nets.eu NemID til erhverv 1. Opgaven vi står over for 2. De indledende øvelser 3. Sådan forløber migreringen 4. Problemer

Læs mere

DataHub Forbrugeradgangsløsning NemID Quick Guide

DataHub Forbrugeradgangsløsning NemID Quick Guide 20. august 2012 JHH/MEH DataHub Forbrugeradgangsløsning NemID Quick Guide Dok 75936-12_v1, Sag 10/3365 1/6 Indhold 1. NemId/Digital Signatur... 3 2. Tjenesteudbyderaftaler... 3 2.1 Selve aftalen... 3 2.2

Læs mere

Introduktion til NemID og Tjenesteudbyderpakken

Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S 11. april

Læs mere

Det Fælles Medicinkort. Snitfladebeskrivelse. Version 1.2.6

Det Fælles Medicinkort. Snitfladebeskrivelse. Version 1.2.6 Det Fælles Medicinkort Snitfladebeskrivelse Version 1.2.6 2014-07-01 Versionering Version Dato Forfatter Ændring 0.0.1 2007-04-20 TKN Udkast oprettet på baggrund af use cases og første møde med teknikere.

Læs mere

Specifikationsdokument for servicen RID-CPR

Specifikationsdokument for servicen RID-CPR Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for servicen RID-CPR DanID A/S 15. juni 2011

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Digitaliseringsstyrelsen

Digitaliseringsstyrelsen KFOBS Release Information Version: 7.0 ID: 32309/43491 2014-04-07 Indhold 1 INTRODUKTION... 4 1.1 PRODUKTIONSMILJØ... 4 1.2 TESTMILJØ... 4 2 NEMLOG-IN... 5 2.1 ÆNDRINGER OG FEJLRETTELSER... 5 2.1.1 Release

Læs mere

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær.

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær. EfterUddannelse.dk FraværService - systemdokumentation BRUGERDOKUMENTATION: WEB-SERVICE Af: Logica Indhold 1. Indledning... 1 1.1 Formål... 1 1.2 Webservice version... 1 1.3 Historik... 1 2. Absence Webservice...

Læs mere