...

Som beskrevet i STS - Guide til anvendere, så findes der i STS følgende services indenfor anvendelsesområdet borger: **CHG: Drop 'Niveau' kolonnen og angiv evt. her hvorvidt servicen kræver whitelisting - se kommentar i den overordnede guide **

De to services Bst2Idws og JWT2Idws minder om hinanden i opbygning af requests, understøttede claims og valideringer. Disse beskrives derfor under et i afsnittet om claims og valideringer. JWT2OIOSaml beskrives for sig selv.

...

for sig selv.

 BST tokens **CHG: Skal det stå her? Det er kun relevant for token-udsteder, ikke for alm. anvendere, som givetvis blot bliver forvirret**

**CHG: Vi bør undlade begreberne OIO2BST, OIO2BST-LEGACY og OIO3BST i hele dokumentet, dem hverken kan alle bør anvenderne skulle forholde sig til. I eksemplerne kan man i stedet skrive 'NemLog-in bootstraptoken' eller lign.**

Bst2Idws servicen tager imod 3 typer af BST tokens. For hver token udsteder (issuer), konfigureres token typen i tabellen sts_audconf.trustedIdpCitizenConfiguration.

...

OIO2BST og OIO3BST modtages i krypteret form. Bst2Idws servicen forsøger at dekryptere med krypteringsnøglerne i konfigurationstabellen.

Claims og valideringer for veksling til IDWS tokens **CHG: Til hvilke af de tre snitflader høre denne beskrivelse? **

I forhold til berigelse af det udstedte IDWS token er der mulighed for at medsende følgende claims til: **CHG: Nej, ikke 'mulighed' - CPR skal i hvert fald for BST2IDWS altid medsendes ...**

• dk:gov:saml:attribute:CprNumberIdentifier: Brugerens CPR nummer.
  • Dette kan valideres af STS vha OCES service til validering af PID-CPR (PID står i bootstraptokenet).
  • For OIO2BST og OIO3BST, valideres op imod CPR i tokenet.
• dk:healthcare:saml:attribute:OnBehalfOf: Optionel angivelse af et CPR nummer på en anden borger, som man ønsker at agere udfra fuldmagtstildelinger som.
  • Valideres vha fuldmagtsservice.

Udover claims, skal der i forespørgslen defineres angives et audience (som beskriver hvilken service det udstedte IDWS token skal bruges til). I NSP sammenhæng opereres der med følgende audiences:

• https://audience.nspop.dk/dds: Dokumentdelingsservicen
• https://audience.nspop.dk/minspaerring: MinSpærring
• https://audience.nspop.dk/minlog: MinLog2
• https://fmk: FMK

I eksemplerne neden nedenfor vises der eksempler på vekslinger af bootstraptoken til Idws og JWT til Idws. I eksemplet med bootstraptoken er der ydermere vist eksempler på anvendelsen af claims til både CPR for den kaldende bruger samt fuldmagt.

Snitfladebeskrivelser **CHG: Forkert overskrift**

Afhængig af miljø udstilles tjenesten på:

...

• Omveksling af borger bootstrap token (OIO2BST-LEGACY) til IDWS token (med angivelse af anden borgers CPR nummer for fuldmagtstildelinger)
  
  • OIO2BST assertion
  • OIO3BST assertion
• Omveksling af borger JWT til IDWS token: Mangler for nuværende
• Omveksling af borger JWT til OIO Saml Token: Mangler for nuværende

...

Bemærk returværdien fra STS, der indeholder attributten 'dk:gov:saml:attribute:Privileges_intermediate'. Værdien er base64 encoded. Efter en decode ser det således ud (bemærk, at strukturen både indeholder det CPR nummer, som borgeren ønsker at arbejde på vegne af samt listen af de privilegier, der rent faktisk er tildelt fra denne borger til den kaldende borger): **CHG: Privilege attributten bør vel kun indeholde de fuldmagter der er relevante for den givne audience? Dvs. aldrig FMK og DDV i  samme token. Eller har vi et issue i STS'en her?**

<?xml version="1.0" encoding="UTF-8"?>
<bpp:PrivilegeList xmlns:bpp="http://itst.dk/oiosaml/basic_privilege_profile">
  <bpp:PrivilegeGroup Scope="urn:dk:healthcare:saml:actThroughProcurationBy:cprNumberIdentifier:0101603040">
    <bpp:Privilege>urn:dk:nspop:sts:ddv:read</bpp:Privilege>
    <bpp:Privilege>urn:dk:nspop:sts:ddv:write</bpp:Privilege>
    <bpp:Privilege>urn:dk:nspop:sts:fmk:read</bpp:Privilege>
    <bpp:Privilege>urn:dk:nspop:sts:fmk:write</bpp:Privilege>
  </bpp:PrivilegeGroup>
</bpp:PrivilegeList>

...