OpenSAML user discussion

[Brent Putman <>]

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