Skip to Content.
Sympa Menu

mace-opensaml-users - Re: Signature XPointer References (was Re: Verify a SAML token)

Subject: OpenSAML user discussion

List archive

Re: Signature XPointer References (was Re: Verify a SAML token)


Chronological Thread 
  • From: "Mike Mattozzi" <>
  • To:
  • Subject: Re: Signature XPointer References (was Re: Verify a SAML token)
  • Date: Fri, 8 Jun 2007 14:56:19 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TW8OfVG10r4DN6H67/nlVNeQAUBxkU6CrE4HVjJ1pkVRXwiAHnePjTHNl0QlU9+bSsp9x2up3zIQV5uTw5VvPPsf5Por0k4HNnjnkcRF0VF0GF7dXQQXvx6mO9YApsMec/1wQ/14sKe/y2gTmpTpN3YGu8wU6kjKdyvpOomOfi8=

Hm, assuming for a moment that XPointerResourceResolver didn't have
its single argument constructor requirement... how would I register
the resolver for a standalone Java app? Where is this config.xml
located that xmlsec uses?

Perhaps you could push through an addResourceResolver() to your
SignatureValidator class? Although, again, that would be exposing a
bit much of the xmlsec api.

thanks, Mike

On 6/7/07, Brent Putman
<>
wrote:
I'm glad that it works to resolve the reference.

I had not looked at the resolver code closely, I did not realize that it
took a mandatory single-arg constructor with the base node Node. None
of the other ResourceResolveSpi impls have that requirement.

Ideally it wouldn't, and you'd just register the resolver in the
ResourceResolver chain in the Apache config.xml, and so your code
wouldn't have to change. I posted that observation in the Bugzilla,
we'll see what the developer says. It may be an unavoidable (and
unfortunate) requirement of the XPath and XPointer processing, I don't
know enough about those technologies.

In any event, just FYI, we never really intended for people to do stuff
directly with the Apache XMLSignature that underlies our Signature. The
only reason it's even public on the SignatureImpl is because it has to
be accessed by our other code. We really intended for the specific
underlying signature support to be invisible to the caller, and in fact
at some point may switch the signature code to use the new standard Java
JSR 105 XML Signature API, rather than the original Apache XML Security
API. And if/when we did that, your new code as written would break, so
just fair warning.

--Brent



Mike Mattozzi wrote:
> Success! The XPointerResourceResolver code correctly resolved my
> troublesome xpointer, which for the sake of reminding was:
>
#xpointer(/*[local-name()='Envelope']/*[local-name()='Header']/*[local-name()='Security']/*[local-name()='Assertion'][1])
>
> I just added XPointerResourceResolver by itself to the project I was
> working on, replacing:
>
> SignatureValidator val = new SignatureValidator(basicX509Cred);
> val.validate(assertion.getSignature());
>
> with
>
> SignatureValidator val = new SignatureValidator(basicX509Cred);
> XMLSignature xmlSig = ((SignatureImpl)
> assertion.getSignature()).getXMLSignature();
> Key validationKey = SecurityHelper.extractVerificationKey(basicX509Cred);
> xmlSig.addResourceResolver(new XPointerResourceResolver(soapEnvelope));
> boolean sigValid = xmlSig.checkSignatureValue(validationKey);
>
> I'll let you know if I run into any other issues with this code.
> Mike
>
>>




Archive powered by MHonArc 2.6.16.

Top of Page