Signing and validating using the same credential

[Brent Putman]

On 12/4/14 1:44 PM, Pascal Mainini wrote:
> Hi there
>
> I'm having some troubles in signing and verifying an Assertion and an
> AttributeQuery and thought, this would (hopefully) be the right place to
> ask...
>
> Signing looks like this in my code:
>
>  

I don't see anything wrong there.
>
> I'm trying to validate like this:
>

That looks ok too.

>
> THE_CREDENTIAL is obtained from a Keystore with a single entry
> consisting of a keypair with a private key as well as a certificate with
> according public key:
>
>  

Also fine.

>
> "Signature did not validate against the credential's key"

Turning logging up to DEBUG might provide more info, including on the
Santuario packages.

One thing that comes to mind is: Santuario (xmlsec) used to have a
problem with signing and then attempting to immediately validate the
same XMLSignature instance in the same thread.  Signature validation
would fail.  I can't remember if that is still the case, but: the
workaround in OpenSAML for this was always to take the marshalled DOM of
the thing you've signed (e.g. your AttributeQuery) and unmarshall a new
XMLObject tree around it, which has the side effect of creating a new
Santuario XMLSignature instance.  Then validate the Signature on the
newly unmarshalled tree, *not* the one you originally signed.  In order
to completely simulate the real world, you could actually go a step
farther and actually serialize the signed DOM out to a String or byte[],
and then parse it to DOM and unmarshall around that.  That should
completely avoid in weird aspects of Santuario behavior.

If you are already doing something like the above (like serializing and
re-parsing), then of course make sure you aren't actually changing the
DOM or serialized XML, such as by pretty-printing it before you validate it.

This problem obviously mostly arises when people are testing things,
etc, since in real world use cases you don't generally sign something
and then immediately verify it yourself.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141204/f61f3fb9/attachment.html