[wsf-dev] Pros/Cons OpenSAML XML Tooling

[Asa Hardcastle]

Hi All,

For our call this morning here are some pros and cons directly from  
the source, provided by Scott & Chad - developers of OpenSAML

talk to you soon,

asa



Pro

- doesn't take shortcuts, focused on being a comprehensive code base
- DOM, programmatic Java objects, signature, encryption, credential  
access, security/trust policy are all in scope
- foundation of a new Shibboleth code base that will be used by  
hundreds of deployers or more within a few years, so some degree of  
maintanance is pretty much a given
- has a fairly complete analog in C++ (but it's not SWIGable, so  
probably not much of a pro)
- highly modular design (within the constraints of its XML world view)
- supports validating and non-validating parsing
- already Apache-licensed
- umm, we're here? Who else is offering?
- commmitment to document whatever isn't documented yet
- Support extracting XML fragments from one XMLObject tree and adding  
it to another, most importantly to me is that this process transports  
namespace decelerations as well ensuring that signatures and thing  
stay valid
- Support for custom defined policies for evaluating security and  
message constraints within the SOAP message decoding (or, at least  
there will be support once the SOAP code is finished up)
- The security related items Scott mentions are probably a good bit  
of the work that will need to be done to support the likes of WS-Sec.


Con

- exclusively DOM-based
- nobody likes anybody else's XML code, so most non-novices with pre- 
existing code may reject it
- certainly documentation gaps at this stage
- a lot is new and relatively untested in context (the simple tests  
are fine, but testing real world use cases is largely TBD, and that  
took some work with the old version I did, so I'm expecting some  
signature bumps)
- Java SOAP bits aren't done yet, but this may be a pro in the sense  
that we have a framework but can adjust some things to fit this  
project's needs
- no code generator for XML objects at this point, though the tooling  
is amenable to writing such
- SOAP layer is clean-roomed to integrate well with signature and  
encryption work, so no connection with Axis or any other popular  
stack, so can't tap functionality like attachments that such stacks  
might offer
- no WSDL support, but since WSDL can't handle headers anyway...
- currently dependent on Apache xmlsec, not the Sig/Enc JSRs (hmm, is  
that a con?)
- Has not been profiled yet so there are probably some places where  
it's doing really inefficient things - this just goes with no heavy  
testing yet, in my opinion





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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/wsf-dev/attachments/20070215/69d41ee0/attachment.html