You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Brandon Moser <br...@gmail.com> on 2011/04/06 16:21:10 UTC

Issue in Verifying Signing

Hi,

I'm having an issue trying to verify a signed SAML Response. Our implementation is using ColdFusion 9 & JRun 4 (which I don't believe are effecting the outcome). We are able to load the necessary Jars and create and sign the response. Upon signing, we validate the signing, which returns True. Once the Xml Document is changed to string data, encoded in Base 64, decoded and parsed back into a Xml document, we are unable to validate the signature. I have even gone as far as getting the Signature Values on both versions of the SAML Response. In both cases, the Signature Value is exactly the same. We have also outputted the Xml to a document, both before and after encoding, and found that the documents match 100%. Yet, no matter what I change or what example I read, I cannot validate the encoded/decoded SAML Response.

Any help in things I should be looking for and/or trying would be greatly appreciated.

Thanks in advance,
Brandon
--
Brandon Moser
brandonmoser@gmail.com
brandonmoser.com


Re: Issue in Verifying Signing

Posted by Malcolm Young <ma...@gmail.com>.
The SignatureValue is not part of the signature. The Signature is computed
on the content of the SignedInfo element so I doubt it has anything to do
with the signature.
On Thu, Apr 7, 2011 at 8:28 AM, Brandon Moser <br...@gmail.com>wrote:

> Yes, we are using the Enveloped Signature Transform. The Signature is
> inside the saml2:Assertion element, which is nested inside of the
> saml2:Response element.
>
> What we're beginning to wonder is if the signature is actually being
> ignored during the check. What is the best way to determine what is being
> checked and what is not?
>
>
>
> On Apr 6, 2011, at 4:51 PM, Pellerin, Clement wrote:
>
> > Is the Signature element within the scope of one of your references?
> > For example, that happens when the Reference is the whole document.
> > To make those signatures verifiable, you need the Enveloped Signature
> Transform
> > to ignore the Signature element when computing the digest.
> >
> > -----Original Message-----
> > From: Brandon Moser [mailto:brandonmoser@gmail.com]
> > Sent: Wednesday, April 06, 2011 5:20 PM
> > To: dev@santuario.apache.org
> > Subject: Re: Issue in Verifying Signing
> >
> > So, we decided to use a Transform that allows for whitespace changes, but
> we are still receiving False when attempting to check the signature
> immediately after signing. It appears in the log file that the Pre-Digest
> value before signing doesn't contain the SignatureValue and DigestValue
> (expected), yet after signing the checkSignatureValue contains both
> Signature & Digest values, which I would believe cause the digest to be
> different. Is it possible to check the signature value immediately after
> signing and get a valid response of True?
> >
> > I have tried to use the Online validator and oxygen's validator and both
> return, "Signature Invalid".  We have included the public RSA key in the
> output in any attempt to validate this output. Since we are development the
> data is not valuable, I have attached the XML output and the log.
> >
>
>

Re: Issue in Verifying Signing

Posted by Brandon Moser <br...@gmail.com>.
Thanks Malcom. I'll try those suggestions. 

--
Brandon Moser

On Apr 6, 2011, at 5:41 PM, Malcolm Young <ma...@gmail.com> wrote:

> Also, I was wondering what you meant by a 'tranform that allows for whitespace changes'. I am unaware of a transform that does that. I did notice you've been changing around your canonicalisation transforms. I would suggest you stick to the exclusive canonicalisation transform.
>  
> Also, a small point but I would place that canonicalisation transform AFTER the enveloped signature transform. I don't know about Santuario but that would avoid a node set to stream conversion and prevent another pass using standard canonicalisation (in my stack at least).
>  
> I strongly suspect that what you are seeing is a whitespace related issue.
>  
> Cheers,
>  
> mal
> 
> On Thu, Apr 7, 2011 at 8:28 AM, Brandon Moser <br...@gmail.com> wrote:
> Yes, we are using the Enveloped Signature Transform. The Signature is inside the saml2:Assertion element, which is nested inside of the saml2:Response element.
> 
> What we're beginning to wonder is if the signature is actually being ignored during the check. What is the best way to determine what is being checked and what is not?
> 
> 
> 
> On Apr 6, 2011, at 4:51 PM, Pellerin, Clement wrote:
> 
> > Is the Signature element within the scope of one of your references?
> > For example, that happens when the Reference is the whole document.
> > To make those signatures verifiable, you need the Enveloped Signature Transform
> > to ignore the Signature element when computing the digest.
> >
> > -----Original Message-----
> > From: Brandon Moser [mailto:brandonmoser@gmail.com]
> > Sent: Wednesday, April 06, 2011 5:20 PM
> > To: dev@santuario.apache.org
> > Subject: Re: Issue in Verifying Signing
> >
> > So, we decided to use a Transform that allows for whitespace changes, but we are still receiving False when attempting to check the signature immediately after signing. It appears in the log file that the Pre-Digest value before signing doesn't contain the SignatureValue and DigestValue (expected), yet after signing the checkSignatureValue contains both Signature & Digest values, which I would believe cause the digest to be different. Is it possible to check the signature value immediately after signing and get a valid response of True?
> >
> > I have tried to use the Online validator and oxygen's validator and both return, "Signature Invalid".  We have included the public RSA key in the output in any attempt to validate this output. Since we are development the data is not valuable, I have attached the XML output and the log.
> >
> 
> 

Re: Issue in Verifying Signing

Posted by Malcolm Young <ma...@gmail.com>.
Also, I was wondering what you meant by a 'tranform that allows for
whitespace changes'. I am unaware of a transform that does that. I did
notice you've been changing around your canonicalisation transforms. I would
suggest you stick to the exclusive canonicalisation transform.

Also, a small point but I would place that canonicalisation transform AFTER
the enveloped signature transform. I don't know about Santuario but that
would avoid a node set to stream conversion and prevent another pass using
standard canonicalisation (in my stack at least).

I strongly suspect that what you are seeing is a whitespace related issue.

Cheers,

mal

On Thu, Apr 7, 2011 at 8:28 AM, Brandon Moser <br...@gmail.com>wrote:

> Yes, we are using the Enveloped Signature Transform. The Signature is
> inside the saml2:Assertion element, which is nested inside of the
> saml2:Response element.
>
> What we're beginning to wonder is if the signature is actually being
> ignored during the check. What is the best way to determine what is being
> checked and what is not?
>
>
>
> On Apr 6, 2011, at 4:51 PM, Pellerin, Clement wrote:
>
> > Is the Signature element within the scope of one of your references?
> > For example, that happens when the Reference is the whole document.
> > To make those signatures verifiable, you need the Enveloped Signature
> Transform
> > to ignore the Signature element when computing the digest.
> >
> > -----Original Message-----
> > From: Brandon Moser [mailto:brandonmoser@gmail.com]
> > Sent: Wednesday, April 06, 2011 5:20 PM
> > To: dev@santuario.apache.org
> > Subject: Re: Issue in Verifying Signing
> >
> > So, we decided to use a Transform that allows for whitespace changes, but
> we are still receiving False when attempting to check the signature
> immediately after signing. It appears in the log file that the Pre-Digest
> value before signing doesn't contain the SignatureValue and DigestValue
> (expected), yet after signing the checkSignatureValue contains both
> Signature & Digest values, which I would believe cause the digest to be
> different. Is it possible to check the signature value immediately after
> signing and get a valid response of True?
> >
> > I have tried to use the Online validator and oxygen's validator and both
> return, "Signature Invalid".  We have included the public RSA key in the
> output in any attempt to validate this output. Since we are development the
> data is not valuable, I have attached the XML output and the log.
> >
>
>

Re: Issue in Verifying Signing

Posted by Brandon Moser <br...@gmail.com>.
Yes, we are using the Enveloped Signature Transform. The Signature is inside the saml2:Assertion element, which is nested inside of the saml2:Response element.

What we're beginning to wonder is if the signature is actually being ignored during the check. What is the best way to determine what is being checked and what is not?



On Apr 6, 2011, at 4:51 PM, Pellerin, Clement wrote:

> Is the Signature element within the scope of one of your references?
> For example, that happens when the Reference is the whole document.
> To make those signatures verifiable, you need the Enveloped Signature Transform
> to ignore the Signature element when computing the digest.
> 
> -----Original Message-----
> From: Brandon Moser [mailto:brandonmoser@gmail.com] 
> Sent: Wednesday, April 06, 2011 5:20 PM
> To: dev@santuario.apache.org
> Subject: Re: Issue in Verifying Signing
> 
> So, we decided to use a Transform that allows for whitespace changes, but we are still receiving False when attempting to check the signature immediately after signing. It appears in the log file that the Pre-Digest value before signing doesn't contain the SignatureValue and DigestValue (expected), yet after signing the checkSignatureValue contains both Signature & Digest values, which I would believe cause the digest to be different. Is it possible to check the signature value immediately after signing and get a valid response of True?
> 
> I have tried to use the Online validator and oxygen's validator and both return, "Signature Invalid".  We have included the public RSA key in the output in any attempt to validate this output. Since we are development the data is not valuable, I have attached the XML output and the log.
> 


RE: Issue in Verifying Signing

Posted by "Pellerin, Clement" <Cl...@ibi.com>.
Is the Signature element within the scope of one of your references?
For example, that happens when the Reference is the whole document.
To make those signatures verifiable, you need the Enveloped Signature Transform
to ignore the Signature element when computing the digest.

-----Original Message-----
From: Brandon Moser [mailto:brandonmoser@gmail.com] 
Sent: Wednesday, April 06, 2011 5:20 PM
To: dev@santuario.apache.org
Subject: Re: Issue in Verifying Signing

So, we decided to use a Transform that allows for whitespace changes, but we are still receiving False when attempting to check the signature immediately after signing. It appears in the log file that the Pre-Digest value before signing doesn't contain the SignatureValue and DigestValue (expected), yet after signing the checkSignatureValue contains both Signature & Digest values, which I would believe cause the digest to be different. Is it possible to check the signature value immediately after signing and get a valid response of True?

I have tried to use the Online validator and oxygen's validator and both return, "Signature Invalid".  We have included the public RSA key in the output in any attempt to validate this output. Since we are development the data is not valuable, I have attached the XML output and the log.


Re: Issue in Verifying Signing

Posted by "Cantor, Scott E." <ca...@osu.edu>.
On 4/6/11 8:28 PM, "David Wall" <da...@yozons.com> wrote:
>On 4/6/2011 5:01 PM, Cantor, Scott E. wrote:
>> The advice from the other poster was
>> correct, you should be using Enveloped followed by Excl C14N, period.
>
>Does this mean CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS or
>INCLUSIVE shouldn't be used?

With SAML? Not in general, no. With any ID-based signature, using a
WithComments method is a waste of time, it won't work anyway. The reasons
are long and boring, but your comments aren't signed.

> Seems like all the examples online show the inclusive with comments.

Not SAML examples.

-- Scott


Re: Issue in Verifying Signing

Posted by David Wall <da...@yozons.com>.
On 4/6/2011 5:01 PM, Cantor, Scott E. wrote:
> The advice from the other poster was
> correct, you should be using Enveloped followed by Excl C14N, period.

Does this mean CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS or 
INCLUSIVE shouldn't be used?  Seems like all the examples online show 
the inclusive with comments.

Just EXCLUSIVE? What about EXCLUSIVE_WITH_COMMENTS?

Just checking on best practice for those who don't do these much...  In 
our case, comments are fine though rarely used, but I'm not really sure 
about the Inclusive/Exclusive option's implications.

David


Re: Issue in Verifying Signing

Posted by "Cantor, Scott E." <ca...@osu.edu>.
On 4/6/11 5:19 PM, "Brandon Moser" <br...@gmail.com> wrote:
>\So, we decided to use a Transform that allows for whitespace changes,
>but we are still receiving False when attempting to check the signature
>immediately after signing.

As others said, there is no such transform, and SAML is totally explicit
about the allowable transforms. The advice from the other poster was
correct, you should be using Enveloped followed by Excl C14N, period.

> It appears in the log file that the Pre-Digest value before signing
>doesn't contain the SignatureValue and DigestValue (expected), yet after
>signing the checkSignatureValue contains both Signature & Digest values,
>which I would believe cause the digest to be different.

Enveloped signatures exclude the Signature element, that's how they work.

>I have tried to use the Online validator and oxygen's validator and both
>return, "Signature Invalid".

Then your XML is bad. There's virtually no question on it, you've simply
broken it during serialization. Rather than spend time trying to avoid
fixing that, just change how you're serializing and make sure you know
it's not adding any whitespace or breaking namespaces somehow.

Note that if you're taking a signed Assertion and adding that to a
Response, any number of bugs can break the result. Using off the shelf XML
processing is virtually guaranteed to break the signature, which is why
most SAML toolkits do their own XML processing.

-- Scott


Re: Issue in Verifying Signing

Posted by Brandon Moser <br...@gmail.com>.
So, we decided to use a Transform that allows for whitespace changes, but we are still receiving False when attempting to check the signature immediately after signing. It appears in the log file that the Pre-Digest value before signing doesn't contain the SignatureValue and DigestValue (expected), yet after signing the checkSignatureValue contains both Signature & Digest values, which I would believe cause the digest to be different. Is it possible to check the signature value immediately after signing and get a valid response of True?

I have tried to use the Online validator and oxygen's validator and both return, "Signature Invalid".  We have included the public RSA key in the output in any attempt to validate this output. Since we are development the data is not valuable, I have attached the XML output and the log.


RE: Issue in Verifying Signing

Posted by "Pellerin, Clement" <Cl...@ibi.com>.
For example, the XML spec says the XML parser must map bare carriage returns to a new line character.
We had to change our serializer to quote the carriage returns in text values (like this &#xD);
This is a constant complain from our users that don't expect this ugly sequence in their output
but it avoids a bug similar to what you describe.

>From the XML Spec:

2.11 End-of-Line Handling
XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.



-----Original Message-----
From: Cantor, Scott E. [mailto:cantor.2@osu.edu] 
Sent: Wednesday, April 06, 2011 11:30 AM
To: dev@santuario.apache.org
Subject: RE: Issue in Verifying Signing

> True. Once the Xml Document is changed to string data, encoded in Base 64,
> decoded and parsed back into a Xml document, we are unable to validate the
> signature.

Then "changed to string data" is most likely corrupting the XML. Probably a whitespace issue.

> Any help in things I should be looking for and/or trying would be greatly
> appreciated.

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManSigErrors

-- Scott


RE: Issue in Verifying Signing

Posted by "Cantor, Scott E." <ca...@osu.edu>.
> True. Once the Xml Document is changed to string data, encoded in Base 64,
> decoded and parsed back into a Xml document, we are unable to validate the
> signature.

Then "changed to string data" is most likely corrupting the XML. Probably a whitespace issue.

> Any help in things I should be looking for and/or trying would be greatly
> appreciated.

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManSigErrors

-- Scott


Re: Issue in Verifying Signing

Posted by eric fu <er...@gmail.com>.
Did you checked and compared output for each Reference? The first step is to
verify digest values of all references are same, then content of SignedInfo.

Eric

On Wed, Apr 6, 2011 at 7:21 AM, Brandon Moser <br...@gmail.com>wrote:

> Hi,
>
> I'm having an issue trying to verify a signed SAML Response. Our
> implementation is using ColdFusion 9 & JRun 4 (which I don't believe are
> effecting the outcome). We are able to load the necessary Jars and create
> and sign the response. Upon signing, we validate the signing, which returns
> True. Once the Xml Document is changed to string data, encoded in Base 64,
> decoded and parsed back into a Xml document, we are unable to validate the
> signature. I have even gone as far as getting the Signature Values on both
> versions of the SAML Response. In both cases, the Signature Value is exactly
> the same. We have also outputted the Xml to a document, both before and
> after encoding, and found that the documents match 100%. Yet, no matter what
> I change or what example I read, I cannot validate the encoded/decoded SAML
> Response.
>
> Any help in things I should be looking for and/or trying would be greatly
> appreciated.
>
> Thanks in advance,
> Brandon
> --
> Brandon Moser
> brandonmoser@gmail.com
> brandonmoser.com
>
>