The profile handlers in the Shibboleth 2.0 IdP (java-idp project) which
de facto use the SAML 2 SOAP binding are:
edu.internet2.middleware.shibboleth.idp.profile.saml2.AttributeQueryProfileHandler
edu.internet2.middleware.shibboleth.idp.profile.saml2.ArtifactResolution
However, the method that actually does the response encoding
(encodeResponse) is actually way up in a super class and is common to
all the bindings used by all the SAML 1 and SAML 2 profile handlers.
So you're not really going to see anything there that's specific to the
SOAP binding case. But wouldn't hurt to look at the handlers anyway as
an example of how all the components get used.
Note also you're not going see specific references in the code to
particular encoder impls. The IdP is based on Spring and the actual
encoder that gets used is based on declarative configuration, which
determines encoder bean(s) that get injected into the right places.
It's odd that it works for you for the POST encoder but not the SOAP
encoder. There really shouldn't be any difference between the two.
Like I said, a simple test program worked for me. Sounds like either
you're doing something different code-wise between the 2 cases, or else
something about your environment is off.
HTH,
Brent
Bleu Rubin wrote:
I am using all of the jar files included in the 2.1
distribution, appropriate jars are in the proper endorsed directory. I
was also successful signing using the SAML2 HTTPPostEncoder. I checked
out the shibboleth code as of May 1 and I can't find any examples of
using the HTTPSOAP11Encoder. Can you point me to a particular file in
the shibboleth code which uses the soap encoder so I can see if I am
doing something wrong? I really appreciate your help.
thanks,
Bleu
On Wed, May 7, 2008 at 12:03 PM, Brent
Putman <>
wrote:
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
|
