locked
Signed SAML Assertions with ADFS RRS feed

  • Question

  • i am trying to integrate with a partner over IDP-Initiated SSO via an HTTP Post and they are expecting the SAML 2.0 assertions to be signed. In ADFS I have the token signing certificate specified but it looks like ADFS is not signing the assertions but another part of the Saml-P payload.

    Does anyone know a way to tell ADFS to sign the assertions?

    Is there any other approach to handle this? Is there a way to modify the request in transit so I can sign the assertions myself?

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Wednesday, May 18, 2011 10:12 PM

Answers

  • ADFS signs the entire message including the assertions.  Otherwise the whole purpose of signing the message would go out the window.


    Developer Security MVP | http://www.steveonsecurity.com
    • Marked as answer by Ben Cline1 Friday, May 20, 2011 4:30 PM
    Thursday, May 19, 2011 7:15 PM
  • The signature is the bit starting with "7T3Cwk=".  It's within the CipherData tag with the xmlns of http://www.w3.org/2000/09/xmldsig#.

     


    Developer Security MVP | http://www.steveonsecurity.com
    • Marked as answer by Ben Cline1 Friday, May 20, 2011 4:34 PM
    Friday, May 20, 2011 1:45 PM

All replies

  • ADFS signs the entire message including the assertions.  Otherwise the whole purpose of signing the message would go out the window.


    Developer Security MVP | http://www.steveonsecurity.com
    • Marked as answer by Ben Cline1 Friday, May 20, 2011 4:30 PM
    Thursday, May 19, 2011 7:15 PM
  • Thanks for the response Steve.

    Maybe I am doing something wrong, the SAML assertions are encrypted but the signature is looking like this:

    <KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <ds:X509IssuerSerial>

         <ds:X509IssuerName>CN=myCN</ds:X509IssuerName>

    <ds:X509SerialNumber>50570808494923214274701535135366611101</ds:X509SerialNumber>

    </ds:X509IssuerSerial></ds:X509Data>

    </KeyInfo>

    I was expecting to see a DigestValue and SignatureValue instead. Do you know why this would output instead?

    Thanks!


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, May 19, 2011 8:23 PM
  • Can you show the entire token (minus any compromising details of course)?
    Developer Security MVP | http://www.steveonsecurity.com
    Thursday, May 19, 2011 8:47 PM
  • Yes absolutely, thanks so much for continuing your replies.

    <samlp:Response ID="_3f6c2a8d-723d-4c34-a101-c9638d04eea8" Version="2.0" IssueInstant="2011-05-18T20:13:34.351Z" Destination="partner address" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://mydomain/adfs/services/trust</Issuer>

    <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>

    <EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">

    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />

    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#"><e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /></e:EncryptionMethod>

    <KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <ds:X509IssuerSerial><ds:X509IssuerName>CN=myCN</ds:X509IssuerName>

    <ds:X509SerialNumber>50570808494923214274701535135366611101</ds:X509SerialNumber>

    </ds:X509IssuerSerial></ds:X509Data>

    </KeyInfo>

    <e:CipherData><e:CipherValue>7T3Cwk=...</e:CipherValue></e:CipherData>

    </e:EncryptedKey></KeyInfo>

    <xenc:CipherData><xenc:CipherValue>9ku1Yz...</xenc:CipherValue></xenc:CipherData>

    </xenc:EncryptedData></EncryptedAssertion></samlp:Response>


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, May 19, 2011 10:02 PM
  • The signature is the bit starting with "7T3Cwk=".  It's within the CipherData tag with the xmlns of http://www.w3.org/2000/09/xmldsig#.

     


    Developer Security MVP | http://www.steveonsecurity.com
    • Marked as answer by Ben Cline1 Friday, May 20, 2011 4:34 PM
    Friday, May 20, 2011 1:45 PM
  • Very interesting. My partner was thinking it would show up in a format like this:

    <Signature xmlns=\"http://www.w3.org/2000/09/xmldsig#\">
          <SignedInfo>
            <CanonicalizationMethod Algorithm=\"http://www.w3.org/TR/2001/REC-xml-c14n-20010315\" />
              <SignatureMethod Algorithm=\"http://www.w3.org/2000/09/xmldsig#rsa-sha1\" />
                <Reference URI=\"#_33c46063-a304-4ee6-bd31-85a1a39a25aa\">
                  <Transforms>
                    <Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" />
                      <Transform Algorithm=\"http://www.w3.org/TR/2001/REC-xml-c14n-20010315\" />
                    </Transforms>
                    <DigestMethod Algorithm=\"http://www.w3.org/2000/09/xmldsig#sha1\" />
                    <DigestValue>z...</DigestValue>
                  </Reference>
          </SignedInfo>
          <SignatureValue>khj...</SignatureValue>

    I was not sure if this might be a different type/technique for signature. Do you know how this is different?

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Friday, May 20, 2011 4:34 PM
  • Sorry to bother you Steve. Thanks for all of your help. This is another poorly documented PowerShell feature.

    I finally figured this one out. Here is the important command:

    Set-ADFSRelyingParty -TargetName MyRP -SamlResponseSignature "MessageAndAssertion"

    This got the signature element to come through near the top of the Samlp response. It looks like the default with ADFS is just on the assertion.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Friday, May 20, 2011 9:42 PM
  • @Ben. Just out of curiosity. Any idea why your customer wants signature on whole message? I know all the arguments, just wondering which one they give the high weight.

    @Steve. Small correction. In original message "e:CipherValue..7T3Cwk.." is the asymmetric-encrypted symmetric-encryption-key. After Ben's modification the whole message was signed.


    Paul Lemmers
    Saturday, May 21, 2011 10:04 AM
  • Paul,

      I actually do not know why they want the message signed, but I would be glad to ask them and let you know. They are using componentSpace for their federation provider and I am not sure if the message signature is optional or not.

    Thanks for the additional comments.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Saturday, May 21, 2011 4:18 PM
  • It is up to IdP and SP to decide what they want. Not many things are really mandatory. Often the metadata tells the partners what should be done. I gues the parameter that you did manually, would normally be automatically configured correctly by reading their metadata (assuming both parties have the correct metadata). But I haven't tested all combinations, so maybe you have to do this one manually indeed. I'd be interested in your (default ADFS?) and their metadata, but we'll have to that through direct email (company in profile and I am the one-and-only).
    Paul Lemmers
    Saturday, May 21, 2011 7:32 PM
  • That's a good point, metadata could propulate whether the message is signed. The componentSpace metadata does not comply with the 06/2007 Federation metadata so unfortunately I had to setup this RP manually.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Sunday, May 22, 2011 6:02 PM
  • In cases like that I give them the metadata and they can sign it. Setting an example usually pulls them over. It saves them time too!
    Paul Lemmers
    Monday, May 23, 2011 7:14 AM
  • Hi, I think there is a mistake in the command. Shouldn't it be like this?

    Set-ADFSRelyingPartyTrust -TargetName MyRP -SamlResponseSignature "MessageAndAssertion"

    Note the "..Trust" at the end of the command.

    Thank you all for your help, from Spain.

    Alfonso

    Wednesday, September 2, 2015 1:29 PM
  • For sure. Good catch.

    Paul Lemmers

    Wednesday, September 2, 2015 3:01 PM