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: Brent Putman <>
  • To:
  • Subject: Re: Signature XPointer References (was Re: Verify a SAML token)
  • Date: Fri, 08 Jun 2007 18:24:38 -0400



Mike Mattozzi wrote:
> 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?

The default one is located inside the xmlsec jar. It's a resource
located in package:
org.apache.xml.security.resource.

So cracking open the jar and modifying the file is one (messy) option.

You can also (supposedly) override the config file that is used by
setting system property:
"org.apache.xml.security.resource.config"

See org.apache.xml.security.Init. That's not documented anywhere that I
have ever seen, however (although that's, um, not inconsistent with the
rest of their documentation, IMHO...). I've been meaning to ask them
whether this mechanism is officially supported (meaning unlikely to
change or be removed without warning). I also have not tested whether
it actually works.

Assuming it is supported and works correctly, I have considered just
making our XMLTooling and OpenSAML stack use a specific file, via this
mechanism, that we put in a fixed and documented location. I have a use
case to put some info in there that is missing from the default file
(signature algorithm URI -> JCA key algorithm mappings), although I
might just see if they will add it. But that would also make it easier
for people to customize for things like the custom resource resolver
impls. But not sure yet whether will do this.

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

Yeah, I think that would expose too much of their API. I haven't
investigated, but I'm willing to bet the JSR 105 stuff uses a completely
different mechanism for extension. We even avoid using string constants
from their library, because we didn't want to introduce those kinds of
Apache API dependencies. So that's another reason I'm not even sure yet
about baking in a dependency in our stack on a fixed config.xml. I'm
not sure if they share/use if for their JSR 105 implementation classes.

--Brent




Archive powered by MHonArc 2.6.16.

Top of Page