OpenSAML user discussion

[Brent Putman <>]

Sorry for not getting back to you til now, I did actually start looking 
at this on Monday but our email system was down for a good part of 
yesterday...

Yes, I am able to use the HTTPSOAP11Encoder to successfully encode a 
signed SAML 2 message into a SOAP envelope.    Didn't really encounter 
any issues, it works as expected for me.   Also, we do this successfully 
and routinely in our Shibboleth IdP package, for returning both a 
samlp:Response after receipt of an samlp:AttributeQuery, and for 
returning a samlp:ArtifactResponse after an samlp:ArtifactResolve.

Also, your success with the Redirect-DEFLATE binding encoder is not very 
meaningful:  that encoder strips off the protocol message's ds:Signature 
element (if even present) before the marshalling and signing 
operations.  Per the spec, it's not allowed to carry the signature that 
way.  The signing is via raw signature passed in the query params.  So 
you wouldn't see this error there.  Just for the hell of it, you may 
want to test the SAML 2 HTTPPostEncoder in your environment, which will 
sign the message via XML Signature.  I'll wager you'll get the same 
error. (not that either of those bindings really makes sense for an 
ArtifactResolve message).


So whatever is going wrong for you must be in something odd with your 
environment vis-a-vis XML Signaure.  I traced the code.  The error is 
odd, because it seems to think that the namespace prefix on the 
Signature element is null (which it's not, both our library and Apache 
XML Security use "ds") and it seems to be unable to resolve that to the 
namespace URI that is bound to it (so even if it were really null, 
meaning the default namesapce, it should be able to resolve that to the 
namespace URI that is bound as the default).  Almost sounds like the DOM 
element that is cached isn't namespace aware, only DOM Level 1 or 
something.  Don't know how that would happen...

Neither of those things appears consistent with what I see, so 2 
questions:  1) how have you set up your XML parsing environment in your 
VM (i.e. have endorsed the recommended versions of Xerces, etc) 2) have 
you deliberately or accidentially replaced our supplied version of the 
Apache XML Security library jar with an older one?


HTH,
Brent



Bleu Rubin wrote:
> I'll try one *bump* and then let it go.
>
> Has anyone successfully signed a message using the HTTPSOAP11Encoder?
> I can get it working if I do the SOAP encoding myself, and as stated,
> I have successfully signed messages using the
> HTTPRedirectDeflateEncoder, but I get "Unable to resolve namespace
> prefix null found on element
> {http://www.w3.org/2000/09/xmldsig#}Signature"; when attempting to sign
> using the SOAP encoder.
>
>
>
> On Sat, May 3, 2008 at 12:42 PM,  
> <>
>  wrote:
>   
> > I am using the org.opensaml.saml2.binding.encoding.HTTPSOAP11Encoder class to 
> > encode an ArtifactResolve request.  Everything works fine if I don't try to 
> > sign the request, but I'm stuck on the following error when I try to sign it. 
> >  I don't have any problems using similar code using the 
> > HTTPRedirectDeflateEncoder.
> >
> >  this works (same credential)
> >  <code>
> >  
> > messageContext.setOutboundSAMLMessageSigningCredential(getSigningCredential());
> >
> >  HTTPRedirectDeflateEncoder encoder = new HTTPRedirectDeflateEncoder()
> >  encoder.encode(messageContext);
> >  </code>
> >
> >  but this breaks:
> >
> >  <code>
> >  
> > messageContext.setOutboundSAMLMessageSigningCredential(getSigningCredential());
> >
> >  HTTPSOAP11Encoder encoder = new HTTPSOAP11Encoder();
> >  encoder.encode(messageContext);
> >  </code>
> >
> >  with this error:
> >
> >  ERROR org.opensaml.xml.io.AbstractXMLObjectMarshaller - Unable to root 
> > namespaces of cached DOM element, 
> > {urn:oasis:names:tc:SAML:2.0:protocol}ArtifactResolve
> >  org.opensaml.xml.parse.XMLParserException: Unable to resolve namespace 
> > prefix null found on element {http://www.w3.org/2000/09/xmldsig#}Signature
> >         at org.opensaml.xml.util.XMLHelper.rootNamespaces(XMLHelper.java:893)
> >
> >  Does anyone have any ideas why this is breaking in the 
> > BaseMessageEncoder.marshallMessage(BaseMessageEncoder.java:85) step?
> >
> >  thanks,
> >  Bleu
> >
> >