(-- KaareKjelstroem - 20 Jan 2006)

Security Assertions Markup Language (SAML) er en XML specifikation fra OASIS (Organization for the Advancement of Structured Information Standards). SAML definerer rammerne for udveksling af sikkerhedsinformation (f.eks. autentifikation, rettigheder og attributter) mellem it-systemer, noget der typisk involverer check af akkreditiver som brugernavn/password eller digitale certifikater. Specifikationen favner en række forskellige brugsscenarier og det er nødvendigt at tilpasse SAML til den konkrete situation.

SAML forsøger ikke at standardisere samtlige aspekter af identitsstyring, men addresserer udelukkende hvordan identitetsinformation kan udveksles mellem to domæner på en sikker måde. En komplet identitsstyringsløsning skal desuden definere mekanismer til håndtering af provisioning dvs. oprettelse og håndtering af brugerkonti med privilegier, autentifikation, samt autorisation. SOSI-projektets ambition er også at favne provisioning og autentifikation, men lader autorisation være op til de enkelte serviceprovidere på baggrund af SAML attributter.

SAML er en platformneutral specifikation, der bortabstraherer den faktiske implementation og arkitektur. Ved at basere SOSI på SAML opnår vi derfor at serviceudbydere frit kan vælge den underliggende software og hardwareplatform. SAML giver desuden en løs kobling, der ikke kræver at alle brugere kendes af samtlige parter i netværket. Endelig dækker SAMLs attributbegreb netop det behov vi har i SOSI for et ID kort, der kan benyttes til SSO.

Version 1.0 af SAML specifikationen blev vedtaget i november 2002 og siden er den udkommet i en opdatering v1.1 samt den nye v2.0 i marts 2005, der retter sikkerhedsbrist og introducerer yderligere sikkerhedsfaciliteter samt single logout.

5.1 Elementer i SAML

SAML er opbygget af et antal overordnede elementer: assertions, protocols, bindings og profiles der alle er beskrevne via XML schemaer:

5.1.1 Assertions, statements og principals

SAML core specifikationen definerer strukturen for - og indholdet af assertions, som igen definerer statements om en principal dvs. en person / bruger, der kan autentificeres. Assertions udstedes af en IdP efter at denne har autentificeret brugeren.

SAML definerer 3 forskellige typer af statements:

• Authentication: Det subjekt, en assertion omhandler blev autentificeret på et givet tidspunkt med en given mekanisme (password, X509, ...)
• Authorization Decision: Subjektet har tilladelse til - eller forbud mod at tilgå en bestemt ressource.
• Attribute: Subjektet er associeret med følgende attributter

Assertions kan signeres med digitale certifikater, kan være underlagt betingelser (conditions) under hvilke de er valide og være tilknyttet beskrivelser (advice) af hvorfor en given assertion blev udstedt.

I SOSI projektet vil assertions spille rollen som ID-kort.

5.1.2 Protokoller

SAML definerer et antal forskellige request-response protokoller, der bla giver en klient mulighed for at kommunikere med en SAML autoritet med henblik på at:

• Modtage en eller flere assertions om en bruger
• Bede om at få autentificeret en bruger og modtage det tilhørende autentifikationsdata.
• Bede autoriteten om at bruge et angivet pseudonum for brugeren ved efterfølgende kommunikation
• Foretage næsten-realtids logout af et sæt relaterede brugersessioner, såkaldt single-logout.
• ...

Når SAML autoriteten modtager en af disse forespørgsler sender den et svar tilbage. Hvis forespørgslen var OK (ingen syntaksfejl og brugeren kunne autentificeres eller var det allerede) indeholder svaret de assertions der passer til.

5.1.3 Bindings

SAML protokoller er abstrakte beskrivelser af beskeder der udveksles, deres rækkefølge mm. En binding er en konkret realisering af disse protokoller over faktiske kommunikationskanaler. SAML SOAP bindingen definerer f.eks. hvordan SAML information kan udveksles i SOAP beskeder.

5.1.4 Profiles

SAML specifikationen er tænkt til at understøtte mange forskellige brugsscenarier og giver derfor en stor grad af fleksibilitet i hvordan beskeder kan sammensættes. Desværre er stor frihed og interoperabilitet modsatte størrelser og SAML definerer derfor profilbegrebet.

En SAML profil er et sæt begrænsninger og udvidelser til SAML kernen der anvendes i et bestemt deploymentscenario. Parter, der ønsker at indgå i en føderation behøver ikke enes om at understøtte hele SAML specifikationen, men kan nøjes med at implementere en bestemt profil. En profil defineres således ved at anvende et sæt bindings, protokoller og assertions.

SOSI anvender sin egen SOAP-baserede profil for services i en Service-Orienteret Arkitektur.

5.2 SAML og SOSI

En konkret anvendelse af SAML, der definerer hvilken profil, hvilke message-flow-protokoller og hvilke bindings der benyttes kaldes en SAML v2.0 feature (se Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0). Nedenstående matrix definerer SOSIs SAML features:

Profile	Message flow protocol	Binding
SOSI SOAP	<AuthnRequest> fra klient til IdP	SOAP
SOSI SOAP	IdP <Response> til klient	SOAP

I SOSI etableres ikke sessioner mellem IdP'en og serviceprovidere idet ID-kortet medsendes på samtlige forespørgsler. Der er derfor ikke brug for en Single-Logout mekanisme.

5.2.1 SOSI SOAP Profile

SOSI benytter SOAP til transport at både SAML protokol beskeder og SAML attributes i efterfølgende web service kald. OASIS definerer ikke en SOAP SAML profil, som beskriver interaktionen mellem service udbyder, IdP og service aftager. Dette afsnit råder bod på denne mangel ved at beskrive en sådan SOAP SAML profil.

SAML profiler skal overholde en række krav, defineret i Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 s. 10:

"This section provides a checklist of issues that MUST be addressed by each profile.

1. Specify a URI that uniquely identifies the profile, postal or electronic contact information for the author, and provide reference to previously defined profiles that the new profile updates or obsoletes.
2. Describe the set of interactions between parties involved in the profile. Any restrictions on applications used by each party and the protocols involved in each interaction must be explicitly called out.
3. Identify the parties involved in each interaction, including how many parties are involved and whether intermediaries may be involved.
4. Specify the method of authentication of parties involved in each interaction, including whether authentication is required and acceptable authentication types.
5. Identify the level of support for message integrity, including the mechanisms used to ensure message integrity.
6. Identify the level of support for confidentiality, including whether a third party may view the contents of SAML messages and assertions, whether the profile requires confidentiality, and the mechanisms recommended for achieving confidentiality.
7. Identify the error states, including the error states at each participant, especially those that receive and process SAML assertions or messages.
8. Identify security considerations, including analysis of threats and description of countermeasures.
9. Identify SAML confirmation method identifiers defined and/or utilized by the profile.
10. Identify relevant SAML metadata defined and/or utilized by the profile."

Dette dokument adresserer allerede en stor del af disse punkter og det er nok at fokusere på punkterne 1, 2, 7, 9 og 10.

5.2.1.1 Required Information

Identification: urn:???:names:tc:SAML:2.0:profiles:SSO:SOSI

Contact information: sosiprofilecomment@Xsosi.dk (Spamforhindring: fjern X. Adressen relayer pt. til JanRiis og KaareKjelstroem )

SAML Confirmation Method Identifiers: Denne profil benytter følgende SAML V2.0 confirmation methods: Holder-of-key urn:oasis:names:tc:SAML:2.0:cm:holder-of-key samt Sender-vouches urn:oasis:names:tc:SAML:2.0:cm:sender-vouches.

Description: Se nedenfor

Updates: Protokollen er ny og opdaterer ikke en tidligere version.

5.2.1.2 Profile overblik

Hele profilen bruger SOAP bindingen (urn:oasis:names:tc:SAML:2.0:bindings:SOAP) til at kommunikere beskeder.

1. AuthnRequest fra Web Service Consumer til IdP: Web Service Consumeren foretager SOAP over HTTP POST til IdP'en indeholdende en <AuthnRequest> besked for den bruger der skal have udstedt et ID-kort.
2. Response fra IdP til Web Service Consumer: IdP'en sender et SOAP response indeholdende SAML <Response> beskeden. Hvis login lykkes vil beskeden indeholde en SAML-assertion. Hvis ikke, vil den indeholde en <StatusCode> der angiver hvorfor der ikke kunne logges på.
3. SOAP request fra Web Service Consumer til Web Service Provider: I efterfølgende SOAP-kald medsendes brugerens SAML-assertion i SOAP headeren som beskrevet i Webservices i SOSI.
4. SOAP response fra Web Service Provider til Web Service Consumer: SOAP-responsebeskeden indeholder Web Service Providerens svar i SOAP body samt SOSI specifikke data som beskrevet i Webservices i SOSI.

5.2.1.3 Profile beskrivelse

Profilen inititeres altid af Web Service Consumeren. I beskrivelsen nedenfor refereres der til:

Single Sign-On Service: Dette er det authentication-request-protokol-endpoint hos IdP'en, der kan modtage <AuthnRequest> kald.

Assertion Consumer Service: Det authentication-request-protokol-endpoint hos Web Service Consumeren, der kan modtage <Response> svar.

5.2.1.3.1 <AuthnRequest> sendes fra Web Service Consumer til IdP

SOSI benytter kun een IdP og der indgår derfor ikke noget skridt hvori denne udvælges. Protokollen kan dog let udvides hvis dette skulle blive en nødvendighed i fremtiden.

Web Service Consumeren starter med at danne en SOAP <AuthnRequest> besked, som sendes via HTTP POST binding til IdP'ens Single Sign-On Service. Udvekslingen af beskeder foregår altid over (mindst) en SSL 3.0 eller TLS 1.0 krypteret linje.

IdP'en skal behandle <AuthnRequest> beskeden som beskrevet i SAML core specifikationen og præciseret i detalje i sektion 5.2.1.4 nedenfor.

5.2.1.3.2 IdP identificerer brugeren

Identityprovideren identificerer om muligt brugeren via de medsendte akkreditiver og udsteder et SOSI ID-kort. IdP'en autentificerer altid brugeren uanset om denne er set tidligere og udsteder altid et nyt ID-kort.

5.2.1.3.3 IdP sender <Response> til Web Service Consumeren

Uagtet om brugeren kunne identificeres eller ej danner IdP'en en <Response> besked som sendes direkte tilbage til Web Service Consumeren som svar på HTTP POST kaldet. Det er med andre ord ikke tilladt IdP'en at initiere et HTTP POST eller på anden måde levere svaret asynkront til Web Service Consumeren. Bemærk også, at da der er tale om en synkron request-respons-model skal IdP'ens processering af <AuthnRequest> beskeden være kortvarig.

Web Service Consumeren gemmer de SAML attributter der er indlejret i <Response> beskeden og som udgør SOSI ID-kortet, til senere brug.

SAML specifikationen definerer et sæt mulige fejlkoder, der kan kvalificere en <Response> besked. Hvis logon ikke kan gennemføres returneres i stedet et SAML Response med statuskoder som beskrevet i SAML core specifikationen sektion 3.4.1.4.

5.2.1.3.4 Web Service Consumeren sender besked til Web Service Provideren

Web Service Consumeren danner nu sin serviceforespørgsel i form af en "Den Gode Web Service"-konvolut, indlejrer ID-kortet i SOAP headeren og sender det hele til Web Service Provideren via HTTP POST over en TLS/SSL-krypteret linje.

5.2.1.3.5 Web Service Provider udfører service eller afviser kald

Web Service Provideren verificerer beskedens integritet, trækker ID-kortet ud af SOAP-beskeden og verificerer dets gyldighed. På baggrund af oplysningerne i ID-kortet autoriseres brugeren nu til at kalde servicen om muligt eller afvises.

5.2.1.4 Anvendelse af Authentication Request protokollen

Denne profil er baseret på Authentication Request protokollen, defineret i SAML core specifikationen sektion 3.4. SAML core definerer en række roller for autentifikationen. SOSI kvalificerer disse yderligere:

Requester: Det afsendersystem, der danner en <AuthnRequest> og sender den til IdP'en.

Presenter: Den der fremviser et <AuthnRequest>. I SOSI, synonym med Requester

Requested Subject: Den bruger om hvem der skal udstedes et ID-kort.

Attesting Entity: Den der fremviser en assertion. I SOSI, synonym med Requester

Relying Party: Serviceudbyderen

Identity Provider: IdP'en.

5.2.1.4.1 Brug af <AuthnRequest>

Før et ID-kort kan udstedes må den faktiske bruger identificeres, hvilket foregår ved at der foretages et <AuthnRequest> kald til IdP'en. For autenticitetssikring på niveau 1 har afsendersystemet ikke nogen bruger tilknyttet kaldet og må her nøjes med at underskrive beskeden med sin systemnøgle. I praksis svarer dette til at IdP'en udsteder et system ID-kort.

Anvendes niveau 2 af autenticitetssikring har brugeren ikke anvendt et OCES certifikat ved pålogning at afsendersystemet og en reference til dette kan dermed ikke sendes med, ligesom der ikke kan dannes en bruger-signatur. I stedet sendes brugerens CPR-nummer i <KeyName> feltet. IdP'en verificerer systemsignaturen og udsteder et bruger ID-kort.

For autenticitetssikring på niveau 3 signeres <AuthnRequest> beskeden med brugerens private OCES nøgle og IdPen kan nu foretage autentifikationen ved at verificere brugerens signatur. På disse niveauer medsendes systemets unikke ID (CVR-...UID-...) direkte og der foretages ikke systemsignering af beskeden.

I SOSI er niveau 4 autentifikation identisk med niveau 3 bortset fra at certifikaterne er kvalificerede. Da OCES certifikater ikke kan være kvalificerede understøtter de dermed ikke SOSI niveau 4.

I SOSI tillades det også at et system beder om et ID-kort, noget der f.eks. anvendes hvis en serviceaftager eksplicit beder en serviceudbyder om uafviselighed for behandlingen af en forespørgsel. I dette tilfælde anvendes altid systemets OCES certifikat og der er ingen bruger involveret.

Eksemplet nedenfor viser en <AuthnRequest> besked for niveau 3+4:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope 
    xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
    soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"          
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
>  
  <soap:Body>
    <samlp:AuthnRequest 
         xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
         xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:protocol" 
         IssueInstant="2005-12-29T21:44:00Z" 
         Version="2.0" 
         ID="eb529fec-6498-11d7-b236-000629ba5445" 
         ForceAuthn="true" 
         ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 
         ProviderName="urn:ribamt.dk:emp" 
         Consent="urn:oasis:names:tc:SAML:2.0:consent:implicit" >
      <!-- Reference til afsendersystemets certifikat (identifikation af afsenderen) -->
      <saml:Issuer NameQualifier="emp">CVR-...UID-...</saml:Issuer>
      <!-- Brugerens digitale signatur af AuthnRequest beskeden -->
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#eb529fec-6498-11d7-b236-000629ba5445">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>oYEdQYG1IHzbkR1UcJ9Q5VriRPs=</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:KeyName>CVR:....-RID:....</ds:KeyName>
        </ds:KeyInfo>
      </ds:Signature>     
      <!-- Niveau 3+4 autentifikation: Oplysninger om den bruger der skal autentificeres, inklusive reference til dennes certifikat via cvr-rid -->
      <saml:Subject>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
          <saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
            <ds:KeyInfo>
              <ds:KeyName>CVR...-RID...</ds:KeyName>
            </ds:KeyInfo>
          </saml:SubjectConfirmationData>
        </saml:SubjectConfirmation>         
      </saml:Subject>          
      <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName"/>
      <saml:Conditions NotOnOrAfter="2005-12-29T21:49:00Z"/>                  
    </samlp:AuthnRequest>
  </soap:Body>
</soap:Envelope>

Det følgende eksempel viser en niveau 2 autentifikation, hvor brugeren er angivet med CPR-nummer i <KeyName>. Bemærk at der ikke er tilknyttet en brugerspecifik signatur.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope 
  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
  soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#">  
  <soap:Body>
    <samlp:AuthnRequest 
         xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
         xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:protocol U:\docs\library\SAML\saml-schema-protocol-2.0.xsd" 
         IssueInstant="2005-12-29T21:44:00Z" 
         Version="2.0" 
         ID="eb529fec-6498-11d7-b236-000629ba5445" 
         ForceAuthn="true" 
         ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 
         ProviderName="urn:ribamt.dk:emp" 
         Consent="urn:oasis:names:tc:SAML:2.0:consent:implicit" >
      <!-- Reference til afsendersystemets certifikat (identifikation af afsenderen) -->
      <saml:Issuer NameQualifier="emp">CVR-...UID-...</saml:Issuer>
      <!-- Niveau 1+2 autentifikation: Oplysninger om den bruger der skal autentificeres i form af CPR nummer -->
      <saml:Subject>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
          <saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
            <ds:KeyInfo>
              <ds:KeyName>0519221234</ds:KeyName>
            </ds:KeyInfo>
          </saml:SubjectConfirmationData>
        </saml:SubjectConfirmation>         
      </saml:Subject>          
      <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName"/>
      <saml:Conditions NotOnOrAfter="2005-12-29T21:49:00Z"/>                  
    </samlp:AuthnRequest>
    <!-- Afsendersystemets digitale signatur af AuthnRequest beskeden -->
    <ds:Signature>
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <ds:Reference URI="#eb529fec-6498-11d7-b236-000629ba5445">
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <ds:DigestValue>VBG8jFkDkvPBEgJXBLaVkHf6oK5i=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>
        NFAnBZLz/jOaG4RVdBKBKpB5q27OqBhi9NW9n4b5mHhBpoJXKDt8sVF3nT3aRlWklYCyzNO6fiUYqWEJcNFJmFHs
        /9lsORK10zjnZjBi8kI1QVBG8jFkDkvPBEgJXBLaVkHf6oK5iVDUaBY+CxbXfPWo qB0JItwbcDnc8Aj6Od0=
      </ds:SignatureValue>
      <ds:KeyInfo>
        <ds:KeyName>CVR:....-UID:....</ds:KeyName>
      </ds:KeyInfo>
    </ds:Signature>  
  </soap:Body>
</soap:Envelope>

Endelig viser følgende eksempel hvordan forespørgslen til udstedelse af et system ID-kort ser ud. Her er der ikke nogen slutbruger involveret og da signaturen af konvolutten og <AuthnRequest> er semantisk ækvivalente er den sidstnævnte udeladt.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope 
  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
  soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"          
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#">  
  <soap:Body>
    <samlp:AuthnRequest 
         xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
         xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:protocol U:\docs\library\SAML\saml-schema-protocol-2.0.xsd" 
         IssueInstant="2005-12-29T21:44:00Z" 
         Version="2.0" 
         ID="eb529fec-6498-11d7-b236-000629ba5445" 
         ForceAuthn="true" 
         ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 
         ProviderName="urn:ribamt.dk:emp" 
         Consent="urn:oasis:names:tc:SAML:2.0:consent:implicit" >
      <!-- Reference til afsendersystemets certifikat (identifikation af afsenderen) -->
      <saml:Issuer NameQualifier="emp">CVR-...UID-...</saml:Issuer>
      <!-- Systemets digitale signatur af AuthnRequest beskeden -->
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#eb529fec-6498-11d7-b236-000629ba5445">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>oYEdQYG1IHzbkR1UcJ9Q5VriRPs=</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:KeyName>CVR:....-UID:....</ds:KeyName>
        </ds:KeyInfo>
      </ds:Signature>     
      <!-- Systemautentifikation til udstedelse af SOSI system ID-kort. Brugeren er et system. -->
      <saml:Subject>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
          <saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
            <ds:KeyInfo>
              <ds:KeyName>CVR...-UID...</ds:KeyName>
            </ds:KeyInfo>
          </saml:SubjectConfirmationData>
        </saml:SubjectConfirmation>         
      </saml:Subject>          
      <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName"/>
      <saml:Conditions NotOnOrAfter="2005-12-29T21:49:00Z"/>                  
    </samlp:AuthnRequest>
  </soap:Body>
</soap:Envelope>

Semantikken for elementerne i en SOSI <AuthnRequest> forespørgsel er defineret nedenfor. De enkelte elementer og attributter er speciferede som XPath udtryk:

• /AuthnRequest@IssueInstant Lokal tid hos klienten, hvor IdPen lavede AuthnRequest beskeden
• /AuthnRequest@Version For SAML 2.0 er værdien "2.0"
• /AuthnRequest@ID Globalt unikt ID for denne forespørgsel. I SOSI benytter vi GUIDs.
• /AuthnRequest@ForceAuthn Altid TRUE, hvilket betyder at IdP'en ALTID skal autentificere brugeren på ny.
• /AuthnRequest@Consent I SOSI altid urn:oasis:names:tc:SAML:2.0:consent:implicit, angivende at brugeren tidligere har afgivet sit samtykke til at certifikatet anvendes.
• /AuthnRequest@IsPassive Anvendes ikke. Defaulter til FALSE
• /AuthnRequest@AssertionConsumerServiceIndex Anvendes ikke. Request og Presenter er en og samme.
• /AuthnRequest@AssertionConsumerServiceURL Anvendes ikke. Svaret returneres altid synkront til requester.
• /AuthnRequest@ProtocolBinding Den protokol, der skal anvendes til at returnere <Response> beskeden. I SOSI tillades kun SOAP bindingen urn:oasis:names:tc:SAML:2.0:bindings:SOAP.
• /AuthnRequest@AttributeConsumingServiceIndex Anvendes ikke. SOSI ID-kort indeholder altid det totale sæt oplysninger der er til rådighed om en bruger.
• /AuthnRequest@ProviderName En menneskeligt læselig tekststreng, der angiver navnet på klienten. Anvendes ikke til egentlig identifikation, men kan f.eks. bruges til logningsformål.
• /AuthnRequest/Issuer Dette felt anvendes til at angive afsenderens unikke id CVR-...UID-... og via NameQualifier attributten hvilket system hos afsenderen, der lavede AuthnRequest beskeden. Et systemcertifikat forventes således at kunne genbruges af flere applikationer hos samme organisation.
• /AuthnRequest/Issuer@NameQualifier Anvendes til at angive et navn der er lokalt unikt for en serviceaftager, f.eks. "EPM", "EMS", "Booking", etc. Sammen med /AuthnRequest/Issuer feltets værdi giver dette et globalt unikt ID for afsenderen.
• /AuthnRequest/Subject Den bruger der skal autentificeres. I SOSI er dette et påkrævet element.
• /AuthnRequest/Subject/SubjectConfirmation Skal angives.
• /AuthnRequest/Subject/SubjectConfirmation@Method Angiver hvordan en bruger autentificeres. SOSI tillader Holder of Key urn:oasis:names:tc:SAML:2.0:cm:holder-of-key samt Sender-vouches urn:oasis:names:tc:SAML:1.0:cm:sender-vouches. Se afsnittet om Autenticitet på niveau 2 for en diskussion af sikkerhedsimplikationerne af dette valg.
• /AuthnRequest/NameIDPolicy Angiver hvordan bruger-id repræsenteres. I SOSI er dette et påkrævet element.
• /AuthnRequest/NameIDPolicy@SPNameQualifier Anvendes ikke
• /AuthnRequest/NameIDPolicy@AllowCreate IdPen har lov til at oprette brugeren internt, hvis denne ikke findes i forvejen.
• /AuthnRequest/NameIDPolicy@Format SOSI anvender digitale signaturer og brugernavnet er i disse angivet i certifikatets Subject DN. Værdien af Format attributten er derfor altid urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
• /AuthnRequest/Conditions Elementet anvendes kun til at angive udløbstid for forespørgslen. Andre conditions anvendes ikke.
• /AuthnRequest/Conditions@NotBefore Anvendes ikke
• /AuthnRequest/Conditions@NotOnOrAfter Sættes til nuværende tid T+5 minutter.
• /AuthnRequest/RequestedAuthnContext I SOSI initieres <AuthnRequest> kald altid af requester og dette element er derfor ikke meningsfyldt. ID-kortet indeholder en fast mængde information som en service provider kan benytte til at kvaliteten af brugerens autentifikation.
• /AuthnRequest/Scoping I SOSI er der kun een identity-provider og requester og presenter er en og samme. Dette element anvendes derfor ikke

5.2.1.4.2 Brug af <Response>

Hvis der ikke lykkedes at autentificere brugeren (eller systemet) skal IdP'en returnere en <Response> besked hvori der ikke må indgå nogen Assertions og hvori der skal specificeres hvad der gik galt via <StatusCode> samt hvorfor via <StatusMessage>. Valide værdier for <StatusCode> er defineret i SAML-core specifikation, mens <StatusMessage> indeholder en besked på dansk, der kan fremvises til en slutbruger.

Eksemplet nedenfor viser resultatet af en mislykket autentificering på niveau 3 eller 4

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">  
  <soap:Body>
    <samlp:Response 
         xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
         xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:protocol U:\docs\library\SAML\saml-schema-protocol-2.0.xsd"
         IssueInstant="2005-12-29T21:46:00Z" 
         Version="2.0" 
         ID="faf32100-6498-11d7-c226-0a9d76001bef"    
         >
      <saml:Issuer>http://www.sundhed.dk/sosi/sso</saml:Issuer>
      <!-- IdP'ens digitale signatur af Response beskeden -->
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#faf32100-6498-11d7-c226-0a9d76001bef">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>oYEdQYG1IHzbkR1UcJ9Q5VriRPs=</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:KeyName>CVR:....-UID:....</ds:KeyName>
        </ds:KeyInfo>
      </ds:Signature>     
      <!-- Status for hvordan autentifikationen forloeb -->
      <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/>
        <samlp:StatusMessage>Det angivne certifikat er spærret</samlp:StatusMessage>
      </samlp:Status>
    </samlp:Response>
  </soap:Body>
</soap:Envelope>

Lykkedes det IdP'en at autentificere brugeren returneres en <Response> besked, hvori følgende elementer skal angives:

• <Issuer> elementet skal indeholde IdP'ens unikke id som CVR-...UID-... samt et internt ID i NameQualifier.
• Det skal indeholde et SOSI ID-kort som SAML assertions.
• <StatusCode> skal have værdien urn:oasis:names:tc:SAML:2.0:status:Success

Eksemplet nedenfor viser resultatet af en vellykket autentificering på niveau 3 (eller 4 hvis certifikatet er kvalificeret og dermed ikke OCES):

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">  
  <soap:Body>
    <samlp:Response 
         xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
         xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:protocol U:\docs\library\SAML\saml-schema-protocol-2.0.xsd"
         IssueInstant="2005-12-29T21:46:00Z" 
         Version="2.0" 
         ID="faf32100-6498-11d7-c226-0a9d76001bef"    
         >
      <saml:Issuer>http://www.sundhed.dk/sosi/sso</saml:Issuer>
      <!-- IdP'ens digitale signatur af Response beskeden -->
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#faf32100-6498-11d7-c226-0a9d76001bef">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>oYEdQYG1IHzbkR1UcJ9Q5VriRPs=</ds:SignatureValue>
        <ds:KeyInfo>
          <ds:KeyName>CVR:....-UID:....</ds:KeyName>
        </ds:KeyInfo>
      </ds:Signature>     
      <!-- Status for hvordan autentifikationen forloeb -->
      <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <!-- ID-kort udstedt til brugeren af IdP'en -->
      <saml:Assertion>...</saml:Assertion>
    </samlp:Response>
  </soap:Body>
</soap:Envelope>

Nederst i response-beskeden finder man det returnerede ID-kort som et element. Elementets indhold gennemgås i kapitlet om SOSI webservices og er af simplicitetsgrunde kun repræsenteret med =... = her.

Semantikken for elementerne i en SOSI <Response> svaret til en <AuthnRequest> forespørgsel er defineret nedenfor. De enkelte elementer og attributter er speciferede som XPath udtryk:

• /Response@IssueInstant Lokal tid hos IdP'en, hvor svaret blev skabt.
• /Response@Version For SAML 2.0 er værdien "2.0"
• /Response@ID Globalt unikt ID for denne forespørgsel. I SOSI benytter vi GUIDs.
• /Response@Destination Anvendes ikke
• /Response@Consent Anvendes ikke og defaulter derfor til urn:oasis:names:tc:SAML:2.0:consent:unspecified
• /Response/Issuer Sættes til =CVR-...UID-..." fra IdP'ens system certifikat.
• /Response/Issuer@NameQualifier Sættes til et internt ID for den tjeneste, der foretog autentifikationen, f.eks. "sosi/sso"
• /Response/Signature Beskeden signeres med IdP'ens private nøgle.
• /Response/Extensions Anvendes ikke
• /Response/Status For autentifikationer, der lykkedes er værdien altid urn:oasis:names:tc:SAML:2.0:status:Success. For autentifikationer, der fejlede er værdien en fejlkode som angivet i SAML core specifikationen afsnit 3.2.2.2.
• /Response/StatusMessage For autentifikationer der lykkedes er dette element ikke påkrævet. For fejlede autentifikationer der fejlede angives en menneskeligt læselig tekst med årsagen til at det ikke lykkedes, f.eks. "OCES medarbejdercertifikatet er udløbet".
• /Response/Assertion/ For autentifikationer, der lykkedes indeholder dette element SOSI ID-kortet. For autentifikationer, der fejlede er dette element ikke tilladt i Response beskeder.