[wsf-dev] Pros/Cons OpenSAML XML Tooling

[Cahill, Conor P]

I think this might be a good lower layer.  I don't know how well it will
fit into java SOAP environments such as Axis, but perhaps that doesn't
matter.
 
I would like to see us write a wrapper layer that allows a WSC to use
this code in a fully text mode along the lines of:
 
serviceInstance si = new serviceInstance(Assertion, service_urn )
 
response = si.Request("<pip:Query>....</pip:Query")
 
    where Assertion is a SAML SSO assertion containing a DS EPR
bootstrap
    and service_urn is the service type URI
    and response has a response.bodyTxt() that returns the contents of
the body of the response as a text string.
 
Conor
 
 
 


________________________________

	From: wsf-dev-bounces at openliberty.org
[mailto:wsf-dev-bounces at openliberty.org] On Behalf Of Asa Hardcastle
	Sent: Thursday, February 15, 2007 10:26 AM
	To: wsf-dev at openliberty.org
	Subject: [wsf-dev] Pros/Cons OpenSAML XML Tooling
	
	
	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/a975ba7e/attachment.html