OpenSAML user discussion

[Asa Hardcastle <>]

Thanks.  In my specific example (ID-WSF 2.0), the resultant  
ds:Signature is added as a child of the wsse:Security SOAP Header.  I  
am signing the SOAP Body and several Headers, including some elements  
of the wsse:Security header.  At present, I am doing the signing with  
my own signing class, I'd like to transition to using the OpenSAML  
signing features.  Is the case I described above be easily possible?

asa


--
Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
Tel: +1.413.429.1044 Skype: subsystem7

On Feb 15, 2008, at 5:33 PM, Brent Putman wrote:

> Yes, that's correct.  More precisely I think the rule would be:  
> extend AbstractSignableXMLObject if the object/element is to be  
> signed with an *enveloped* signature.  In a schema-driven world,  
> that would typically be elements whose schema definition allows a  
> ds:Signature element child (or possibly grandchild, etc), and where  
> the intent is that the element itself (or perhaps one of its  
> ancestors) is the "target" of the signature, via the Reference.  
> (When the Signature element child is not just a placeholder for an  
> enveloping signature or a detached signature of other stuff located  
> elsewhere).
>
> Note, you could also easily imagine signing things such as you have  
> below with a detached signature (like WS-Security signature in the  
> header over only the SOAP body), so I'm not sure if that's what you  
> meant or not.  In that case you wouldn't extend that class.  You'd  
> just create a Signature object separately, with the right  
> Reference(s) and sign accordingly, placing the resulting Signature  
> element wherever it ought to go.
>
> However, I don't think that any of that is a hard and fast rule:  
> enveloped vs. enveloping vs. detached Signatures are not mutually  
> exclusive.  A given Signature could technically be all 3 at once  
> (although that would be pretty unusual).  That xmltooling abstract  
> class API is pretty SAML-centric, where the only possible option is  
> enveloped (per the spec).
>
> HTH,
> Brent
>
>
>
> Asa Hardcastle wrote:
> > Hi All,
> >
> > When building my tooling classes I've made a habit of always  
> > extending AbstractSignableXMLObject.   I just realized that it is  
> > more likely that I should only be doing this for elements that I  
> > plan to sign.
> >
> > ridiculous example:
> >
> > <MyThing>
> >    <TrivialElement></TrivialElement >
> >    <ImportantElement id="imp_ele">
> >        <ImportantElementChild></ImportantElementChild>
> >    </ImportantElement>       <SomeOtherImportantElement  
> > id="so_imp_ele">
> >    </SomeOtherImportantElement >
> > </MyThing>
> >
> > If I wanted to sign SomeOtherImportantElement and ImportantElement,  
> > then the tooling classes would extend AbstractSignableXMLObject,  
> > whereas, TrivialElement and MyThing could extend AbstractXMLObject.
> >
> >
> > Is this right?
> >
> >
> > thanks,
> >
> > asa
> >
> >
> > --
> > Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
> > Tel: +1.413.429.1044 Skype: subsystem7