STS Anvenderdokument. STS Anvenderdokument

Transkript

1 STS Anvenderdokument i STS Anvenderdokument

2 STS Anvenderdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME N

3 STS Anvenderdokument iii Contents 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: 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 11 A STS 1.1 til 1.3 migrering 11 B STS 1.3 til 2.0 migrering 11 C STS 2.0 til 2.1 migrering 12

4 STS Anvenderdokument 1 / 12 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 4 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/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 (nemlogin) /sts/services/bst2idws Niveau 5 Ombytter OIOSaml bootstrap token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (nem-login) /sts/services/oiosaml2sosi Niveau 5 Ombytter krypteret OIOSaml token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (nem-login) 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 STS Anvenderdokument 2 / Arkitektur overblik DesignDokument/systemcontext.png Figure 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. 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å: 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=" <wst:tokentype>urn:oasis:names:tc:saml:2.0:assertion:</wst:tokentype> <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>

6 STS Anvenderdokument 3 / 12 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=" <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> </wst:status> <wst:issuer> <wsa:address>test2-nsp-sts</wsa:address> </wst:issuer> </wst:requestsecuritytokenresponse> </soapenv:body> </soapenv:envelope> 2.3 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

7 STS Anvenderdokument 4 / 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: 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.

8 STS Anvenderdokument 5 / 12 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. Note 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: 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. 3.1 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å: 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"> /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>

9 STS Anvenderdokument 6 / 12 <!-- signeret af det kaldende system --> </ds:signature> </wsse:security> </soapenv:header> <soapenv:body wsu:id="body"> <wst:requestsecuritytoken Context="..."> <wst:tokentype> <wst:requesttype> wst:requesttype> <wst14:actas> <saml:assertion xmlns:xs=" ID="..." IssueInstant=" T15:32:06Z" Version="2.0" > <!-- udstedt og signeret af Nem-login --> <!-- NIX pille --> </saml:assertion> <saml:assertion xmlns:xs=" 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> </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> </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"> /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">

10 STS Anvenderdokument 7 / 12 <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> 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> </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> <wsse:securitytokenreference> <wsse:reference URI="#IDCard"/> </wsse:securitytokenreference> </wst:requestedunattachedreference> </wst:requestsecuritytokenresponsecollection> </soapenv:body> </soapenv:envelope> 3.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

11 STS Anvenderdokument 8 / 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. 4 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. 4.1 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. snitflade: Signeringen skal foregå via følgende 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.

12 STS Anvenderdokument 9 / 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> <wsa:messageid>...</wsa:messageid> </soapenv:header> <soapenv:body> <wst:requestsecuritytoken Context="..."> <wst:tokentype> <wst:requesttype> 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"> /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: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> SAMLV2.0</wst:TokenType> <wst:requestedsecuritytoken> <saml:encryptedassertion> <xenc:encrypteddata xmlns:xenc=" Type="http: // <!-- krypteret med nøgle, så kun sundhed.dk kan dekryptere --> <!-- dette token kan så bruges til autentifikation mod sundhed.dk --> </xenc:encrypteddata>

13 STS Anvenderdokument 10 / 12 </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> 4.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. 4.4 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 Section 4.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.

14 STS Anvenderdokument 11 / 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. 5 Referencer [A1] SOSI Executive Summary - (forklaring af føderationsbegrebet), Lakeside [A2] The SOSI Library Programmers Guide (version 2.3.2), Lakeside 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 [A6] OCES-certifikatpolitikker (MOCES v4, VOCES v3) [A9] Seal.NET ITS eksempel [A10] STS Fejlsituationer, Arosii A/S [A11] 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: 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 Section 3 Seal.Java opgradering til version 2.1.5

15 STS Anvenderdokument 12 / 12 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 Section 4 samt introduktion af ny signeringssnitflade, der overskriver NameId feltet. Seal.Java opgradering til version 2.1.6