Verification of the XML digital signature on a SAML Assertion

[Mark E Hansen]

We have a web application which allows SSO authentication using SAML 2.0

The customer will use their federated server (various flavors) to generate an HTTP Post request with a SAML Response which contains a digitally-signed SAML Assertion.

Our code will take the SAML Assertion and validate the digital signature.

We basically follow the code examples from the following page: http://docs.oracle.com/javase/7/docs/technotes/guides/security/xmldsig/XMLDigitalSignature.html

Under the section titled "What if the XML Signature Fails to Validate, it states that we can do a couple things to see what actually failed: The signature, or one (or more) of the reference elements.

In our customer's case, the Signature element has just one Reference element and it is referencing the SAML Assertion element.

The verification check is failing. It states that the signature validates okay, but the reference does not.

Note that the customer and I have double-checked that we have the correct public key certificate associated with the private key certificate they are using to sign the assertion.

I'm not sure what to check at this point. The customer claims that they use their software to connect to dozens of other vendors without any problems and so they feel the problem is on our side.

What can I do to determine why the reference element is not validating?

I did notice one interesting thing when looking at their SAML Assertion: The xmlns attributes are not what we normally get from our other customers. Here is what theirs looks like:

    <saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="2.0" ID="pfx4d77d707-998e-4a8b-e2d7-1cd836e35de0" IssueInstant="2013-07-18T19:20:34Z">

Notice that the Assertion element uses the "saml" namespace, but the xmlns attribute shows "xmlns:xs" instead of "xmlns:saml". Could this be the problem?

If so, is there something that needs to be done to our code (again, we're just using the code as shown by the above referenced Oracle page) to allow us to accept an assertion built this way?

Thanks,

[Rob Spoor]

I take it there is a reference to the saml namespace (xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion")?

What happens if you try to validate the response instead of only the assertion? I've so far only seen signatures that refer to the entire response. Of course this would mean that the other side would be incorrectly signing their documents.

[Mark E Hansen]

Rob Spoor wrote:I take it there is a reference to the saml namespace (xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion")?

I see no mention of "xmlns:saml" in the customers XML document at all.

Rob Spoor wrote:What happens if you try to validate the response instead of only the assertion? I've so far only seen signatures that refer to the entire response. Of course this would mean that the other side would be incorrectly signing their documents.

This is for a SAML 2.0 Response, which is build a very specific way. The customer must digitally sign the SAML Assertion, then embed the (now signed) assertion in the SAML Response.
If they sign the whole response, it will no longer work. I can look at the SAML Response they are sending and see that it appears to be constructed properly (as far as what is signed goes).
In other words, the Signature element is inside the Assertion element, which is what they do when signing the Assertion. When the Response is signed, the Signature element would be inside the Response element (a sibling of the Assertion element).

Also, the validation call shows that the signature validates okay - it's just the reference that does not. Also, the Reference element includes a URI attribute which identifies the "thing" the signature is signing, and this correctly references the ID attribute value of the Assertion element.

It sure seems like they've signed it correctly. I keep coming back to the namespace used by the Assertion element. They way this customer has done it is certainly different than any of our other customers, and contrary to how I thought it had to be done.

Thanks,

[Rob Spoor]

Mark E Hansen wrote:

Rob Spoor wrote:I take it there is a reference to the saml namespace (xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion")?

I see no mention of "xmlns:saml" in the customers XML document at all.

Then it is not a valid XML document.

Rob Spoor wrote:What happens if you try to validate the response instead of only the assertion? I've so far only seen signatures that refer to the entire response. Of course this would mean that the other side would be incorrectly signing their documents.

This is for a SAML 2.0 Response, which is build a very specific way. The customer must digitally sign the SAML Assertion, then embed the (now signed) assertion in the SAML Response.
If they sign the whole response, it will no longer work. I can look at the SAML Response they are sending and see that it appears to be constructed properly (as far as what is signed goes).
In other words, the Signature element is inside the Assertion element, which is what they do when signing the Assertion. When the Response is signed, the Signature element would be inside the Response element (a sibling of the Assertion element).
Odd, I've worked with PicketLink and it works just fine like that. Of course it should also be possible to sign other parts like you do.

It sure seems like they've signed it correctly. I keep coming back to the namespace used by the Assertion element. They way this customer has done it is certainly different than any of our other customers, and contrary to how I thought it had to be done.

As I said before, without that namespace declaration the document is not valid XML. That could well be the root of your problems. Make them include it.

[Mark E Hansen]

Rob Spoor wrote:Odd, I've worked with PicketLink and it works just fine like that. Of course it should also be possible to sign other parts like you do.

To be honest, I'm not sure if the fact that the Assertion needs to be signed and not the entire response is a SAML 2.0 thing or a limitation of our implementation. I inherited the code and was told (by the original author) that it had to be that way.

Rob Spoor wrote:As I said before, without that namespace declaration the document is not valid XML. That could well be the root of your problems. Make them include it.

Thanks Rob!