Signing multiple objects?

[Brent Putman]

On 10/31/11 4:53 PM, Brad Cox wrote:

> 
> 
> Since Envelope lacks a setSignature method I created a wrapper to
> provide one plus setHeader and setBody methods.
> 
>           o public class SignableSoapEnvelope extends
>             AbstractSignableXMLObject 
>           o implements ElementExtensibleXMLObject,
>             AttributeExtensibleXMLObject
> 
> Is this on the right path? Or should this be AbstractSignableSOAPObject?
> I'm unclear on the difference so have been exploring both paths. 


Well, strictly speaking, you don't need to do any of that.  There isn't
any need to have a SignbleSoap* thing.  The Signable* classes/interfaces
you see in OpenSAML, especially for the SAML elements, are there just
for convenience, specifically because those things have specific
schema-defined support for enveloped signatures.  SOAP doesn't; as I
mentioned earlier, a SOAP Envelope signed under WS-Security in fact
usually is *not* signed with an enveloped signature, at least as far as
the traditional use of that spec is concerned.  So you certainly don't
need anything like the above to make it work.

Also, the SOAP soap11:Header and wsse:Security elements have open
content models, which obviates the need for type-specific getters/setters.

All that matters is that you get the Signature object in the right place
in the object tree.



> The
> pointer to ws.wssecurity sounds promising. Have been focusing on
> xmltooling on the (mis)understanding that OpenSAML doesn't handle SAML2
> signing yet. I'll look at that next.


I don't know what you mean by that.  OpenSAML absolutely supports SAML 2
signing.  I think you are still confusing the difference between signing
via enveloped signature on the SAML elements that define a signature per
their schemas (e.g. Assertion, Response, etc), and WS-Security signing
of SOAP messages, which has nothing to do with SAML.


> 
> Current problem is that when I sign an Envelope with header and/or body
> contents, the contents disappear during the signing step. 


Yeah, you're just doing something wrong then.



> I believe this
> is because EnvelopeMarshaller, HeaderMarshaller and BodyMarshaller are
> not expecting signatures or contents; for example EnvelopeMarshaller
> 
>         protected void marshallElementContent(XMLObject xmlObject,
>     Element domElement) throws MarshallingException {   
> 
>     // nothing to do, not element content
> 
>         }
> 
> I plan to explore whether extending the marshalElementContent methods
> might get me a bit further.
> 


No, that method is used when an element carries non-XML content (e.g.
simple type data such as a string).  Those elements don't carry such
data, they carry Element children, so it is correct that they are
no-ops.  Your problem lies elsewhere.  Not sure what it could be, but
your doing something fundamentally wrong.