Signing multiple objects?

[Brent Putman]

On 11/1/11 10:21 AM, Brad Cox wrote:

> 
> The first sentence is what sent me on the prior wild goose chase. As I
> read this, "SAMLObject" means an instance of Envelope (right?).


No.  SAMLObject is an interface for providers representing SAML 1.1 or
2.0 schema Elements, up in the java-opensaml2 part of the library.  The
stuff for SOAP is not SAML, therefore logically it doesn't implement the
SAMLObject interface.



>  Problem
> is at this point exists only as as Element, and I've so far been unable
> to marshal that to an Envelope. 


You have the terminology backwards.  You marshall an XMLObject to an
Element.  You unmarshall an Element into an XMLObject.  Just clarifying.


> And in any event Envelope doesn't have a
> setSignature() method.


Right, as I said earlier, the SOAP elements are (in our terminology) not
"signable", i.e. they are not defined to carry an enveloped signature.
SAML requests, responses, assertions, etc are.

Just a crazy thought, I wanted to make sure you realized that the term
"enveloped signature" has nothing to do with a SOAP Envelope. Totally
orthogonal concepts.  "Enveloped signature" means the case where the
ds:Signature element is a child of the the element being signed.
Nothing more, nothing less.



> 
> So what I have now works entirely at the DOM level which doesn't seem
> right. 
> 


Yeah, you've gone off the rails here... The whole point of the library
is that you don't (usually) work with DOM Elements, etc.  You work with
XMLObject provider instances.  So you build an Envelope XMLObject, then
build a Header XMLObject and add it to the Envelope, then build a
Security object and add it to the Header, etc.  You build a graph
(really a tree) of XMLObjects.  Then at the end you marshall the
XMLObject tree to a DOM Document (and then typically serialize that,
depending on what you are going to do with with).


Also, unrelated to your actual problem, you should not construct
instances of builders, marshallers and unmarshallers using 'new'.  You
should obtain them from the factories available on the Configuration.
I'm sure there are  examples of this in the wiki and in unit tests, etc.

Take a look at this page again:

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreateFromScratch





>
> Here are the instructions I've been trying to follow. 


These instructions are for signing SignableSAMLObjects.  That is *not*
what you are doing.  You are not doing "SAML signing" at all.  You are
basically asking to do WS-Security SOAP message signing.    Some of
those instructions are applicable (the stuff about populating the
Signature instance, except for the SAMLContentReference part), but the
parts about adding the Signature to the SignableSAMLObject are not.  You
will be adding the Signature as a child of the wsse:Security header.

Basically, we don't have any literal examples of what you are trying to
do.  But I think once you clear up your conceptual issues of what
OpenSAML is and how it works



> (Wouldn't a code sample be easier?)

Well, there are several examples of both signing and validation at the
bottom of that page:

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaDSIG