Hvad er identitetsbaserede webservices?

En identitetsbaseret web service (IDWS) er en web service der kaldes på vegne af en identitet, og som er bundet til en autentifikationshandling fra identiteten. En 'identitet' kan være lidt af hvert, men i denne sammenhæng vil det være en person, og - når vi som nedenfor taler om OIOIDWS - så vil det være en borger, der har autentificeret sig med sit MitID.

Så det kan med andre ord kun lade sig gøre at kalde en identitetsbaseret web service, når borgeren er i en gyldig login session. Det gør den type services lidt mere sikre, fordi hvis det kaldende system bliver hacket, så vil hackeren maksimalt kunne få adgang til oplysninger for de borgere der på kompromitteringstidspunktet er logget på. Var web servicen derimod ikke bundet til brugerernes login-sessioner, ville hackeren potentielt kunne kalde web servicen "på vegne af" alle mulige borgeres, blot hackeren kunne gætte CPR-numre ... og de bliver jo jævnligt lækket (se fx https://www.dr.dk/nyheder/penge/12-millioner-danskere-har-faaet-cpr-numre-laekket).

Nedenstående figur illustrerer en identitetsbaseret web service der kaldes af Sundhed.dk / Sundhedsjournalen (E-journal web servicen). De illustrerede brugere er alle borgere, der på kaldstidspunktet er logget ind hos Sundhed.dk / Sundhedsjournalen. "Bruger-1" vil nu gerne se journaloplysninger fra hospitalerne. De oplysninger skal hentes hos E-journal web servicen, men før den kan kaldes, skal Sundhedsjournalen skaffe en adgangsbillet, der er bundet til "Bruger-1"s login session. De nærmere detaljer får du nedenfor.

Et af de centrale begreber er altså "adgangsbilletter". Det er måske også værd at bemærke, at disse adgangsbilletter udstedes til at kunne kalde en bestemt identitetsbaseret web service (kaldes "audience" i billetten).


Hvad er så OIOIDWS?

OIO identitetsbaserede webservices er et sæt af webservice profiler som fastlægger hvordan Identitetsbaserede web services (IDWS) bør implementeres i fællesoffentlige IT-systemer. OIOIDWS regulerer hvordan man skaffer adgangsbilletter, hvad der som minimum skal være i adgangsbilletterne og hvordan de "bindes" til brugernes loginsessioner afhængig af, om konteksten er SOAP web services eller REST services. Figuren nedenfor viser de forskellige OIO profiler, der pt. indgår i OIOIDWS området. Figuren viser flowet i "Web Single Sign-On" (Web SSO) scenariet, og er typisk flowet der anvendes når man har at gøre med en web-baseret applikation (f.eks. Sundhed.dk web portalen). De væsentligste forkortelser er:

  • IDP = Identity Provider, autentifikationspunkt altså der hvor borgeren "logger ind". Tænk NemLogin/MitID eller SEB (Sundhedsvæsenets Elektroniske Brugerstyring).
  • SP = Service Provider,  web portalen, f.eks. Sundhed.dk
  • WSC = Web Service Consumer, komponenten der har brug for at kalde en identitetsbaseret webservice. Det kunne f.eks. være Sundhedsjournalen der afvikles i Sundhed.dk
  • STS = Security Token Service, komponent der udsteder adgangsbilletter (identity tokens) i forbindelse med identitetsbaserede web services.
  • WSP = Web Service Provider, komponenten der tilbyder en identitetsbaseret web service.


Hvordan er flowet mellem IDWS komponenterne?

Flowet mellem disse komponenter er relativt logisk.

  1. Først logger brugeren ind (via IdP'en). Her udsteder IdP'en et autentifikationstoken - et SAML token hvori der er indlejret et såkaldt bootstrap token.
    1. OIOSAML profilen regulerer hvordan SAML tokenet skal se ud.
    2. OIO Bootstrap Token Profile regulerer Bootstrap tokenet skal se ud.
  2. SP kalder WSC'en, der anmoder STS'en om at veksle bootstrap tokenet til et identity token
    1. OIO WS-Trust Profile og OIO WS-Trust deployment profile regulerer hvordan kaldet til STS'en skal se ud.
    2. OIO Identity Token regulerer hvordan det udstedte Identity Token skal se ud.
  3. WSC indlejrer identity tokenet i kaldet til WSP, der kontrollerer tokenet og bruger attributterne i tokenet til at afgøre, om brugeren skal have adgang til servicen og evt. til hvordan svaret skal se ud.

I nedenstående figur er flowet eksemplificeret i et scenarie med Sundhed.dk / Sundhedsjournalen, der skal kalde E-journal webservicen:

Hvorfor så mange omvekslinger

Et naturligt spørgsmåls kunne nu være: "hvorfor alle de der omvekslinger. Kan man ikke bare sende bootstraptokenet eller autentifikationstokenet med som parameter til web servicen?".

Det hænger først og fremmest sammen med sikkerhed og privatlivshåndtering. Dels: hvis en WSP får fremsendt et token, der giver adgang til andre services, så er brugeren ikke længere i kontrol over, hvad der bliver kaldt "på vegne af" brugeren. Dels skal alle WSP'er ikke nødvendigvis have alle/samme oplysninger om brugeren. Det handler både om at reducere mængden af information, der sendes over linjerne, og om kun at "sprede" nødvendig information om brugeren i netværket. En omveksling til et identity-token gør det muligt at reducere indholdet til netop det web servicen har brug for. Derfor er der bygget en del sikkerhedsmæssige aspekter ind i protokollen:

  • Bootstrap token er bundet til en bestemt STS, dvs. det er kun denne STS, der kan omveksle det til et Identity Token.
  • Identity Tokens er bundet til en bestemt WSP ('Audience'). Alle andre WSP'er skal afvise et Identity Token, der ikke er tilegnet dem.
  • Gyldighedstiden på Bootstrap tokens er typisk længere end gyldigheden på et Identity Token.
    Det betyder så også, at der jo ikke behøves at blive vekslet hver gang! Men der skal veksles, når man skal kalde en ny WSP og hvis Identity Tokens udløber.
  • Og som ovenfor nævnt kan en STS skræddersy Identity Tokens med netop det indhold, som WSP'en har behov for at få.

Kan jeg simulere kaldene vist i figuren ovenfor?

Ja, ved hjælp af den 'Dynamiske Request Generator' (DRG) kan du selv prøve det! Hvis du ikke allerede har en bruger til DRG, kan I ansøge om en sådan her: https://www.nspop.dk/display/resources/Brugeroprettelse. I Webformen kan man desværre ikke vælge ”Dynamisk Request Generator” så derfor udfyldes i stedet supplerende oplysninger med ønsket om at benytte DRG (du kan få mere info om DRG her: "Guide til anvendere af DRG" https://www.nspop.dk/display/public/web/DRG+-+Guide+til+anvendere)

Men når du har adgang til DRG, så kan du teste det sådan her:

  1. Åbn https://testkald.nspop.dk/drg/entry i en browser
  2. Scroll ned i listen "Vælg identitet" og vælg "Borger (Valgfrit CPR)"
  3. I området til højre skal du vælge et testsystem, f.eks. Test1 cNSP
  4. I området nederst skal du nu vælge en service, der kan kaldes som "borger" (POCES). Tag f.eks. Sundhedsregistre > Organdonorregisterservice (ODR) > Organdonorregister - Has
  5. Scroll nu op  igen og vælg fane "2. Udfyld". Indtast CPR: 0312410968 i begge felter (det er en eksisterende testborger)
  6. Vælg fane "3. Udfør" og tryk på knappen [Vis request]
  7. Nu får du 3 nye links: Vis STS-request, Vis STS-response og Service-request. STS-request og STS-response er de to pile i step (2) i figuren ovenfor.

Hvordan ser en billetomveksling ud (Step 2)?

STS-request med Bootstrap token (digsig fjernet) 
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <soapenv:Header>
      <wsse:Security mustUnderstand="1" wsu:Id="security">
         <wsu:Timestamp wsu:Id="ts">
            <wsu:Created>2023-12-05T10:30:32Z</wsu:Created>
         </wsu:Timestamp>
         <ds:Signature> ... </ds:Signature>
      </wsse:Security>
      <wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
      <wsa:MessageID wsu:Id="messageID">urn:uuid:75a42eac-41b9-4406-8ba6-f40e0db47f64</wsa:MessageID>
   </soapenv:Header>
   <soapenv:Body wsu:Id="body">
      <wst:RequestSecurityToken Context="urn:uuid:6126776f-d061-4346-87c2-ed24a66196e8">
         <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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_ac641bce-0a15-46fe-9d43-b419b8089a65" IssueInstant="2023-12-05T10:30:32Z" Version="2.0">
               <saml:Issuer>https://idp.testkald.nspop.dk</saml:Issuer>
               <ds:Signature Id="OCESSignature"> ... </ds:Signature>
               <saml:Subject>
                  <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">dk:gov:saml:attribute:CprNumberIdentifier:0312410968</saml:NameID>
                  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
                     <saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
                        <ds:KeyInfo>
                           <ds:X509Data> ...</ds:X509Data>
                        </ds:KeyInfo>
                     </saml:SubjectConfirmationData>
                  </saml:SubjectConfirmation>
               </saml:Subject>
               <saml:Conditions NotOnOrAfter="2023-12-05T11:20:32Z">
                  <saml:AudienceRestriction>
                     <saml:Audience>https://sts.sosi.dk/</saml:Audience>
                  </saml:AudienceRestriction>
               </saml:Conditions>
               <saml:AttributeStatement>
                  <saml:Attribute Name="https://data.gov.dk/model/core/specVersion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                     <saml:AttributeValue xsi:type="xs:string">OIO-SAML-3.0</saml:AttributeValue>
                  </saml:Attribute>
                  <saml:Attribute Name="https://data.gov.dk/concept/core/nsis/loa" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                     <saml:AttributeValue xsi:type="xs:string">Substantial</saml:AttributeValue>
                  </saml:Attribute>
                  <saml:Attribute Name="https://data.gov.dk/model/core/eid/cprNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                     <saml:AttributeValue xsi:type="xs:string">0312410968</saml:AttributeValue>
                  </saml:Attribute>
               </saml:AttributeStatement>
            </saml:Assertion>
         </wst14:ActAs>
         <wsp:AppliesTo>
            <wsa:EndpointReference>
               <wsa:Address>https://fsk</wsa:Address>
            </wsa:EndpointReference>
         </wsp:AppliesTo>
         <wst:Claims Dialect="http://docs.oasis-open.org/wsfed/authorization/200706/authclaims">
            <auth:ClaimType Uri="dk:gov:saml:attribute:CprNumberIdentifier">
               <auth:Value>0312410968</auth:Value>
            </auth:ClaimType>
         </wst:Claims>
      </wst:RequestSecurityToken>
   </soapenv:Body>
</soapenv:Envelope>

Bootstrap tokenet er den SAML Assertion du kan se linje: 18-47. Bemærk 'audience' i linje 33 er "https://sts.sosi.dk/". Det er kun hos denne STS, der kan veksles.

STS-response med Identity token (digsig fjernet) 
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <soapenv:Header>
      <wsse:Security mustUnderstand="1" wsu:Id="security">
         <wsu:Timestamp wsu:Id="ts">
            <wsu:Created>2023-12-05T10:30:32Z</wsu:Created>
         </wsu:Timestamp>
         <ds:Signature>...</ds:Signature>
      </wsse:Security>
      <wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
      <wsa:MessageID wsu:Id="messageID">urn:uuid:8bbd4d95-7400-4577-9bcd-1c681d5c0089</wsa:MessageID>
      <wsa:RelatesTo wsu:Id="relatesTo">urn:uuid:75a42eac-41b9-4406-8ba6-f40e0db47f64</wsa:RelatesTo>
   </soapenv:Header>
   <soapenv:Body wsu:Id="body">
      <wst:RequestSecurityTokenResponseCollection>
         <wst:RequestSecurityTokenResponse Context="urn:uuid:6126776f-d061-4346-87c2-ed24a66196e8">
            <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
            <wst:RequestedSecurityToken>
               <saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_6c9a5c36-fc95-43c9-bd2d-7490ef076968" IssueInstant="2023-12-05T10:30:32Z" Version="2.0">
                  <saml:Issuer>TEST1-NSP-STS</saml:Issuer>
                  <ds:Signature Id="OCESSignature">...</ds:Signature>
                  <saml:Subject>
                     <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">dk:gov:saml:attribute:CprNumberIdentifier:0312410968</saml:NameID>
                     <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
                        <saml:SubjectConfirmationData NotOnOrAfter="2023-12-05T11:20:32Z" Recipient="https://fsk">
                           <ds:KeyInfo>
                              <ds:X509Data>...</ds:X509Data>
                           </ds:KeyInfo>
                        </saml:SubjectConfirmationData>
                     </saml:SubjectConfirmation>
                  </saml:Subject>
                  <saml:Conditions NotBefore="2023-12-05T10:25:32Z" NotOnOrAfter="2023-12-05T11:20:32Z">
                     <saml:AudienceRestriction>
                        <saml:Audience>https://fsk</saml:Audience>
                     </saml:AudienceRestriction>
                  </saml:Conditions>
                  <saml:AttributeStatement>
                     <saml:Attribute Name="dk:gov:saml:attribute:SpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                        <saml:AttributeValue xsi:type="xs:string">DK-SAML-2.0</saml:AttributeValue>
                     </saml:Attribute>
                     <saml:Attribute Name="dk:gov:saml:attribute:AssuranceLevel" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                        <saml:AttributeValue xsi:type="xs:string">3</saml:AttributeValue>
                     </saml:Attribute>
                     <saml:Attribute Name="dk:gov:saml:attribute:CprNumberIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                        <saml:AttributeValue xsi:type="xs:string">0312410968</saml:AttributeValue>
                     </saml:Attribute>
                  </saml:AttributeStatement>
               </saml:Assertion>
            </wst:RequestedSecurityToken>
            <wsp:AppliesTo>
               <wsa:EndpointReference>
                  <wsa:Address>https://fsk</wsa:Address>
               </wsa:EndpointReference>
            </wsp:AppliesTo>
            <wst:Lifetime>
               <wsu:Created>2023-12-05T10:25:32Z</wsu:Created>
               <wsu:Expires>2023-12-05T11:20:32Z</wsu:Expires>
            </wst:Lifetime>
         </wst:RequestSecurityTokenResponse>
      </wst:RequestSecurityTokenResponseCollection>
   </soapenv:Body>
</soapenv:Envelope>

Identity tokenet er den SAML Assertion du kan se linje: 19-48. Bemærk audience i linje 34 er "https://fsk" (fælles stamkort, hvor organdonor-opslaget pt. 'bor').

Hvordan ser et IDWS-kald ud (Step 3)?

Klikker du på det sidste link i DRG  (Service-request) kan du se hvordan selve service-requestet ser ud. Her kan du i linje 8-39 finde det Identity Token, som blev udstedt af STS'en:

Service request med indlejret Identity token (digsig fjernet) 
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:sbf="urn:liberty:sb" xmlns:sbfprofile="urn:liberty:sb:profile" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <wsse:Security mustUnderstand="1" wsu:Id="security">
         <wsu:Timestamp wsu:Id="ts">
            <wsu:Created>2023-12-05T10:30:32Z</wsu:Created>
         </wsu:Timestamp>
         <saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_6c9a5c36-fc95-43c9-bd2d-7490ef076968" IssueInstant="2023-12-05T10:30:32Z" Version="2.0">
            <saml:Issuer>TEST1-NSP-STS</saml:Issuer>
            <ds:Signature Id="OCESSignature">...</ds:Signature>
            <saml:Subject>
               <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">dk:gov:saml:attribute:CprNumberIdentifier:0312410968</saml:NameID>
               <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
                  <saml:SubjectConfirmationData NotOnOrAfter="2023-12-05T11:20:32Z" Recipient="https://fsk">
                     <ds:KeyInfo>
                        <ds:X509Data>
                           <ds:X509Certificate>MIIGlTCCBMmgAwIBAgIUBfJqJcHHTYu8i8CTw0Iof2B+IO4wQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgMGsxLTArBgNVBAMMJERlbiBEYW5za2UgU3RhdCBPQ0VTIHVkc3RlZGVuZGUtQ0EgMTETMBEGA1UECwwKVGVzdCAtIGN0aTEYMBYGA1UECgwPRGVuIERhbnNrZSBTdGF0MQswCQYDVQQGEwJESzAeFw0yMjAzMDgxMzI5NThaFw0yNTAzMDcxMzI5NTdaMIGrMSIwIAYDVQQDDBlEUkcgRnVua3Rpb25zY2VydGlmaWthdGV0MTcwNQYDVQQFEy5VSTpESy1POkc6NWVjN2FmMDEtZTJkZC00NWRhLTkyZjMtZWE4ZWVlY2U5NmY2MSYwJAYDVQQKDB1UZXN0b3JnYW5pc2F0aW9uIG5yLiA5NTQ0NDk2MDEXMBUGA1UEYQwOTlRSREstOTU0NDQ5NjAxCzAJBgNVBAYTAkRLMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAuM01UT/Qfc80p+JnSMUoPRCGVnlk5KkFY3vLXhAlPYm/pgbgI/w3zITbE7ONYnuXU1+pLOkxF3jYPq+WCTGrm8EUA1/I8Yx5L0fY1h9VCVef+1rfvkFdDLPlcZk394Ms5dBcq/2OjxdwD7ZNrV0WgytYBma/vFUroJCyHYqdhYmGoQRfnsNali8l1XG6N2oJwA3r3VuCajmCFFsNKmw6Sh6cSQUyqUtmetCxOzkGh1CPpwUr9EhlC7KyerfFad/gpKjxJ7nr4dQLK0C0hOgcM5MtFINxgg1KSdxWfkGrrcH6FOVRxPH0n3qLoDgYYbfOjVqiakTpc8MTSXaPHX73Jggd7tx39SscnGtgMFbKJt8o53RxjY0k2Sj7/SQclGb478lOVXDP0XmRwl8wMcDE2Qk+PmGWnjBt2+s+0iMFNjZwg5+dxKctzx2qtm6xCubKXfieFy6r7BY7zI1wJ3NZB8g+JCZZpnjq+u4hUcxYhJHv2rF7qOoNktIyswkW/yWRAgMBAAGjggGGMIIBgjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFH8on9lxmULidefXNXYuTQglbXZeMHsGCCsGAQUFBwEBBG8wbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhMS5jdGktZ292LmRrL29jZXMvaXNzdWluZy8xL2NhY2VydC9pc3N1aW5nLmNlcjAmBggrBgEFBQcwAYYaaHR0cDovL2NhMS5jdGktZ292LmRrL29jc3AwIQYDVR0gBBowGDAIBgYEAI96AQEwDAYKKoFQgSkBAQEDBzA7BggrBgEFBQcBAwQvMC0wKwYIKwYBBQUHCwIwHwYHBACL7EkBAjAUhhJodHRwczovL3VpZC5nb3YuZGswRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NhMS5jdGktZ292LmRrL29jZXMvaXNzdWluZy8xL2NybC9pc3N1aW5nLmNybDAdBgNVHQ4EFgQUvp2tVXiewl0io/wMIf+ArCQxPRIwDgYDVR0PAQH/BAQDAgWgMEEGCSqGSIb3DQEBCjA0oA8wDQYJYIZIAWUDBAIBBQChHDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiAwIBIAOCAYEAnRUp0/eatpgkVVt8q9iNYcrTaoGD9lo/vqkQwkSOkQ1NW9uu1fxZAcjjMMpMMpuNpC4V8d6klYUfPWBEDwBEVGgCB/0PADltzm8/a/zYhU3/CLie/7ybWvteAl8ELcX/JJRWzKm5zL1LyA76Hg+77OPsghK796/rLQ2aabqeUN0K5bSUqQDLytn9MdBUFqjRGaQbo6dhD6vpLzwulQYujPFU8Ala0kEfJvq2sdRhVYIHAZlOu18sH/v/NmPzag5h+S/AjF9lw6Hw+nplR0o2hHtvxwnfVPjKjJVGUvxWJc/rn5k0x4YHYO06r50QY9QwMnYWZlLS4kGurKT9gWl3VFUINngZV2xse5MszkC+KV60MEqNhaUWf6Env1vGmBt3aQU53TpvCZMqC2jMG+sHxY8g4YcajEmsLTSWQ+xxJjnNqCo3UKDytULEmyGEG3VmrZmTnZlXGdCsVtauEj5nbg9Qn6to/Ic9gvVzmDKKI9u85010G5nxUO3Nle33QE/D</ds:X509Certificate>
                        </ds:X509Data>
                     </ds:KeyInfo>
                  </saml:SubjectConfirmationData>
               </saml:SubjectConfirmation>
            </saml:Subject>
            <saml:Conditions NotBefore="2023-12-05T10:25:32Z" NotOnOrAfter="2023-12-05T11:20:32Z">
               <saml:AudienceRestriction>
                  <saml:Audience>https://fsk</saml:Audience>
               </saml:AudienceRestriction>
            </saml:Conditions>
            <saml:AttributeStatement>
               <saml:Attribute Name="dk:gov:saml:attribute:SpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                  <saml:AttributeValue xsi:type="xs:string">DK-SAML-2.0</saml:AttributeValue>
               </saml:Attribute>
               <saml:Attribute Name="dk:gov:saml:attribute:AssuranceLevel" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                  <saml:AttributeValue xsi:type="xs:string">3</saml:AttributeValue>
               </saml:Attribute>
               <saml:Attribute Name="dk:gov:saml:attribute:CprNumberIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                  <saml:AttributeValue xsi:type="xs:string">0312410968</saml:AttributeValue>
               </saml:Attribute>
            </saml:AttributeStatement>
         </saml:Assertion>
         <wsse:SecurityTokenReference xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wsswssecurity-secext-1.1.xsd" wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0" wsu:Id="str">
            <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_6c9a5c36-fc95-43c9-bd2d-7490ef076968</wsse:KeyIdentifier>
         </wsse:SecurityTokenReference>
         <ds:Signature>...</ds:Signature>
      </wsse:Security>
      <wsa:MessageID wsu:Id="messageID">efd86bb3-2021-4405-88f2-e541e63a3bf1</wsa:MessageID>
      <wsa:Action wsu:Id="action">http://sundhedsdatastyrelsen.dk/organdonor/2018/05/01#HasOrganDonorRegistration</wsa:Action>
      <sbf:Framework sbfprofile:profile="urn:liberty:sb:profile:basic" version="2.0" wsu:Id="sbf" />
   </soapenv:Header>
   <soapenv:Body wsu:Id="body">
      <ns:HasOrganDonorRegistrationRequest xmlns:ns="http://sundhedsdatastyrelsen.dk/organdonor/2018/05/01/" xmlns:odr="urn:hl7-org:odr" xmlns:urn="urn:hl7-org:v3">
         <id assigningAuthorityName="CPR" extension="0312410968" root="1.2.208.176.1.2" />
      </ns:HasOrganDonorRegistrationRequest>
   </soapenv:Body>
</soapenv:Envelope>
Service response (digsig fjernet) 
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:sbf="urn:liberty:sb" xmlns:sbfprofile="urn:liberty:sb:profile" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
      <wsse:Security mustUnderstand="1" wsu:Id="security">
         <wsu:Timestamp wsu:Id="ts">
            <wsu:Created>2023-12-05T12:02:09Z</wsu:Created>
         </wsu:Timestamp>
         <ds:Signature>...</ds:Signature>
         <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509Token">MIIGjTCCBMGgAwIBAgIUOlR1nYh3hDt/KWi00ZcVw1K8l2IwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgMGsxLTArBgNVBAMMJERlbiBEYW5za2UgU3RhdCBPQ0VTIHVkc3RlZGVuZGUtQ0EgMTETMBEGA1UECwwKVGVzdCAtIGN0aTEYMBYGA1UECgwPRGVuIERhbnNrZSBTdGF0MQswCQYDVQQGEwJESzAeFw0yMzA1MTIwOTM2MDhaFw0yNjA1MTEwOTM2MDdaMIGjMSIwIAYDVQQDDBlOU1AgT0lPIElEV1MgU2lnbmluZyBUZXN0MTcwNQYDVQQFEy5VSTpESy1POkc6ZGUxZWM1OTgtODM5Ni00M2E1LWIwMTAtOTA3NjgyYWU2MmJlMR4wHAYDVQQKDBVTdW5kaGVkc2RhdGFzdHlyZWxzZW4xFzAVBgNVBGEMDk5UUkRLLTMzMjU3ODcyMQswCQYDVQQGEwJESzCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAI06LjXM1ke02o+F3VI4W1r3RCJPl8gjfmLzEFxvZx5OUzkYc0UXemRZSWxGyjhtknDKVtKjArGCClk+cqfk5OWX12NB1mLnBwOcpHQhJ26uBy3uPYr4W6SIGIshKy6kCv6tNzxY9GvX/cB1mVPMnelxNBsqIbWkpD6Rlthhlc1tNvEqVKfoDIkcweqzdCts58QuV71puIwZXntu0+mgfvED6zNLrz8R3vijhYocN6nkhUZODwUcdg3rGHN9VXeI0QNmkijOfqokGGshA9ZwkXiw3nu5PalpxoKIOyWjh24LjWjVS13Sw2PASQxZXTVRB7hgMX1nWVPOoLk+V4ZkySt+//4z+LdEN+uXWs8jbKY2ZsjF+t7/l2eKtBepmtuy+04F3m00Cqe3CCgMxPX/EB86zb2/V1UO7p+BTvsHNVpSqjwQKC850iCBzEaMeA4YLpA1+e7rAv1AHHV0pOwnKy22/LZQH4OQcrJeEQXxRyrK1GCqyUBCZnSD9bR08/0PQwIDAQABo4IBhjCCAYIwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR/KJ/ZcZlC4nXn1zV2Lk0IJW12XjB7BggrBgEFBQcBAQRvMG0wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYTEuY3RpLWdvdi5kay9vY2VzL2lzc3VpbmcvMS9jYWNlcnQvaXNzdWluZy5jZXIwJgYIKwYBBQUHMAGGGmh0dHA6Ly9jYTEuY3RpLWdvdi5kay9vY3NwMCEGA1UdIAQaMBgwCAYGBACPegEBMAwGCiqBUIEpAQEBAwcwOwYIKwYBBQUHAQMELzAtMCsGCCsGAQUFBwsCMB8GBwQAi+xJAQIwFIYSaHR0cHM6Ly91aWQuZ292LmRrMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jYTEuY3RpLWdvdi5kay9vY2VzL2lzc3VpbmcvMS9jcmwvaXNzdWluZy5jcmwwHQYDVR0OBBYEFDMlh3BrlddbtKMHmkVWJNMKDIpbMA4GA1UdDwEB/wQEAwIFoDBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlAwQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASADggGBAGfdz0E0LINiVnbjJa9SJnjBGfXmFzaAFuAvSoUQWakXmwsjbOBxHluI4vEEKAbYI79AIXW9kPAPbhCbHHWnybfGvtlksa5FXROKbLOEFIrZv36l123peQMy7pCFkGflTzdix7uYPNpVOmMD8eMt+TVWRyw24uixmleJK/Owl8Z9rIZFfsGACHGhJZh3Ek04HAsXqRFz/zTfYMJRGuhPRpkqtRznrjiGs55cFfB9250dHH/IJs4+0ZidNtdTqrbD54UYh7HRJI8Ha79MJVBOkfhWr37sKPoUyG9Ffvr1PmsaMt84Nir3UPcDoODjsDe35vj0kFrcNRjL09RFC0iEHrRMbMgJXOGE4Hv+T86F//eFc2/kBs8OaPGmQY+wrQLAv8DsCcuQLlax7xmlYItvp65AGdnyJjFZv8IZCtbzgCCNHqy7VaTolmNQvkjAy2qY7lYR6c0i3/A9dY8qkrCZncaFjJ9NpyvokPDbgQmgvSOBmmn4zQWIcoXfUE7wdrGc3Q==</wsse:BinarySecurityToken>
      </wsse:Security>
      <wsa:MessageID wsu:Id="messageID">0bfd008b-dd0e-4ddc-b8bc-c4820af11d12</wsa:MessageID>
      <wsa:RelatesTo wsu:Id="relatesTo">51a582da-cd3a-4cc1-9bc6-97a082df13e6</wsa:RelatesTo>
      <wsa:Action wsu:Id="action">http://sundhedsdatastyrelsen.dk/organdonor/2018/05/01#HasOrganDonorRegistration</wsa:Action>
      <sbf:Framework sbfprofile:profile="urn:liberty:sb:profile:basic" version="2.0" wsu:Id="sbf" />
   </SOAP-ENV:Header>
   <soap:Body wsu:Id="body">
      <ns3:HasOrganDonorRegistrationResponse xmlns:ns3="http://sundhedsdatastyrelsen.dk/organdonor/2018/05/01/" xmlns:ns2="urn:hl7-org:odr" xmlns:ns4="urn:hl7-org:v3" xmlns:ns5="urn:hl7-org:sdtc">
         <registrationExists>false</registrationExists>
      </ns3:HasOrganDonorRegistrationResponse>
   </soap:Body>
</soap:Envelope>

Og i svaret:

<registrationExists>false</registrationExists>

kan man så se, at denne borger ikke har nogen organdonorregistreringer (ikke i skrivende stund i hvert fald :)).

Subprofiler til OIO Identity Token Profile

Adgangsbilletten følger som ovenfor nævnt profilen fra OIO Identity Token profile. Den regulerer primært nogle af "hygiejne"-attributterne for adgangsbilletten (hvornår er den udstedt, i hvilket tidsrum er den gyldig, brugerens identitet etc.). Men faktisk er profilen ret åben, så den kan anvendes i mange forskellige sammenhænge i forskellige sektorer og domæner. De domæne- eller sektorspecifikke attributter skal "aftales mellem parterne", og det gør man typisk ved at udforme subprofiler til OIOITP. I skrivende stund er der følgende subprofiler:

  • OIOBPP (Basic Privilege Profile), der på sundhedsområdet pt. bruges til at kommunikere fuldmagter og basale privilegier fra SEB brugerstyringen. Subprofilen er udformet af Digitaliseringsstyrelsen og har til hensigt at kommunikere basale privilegier.
  • Blurring Instructions Profile (BIP), der anvendes til sløringsinstruktioner, altså når sundhedsfaglige skal optræde under pseudonym overfor den borger, der er logget ind.
  • (TODO: SRP (subject relations profile), der beskriver relationer til brugeren til f.eks. værge og forældre)

De subprofilerede attributter indlejres som Base64 encodede attributværdier i adgangsbilletten. I praksis betyder det, at 'afkodning' af de subprofilerede attributter sker i to trin:

  1. Base64 decode af attributværdien. Det giver nu XML i klartekst.
  2. Parse klartekst-XML'en og udtrække relevante dele til brug i web servicen.

Eksempel på attribut med 'Blurring Instructions'

Nedenstående figur illustrerer den subprofilerede attribut i relation til OIOITP adgangsbilletten.


Eksempel på BASE64 encoded blok med "Blurring Instructions" 
<?xml version="1.0" encoding="UTF-8"?>
<saml:Attribute
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	Name="urn:dk:healthcare:saml:attribute:BlurringInstructions"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

	<saml:AttributeValue xsi:type="xs:string">
		<!-- Slørings-oplysninger i Base64 encodet form. -->

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxiaXA6Qmx1cnJpbmdJbnN0cnVjdGlvbnMgeG1sbnM6YmlwPSJ1cm46ZGs6aGVhbHRoY2FyZTpzYW1sOmJsdXJyaW5nX2luc3RydWN0aW9uX3Byb2ZpbGU6MS4wIiBjdXItcmVudFNhbHQ9IjVrWlpMTlFNTklrejFZN3RDRGozR1E9PSI+DQoJPGJpcDpCbHVyRW1wbG95ZWVOYW1lc0Zyb21Pcmcgb3JnVHlwZT0iQ1ZSIiByZWFzb249ImZyb21fcmVsYXRlZF9wZXJzb24iPg0KCQkyOTE5MDkyNQ0KCTwvYmlwOkJsdXJFbXBsb3llZU5hbWVzRnJvbU9yZz4NCjwvYmlwOkJsdXJyaW5nSW5zdHJ1Y3Rpb25zPg==

	</saml:AttributeValue>

</saml:Attribute>
Eksempel på BASE64 decoded af den ovenstående BIP blok 
<?xml version="1.0" encoding="UTF-8"?>
<bip:BlurringInstructions xmlns:bip="urn:dk:healthcare:saml:blurring_instruction_profile:1.0" cur-rentSalt="5kZZLNQMNIkz1Y7tCDj3GQ==">
	<bip:BlurEmployeeNamesFromOrg orgType="CVR" reason="from_related_person">
		29190925
	</bip:BlurEmployeeNamesFromOrg>
</bip:BlurringInstructions>


Eksempel på 'Fuldmagt'

Billetomveksling Request - se linje 88-95:

Eksempel på billetomvekslingsrequest med fuldmagt (linje 88-95) 
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <soapenv:Header>
    <wsse:Security mustUnderstand="1" wsu:Id="security">
      <wsu:Timestamp wsu:Id="ts">
        <wsu:Created>2023-12-11T12:51:47Z</wsu:Created>
      </wsu:Timestamp>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#body">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>YQLi14dmrLuhLhMTyzRkYqTx3RM=</ds:DigestValue>
          </ds:Reference>
          <ds:Reference URI="#ts">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>7GcaNcRDx4qjgAjEI+yciXCxgb4=</ds:DigestValue>
          </ds:Reference>
          <ds:Reference URI="#messageID">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>8MBUk696j0wcRYLv/7DCWdspvo4=</ds:DigestValue>
          </ds:Reference>
          <ds:Reference URI="#action">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>3cXAhlhZH22NiSh7AttxKxBap7Q=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>Y5pz .... bCP9</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:X509Data>
            <ds:X509Certificate>MII .... KsAY=</ds:X509Certificate>
          </ds:X509Data>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
    <wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
    <wsa:MessageID wsu:Id="messageID">urn:uuid:5d0506c6-80c7-4511-b408-25b569805f13</wsa:MessageID>
  </soapenv:Header>
  <soapenv:Body wsu:Id="body">
    <wst:RequestSecurityToken Context="urn:uuid:75db436f-67df-442f-a9da-8c2d7a7a57f2">
      <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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_66833d00-89a4-45df-a7f6-8d5de95f4b8f" IssueInstant="2023-12-11T12:51:47Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
          <saml:Issuer>https://oio2bst-issuer.dk</saml:Issuer>
          <ds:Signature Id="OCESSignature">
			...
          </ds:Signature>
          <saml:Subject>
			...
          </saml:Subject>
          <saml:Conditions NotOnOrAfter="2023-12-11T14:51:46Z">
            <saml:AudienceRestriction>
              <saml:Audience>...</saml:Audience>
            </saml:AudienceRestriction>
          </saml:Conditions>
          <saml:AttributeStatement>
            <saml:Attribute Name="dk:gov:saml:attribute:SpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
              <saml:AttributeValue xsi:type="xs:string">DK-SAML-2.0</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="dk:gov:saml:attribute:AssuranceLevel" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
              <saml:AttributeValue xsi:type="xs:string">3</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="dk:gov:saml:attribute:CprNumberIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
              <saml:AttributeValue xsi:type="xs:string">0501792275</saml:AttributeValue>
            </saml:Attribute>
          </saml:AttributeStatement>
        </saml:Assertion>
      </wst14:ActAs>
      <wsp:AppliesTo>
        <wsa:EndpointReference>
          <wsa:Address>http://audience/clear</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:Claims Dialect="http://docs.oasis-open.org/wsfed/authorization/200706/authclaims">
        <auth:ClaimType Uri="dk:gov:saml:attribute:CprNumberIdentifier">
          <auth:Value>0501792275</auth:Value>
        </auth:ClaimType>
        <auth:ClaimType Uri="dk:healthcare:saml:attribute:OnBehalfOf">
          <auth:Value>urn:dk:healthcare:saml:actThroughProcurationBy:cprNumberIdentifier:1111111118</auth:Value>
        </auth:ClaimType>
      </wst:Claims>
    </wst:RequestSecurityToken>
  </soapenv:Body>
</soapenv:Envelope>

Billetomveksling Response - se linje 52-54:

Eksempel på billetomvekslingsrespons med fuldmagt i Identitytoken 
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <soapenv:Header>
    <wsse:Security mustUnderstand="1" wsu:Id="security">
      <wsu:Timestamp wsu:Id="ts">
        <wsu:Created>2023-12-11T12:51:47Z</wsu:Created>
      </wsu:Timestamp>
      <ds:Signature> ...
      </ds:Signature>
    </wsse:Security>
    <wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
    <wsa:MessageID wsu:Id="messageID">urn:uuid:6d79b0ba-9f42-4ffa-a1a9-e96599bd2427</wsa:MessageID>
    <wsa:RelatesTo wsu:Id="relatesTo">urn:uuid:5d0506c6-80c7-4511-b408-25b569805f13</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body wsu:Id="body">
    <wst:RequestSecurityTokenResponseCollection>
      <wst:RequestSecurityTokenResponse Context="urn:uuid:75db436f-67df-442f-a9da-8c2d7a7a57f2">
        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
        <wst:RequestedSecurityToken>
          <saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_5b8f9b84-0538-4fd0-bee3-b01c48abf371" IssueInstant="2023-12-11T12:51:47Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml:Issuer>TESTSTS</saml:Issuer>
            <ds:Signature Id="OCESSignature">
				...
            </ds:Signature>
            <saml:Subject>
              <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">dk:gov:saml:attribute:CprNumberIdentifier:0501792275</saml:NameID>
              <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
                <saml:SubjectConfirmationData NotOnOrAfter="2023-12-11T12:56:47Z" Recipient="http://audience/clear">
                  <ds:KeyInfo>
                    <ds:X509Data>
                      <ds:X509Certificate>MIIGiD .... hPKsAY=</ds:X509Certificate>
                    </ds:X509Data>
                  </ds:KeyInfo>
                </saml:SubjectConfirmationData>
              </saml:SubjectConfirmation>
            </saml:Subject>
            <saml:Conditions NotBefore="2023-12-11T12:46:47Z" NotOnOrAfter="2023-12-11T12:56:47Z">
              <saml:AudienceRestriction>
                <saml:Audience>http://audience/clear</saml:Audience>
              </saml:AudienceRestriction>
            </saml:Conditions>
            <saml:AttributeStatement>
              <saml:Attribute Name="dk:gov:saml:attribute:SpecVer" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">DK-SAML-2.0</saml:AttributeValue>
              </saml:Attribute>
              <saml:Attribute Name="dk:gov:saml:attribute:AssuranceLevel" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">3</saml:AttributeValue>
              </saml:Attribute>
              <saml:Attribute Name="dk:gov:saml:attribute:CprNumberIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">0501792275</saml:AttributeValue>
              </saml:Attribute>
              <saml:Attribute Name="dk:gov:saml:attribute:Privileges_intermediate" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8+PGJwcDpQcml2aWxlZ2VMaXN0IHhtbG5zOmJwcD0iaHR0cDovL2l0c3QuZGsvb2lvc2FtbC9iYXNpY19wcml2aWxlZ2VfcHJvZmlsZSI+PGJwcDpQcml2aWxlZ2VHcm91cCBTY29wZT0idXJuOmRrOmhlYWx0aGNhcmU6c2FtbDphY3RUaHJvdWdoUHJvY3VyYXRpb25CeTpjcHJOdW1iZXJJZGVudGlmaWVyOjExMTExMTExMTgiPjxicHA6UHJpdmlsZWdlPnVybjpkazpuc3BvcDpzdHM6Zm1rOnJlYWQ8L2JwcDpQcml2aWxlZ2U+PC9icHA6UHJpdmlsZWdlR3JvdXA+PC9icHA6UHJpdmlsZWdlTGlzdD4=</saml:AttributeValue>
              </saml:Attribute>
            </saml:AttributeStatement>
          </saml:Assertion>
        </wst:RequestedSecurityToken>
        <wsp:AppliesTo>
          <wsa:EndpointReference>
            <wsa:Address>http://audience/clear</wsa:Address>
          </wsa:EndpointReference>
        </wsp:AppliesTo>
        <wst:Lifetime>
          <wsu:Created>2023-12-11T12:46:47Z</wsu:Created>
          <wsu:Expires>2023-12-11T12:56:47Z</wsu:Expires>
        </wst:Lifetime>
      </wst:RequestSecurityTokenResponse>
    </wst:RequestSecurityTokenResponseCollection>
  </soapenv:Body>
</soapenv:Envelope>

Identitytoken (linje 52-54) BASE64 decoded - Overholder OIO Basic Privilege Profile:

Eksempel på BASE64 decoded af den ovenstående BIP blok 
<?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:1111111118">
        <bpp:Privilege>urn:dk:nspop:sts:fmk:read</bpp:Privilege>
    </bpp:PrivilegeGroup>
</bpp:PrivilegeList>

Hvad skal jeg gøre for at komme igang i forhold til NSP test og produktionsmiljøerne?

Der skal indgås flere ’aftaler’ med SDS for at komme igennem det samlede flow:

  1. En sundhedsdatanetaftale og tilsvarende tilslutning. Skal bruges før services kan nås i produktionsmiljøerne. Du kan nå NSP Test-miljøerne via internettet, men det er en god idé at få det på plads med det samme. Se mere om Sundhedsdatanetaftaler her: https://services.nsi.dk/OmNSIservices/supportingServices/omSDN
  2. En generel aftale om anvendelse af NSP (NSP serviceaftale). https://www.nspop.dk/display/Web3/Mine+aftaler. Kræver login – hvis du ikke har et login, så er der vejledning til at kontakte support på siden.
  3. En ’whitelistning’ af det (eller de) system(er), som anvender STS’ens vekslingsløsning. https://www.nspop.dk/category/sup. Der skal whitelistes til både Test og Produktion.

    Beskriv at det drejer sig om whitelistning ift. STS. Du skal i processen være klar til at give oplysninger om det kaldende system mv. Her finder du et linkt til bestillingssiden: https://www.nspop.dk/display/resources/BST2IDWS+Borgerbilletomveksling. Hvis det rigtige "audience" ikke findes på listen, skal du bestille det via NSP support systemet her: https://www.nspop.dk/category/sup.

IDWS fra en App kontekst (Rest, Open ID Connect)

  1. Hvis I bruger JWT, så skal jeres OpenID Connect (OIDC) JWT udsteder være ”trusted” af STS’en.

Appendiks 1 - Centrale Begreber i IDWS

Begreb / TermAkronymAKATypeBeskrivelseOIOIDWS Eksempel
Service ProviderSP

Applikation/App

Klient

Portal

Komponent

Komponent (web-portal eller klient/app) som stiller en service til rådighed for brugerensundhed.dk
Web Service ConsumerWSC

Applikation

Tjenesteforbruger

Tjenesteaftager

Komponent eller

Rolle

Generelt: komponent som kalder en identitetsbaseret web service.

I denne kontekst: teknisk komponent - typisk er en del af en applikation - som har brug for at kalde en eller flere identitetsbaserede web services for at behandle en borgers sundhedsdata. 

sundhed.dk (backend)
Web Service ProviderWSPTjenesteudbyder

Komponent eller 

Rolle

Generelt: teknisk komponent som udstiller en (eller flere) identitetsbaseret web services.

I denne kontekst: teknisk komponent, som udstiller sundheds-data og -funktionalitet via identitetsbaserede web services.

FMK?
Identity ProviderIdP

Logintjeneste

Login service

SSO service

Komponent

Komponent som udstiller en login- og Single-Sign-On (SSO) service til brugerne.

En login service er en IT-tjeneste som tillader brugere at identificere og autentificere sig over for applikationer.

I denne kontekst er der to login services: 
•    NemLogin Identity Provider (NL IdP) - som udbydes sammen med MitID
•    Sundhedsvæsenets Elektroniske Brugerstyrings Identity Provider (SEB IdP)

Nem Login
Security Token ServiceSTS
Komponent

Komponent/tjeneste som udstiller en service der tillader andre komponenter at anmode om adgangsbilletter til at kalde diverse identitetsbaserede web services. STS'er er tjenester som WSC'er vælger at have tillid til. Når en WSP modtager en adgangsbillet kan de kryptografisk kontrollere at adgangsbilletten er udstedt af en STS, som de stoler på, og dermed kan de stole på de oplysninger, der står i adgangsbilletten - eller i hvert fald de oplysninger i billetten, som STS'en har valideret/verificeret.

Tillid baseres typisk på PKI infrastruktur gennem udstedelse af PKI nøgler og distribution af certifikater. Hvis der ikke var STS'er, ville hver WSP skulle kende certifikater for alle hver mulig WSC, hvilket hurtigt bliver en uoverskuelig administrativ byrde, især når nøgler og certifikater løbende skal udskiftes. Der vil typisk være langt færre STS'er end der er WSC'er og WSP'er. Så længe WSC'en kan præsentere en adgangsbillet udstedt af en STS som WSP'en stoler på så godtages og behandles kaldet. Der kan stadig være regler eller anden logik, håndhævet af WSPen, som gør at servicen ikke kan foretage den efterspurgte databehandling, men uden en adgangsbillet fra en passende STS, afvises kaldet blankt.

Kald til en STS omtales ofte som "billetomveksling". I billetomvekslingskaldet til STS'en fremsætter WSC'en en række "claims": "brugeren hedder ...", "brugeren optræder i rollen som ...", "brugerens CPR-nr. er ..." osv. Nogle af disse claims kan STS'en validere hos autoritative registre og sætter dem ind i adgangsbilletten efter validering, andre må STSen sætte på adgangsbilletten uden at kunne verificere eller validere dem. Det er alle parter i "netværket" klar over, og har underskrevet en aftale om. I aftalen vil der typisk også være indskrevet krav til parterne om kontrol, inspektion, stikprøvekontrol, audit osv. så alle, der er med i "netværket" deltager på et passende sikkert og ensartet grundlag. Disse aftalebaserede netværk omtales også som føderationer.

Læs evt. mere om STS'er her: https://en.wikipedia.org/wiki/Security_token_service

STSen? hedder den noget andet også?
Bootstrap TokenBSTIdentitetsbilletArtefakt

Et bootstrap token (BST) udstedes i forbindelse med brugerens login/autentifikation og indeholder bl.a. 

  • information om brugens identitet
  • en liste af de STS'er som har lov til at udstede adgangsbilletter på baggrund af BST'en
  • en time-to-live som specificere hvor længe BST'en er gyldig

Teknisk er et BST i OIO sammenhæng en lille stump maskinlæsbar tekst som overholder attribut-profilerne specificeret i OIO SAML. 

I web SSO scenariet bliver BST udstedt (og signeret) af den IdP som autentificere brugeren. Det returneres som en attribut i SAML authentication assertionen. I App scenariet får klienten BST på en anden måde.

Som det fremgår er BST'er en helt afgørende del af inputtet til en billetomveksling. Det er netop BST'erne, der gør det muligt at binde adgangsbilletter til login sessionen. BST er dermed en parameter i WS-Trust kaldet, som beskrevet i OIO WS-Trust profile.

Eksempel på en BST indlejret i en OIO SAML 3.0 assertion:

<Attribute Name="https://data.gov.dk/model/core/eid/bootstrapToken" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
  <AttributeValue>
    <!--- Embedded bootstrap token as base64 -->
    AK24bWw...
  </AttributeValue>
</Attribute>



Identity Token

Adgangsbillet

Access Token

SAML Identity Token

Security Token

Artefakt

Adgangsbillet som tillader en given WSC at kalde en given service hos en given WSP i kontekst af en given bruger (identitet / subject). Hver gang der ovenfor er skrevet 'adgangsbillet' kunne man ligesåvel have skrevet 'Identity Token'. 

En adgangsbillet er et stykke maskinlæsbar tekst, der bl.a. indeholder.

  • Identifikation af brugeren 
  • andre attributter, der i et eller andet omfang udtaler sig om brugeren, f.eks. at vedkommende har fuldmagt til at se udvalgte dele af en anden borgers sundhedsdata
  • Applikationen (WSCen) der må benytte billetten
  • Servicen som billetten er udsted til (Audience)

 I OIOIDWS regi er en adgangsbillet en SAML Identity Token som overholder OIO SAML profilen for Identity Tokens. 


Audience


Koncept

Den tiltænkte modtager at et identitetsbaserede web service kald. Kodet ind i den adgangsbillet der udstedes til netop det kald. WSP'er der modtager en adgangsbillet til et andet 'audience' skal per konvention afvise kaldet.


Omveksling

Billetomveksling

Token Exchange

Koncept

Den process hvor en WSC anmoder on udstedelse af en adgangsbillet.


Tillid

Trust

Koncept

Tillid er en parts villighed til at udføre en handling baseret på partens forhold til en anden part.

Trust reguleres i sidste instans gennem aftaler, der specificerer krav og forventninger til bl.a. løbende kontrol, stikprøvekontrol og audit. De parter, der indgår i et tillidsnetværk omtales undertiden også som føderationsparter. Se også 'føderation'.


Føderation

Federation

Koncept

En gruppering af parter, der har indgået aftale om at leve op til en række krav til kontrol, adfærd og samarbejde med de øvrige førderationsparter. Føderationen og føderationsaftalerne har til hensigt at sikre ensartet højt niveau af sikkerhed og proceskontrol, så alle parter i føderationen kan have tillid til hinanden.