Page History
...
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.
BST tokens
...
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
...
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.
...
- 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 **CHG: Skal tilføjes inden publicering**
- Omveksling af borger JWT til OIO Saml Token: Mangler for nuværende **CHG: Skal tilføjes inden publicering**
Eksempel: Omveksling af borger bootstrap token til IDWS token
...
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?**
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?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> |
...