OpenSAML user discussion

[Brent Putman <>]

Yeah, I think that should be possible pretty easily.  At most you might 
have to write some impls of the ContentReference interface to handle any 
special needs of the Reference(s) (URI references, transforms, etc).  
Otherwise, I can't think of any showstoppers offhand.

Also, FYI, Valery, one of Chad's colleagues at SWITCH, is working on 
support for a variety of WS-* specs to be integrated into java-openws, 
including WS-Security and WS-Trust.  There's a branch started called 
"wstrustIntegration".  I haven't looked at it, and I don't know when it 
will be ready, but it's something you might want to take a look at.  
Don't know whether it will just be object provider support, or higher 
level things like spec-specific support for signing, encryption, token 
processing, etc.  Maybe Chad or Valey can comment further.

--Brent



Asa Hardcastle wrote:
> 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