OpenSAML user discussion

[Farrukh Najmi <>]

Thanks Scott. This is very helpful information.

See comments inline below.

Scott Cantor wrote:

> > Lets assume I were to generate Java binding classes from the SAML 1.1 
> > XML Schema files. I assume that I will be able to use the JAXB generated 
> > binding classes to:
> >
> > a) Create SAML 1.1 Request/Response XML (Marshal Java to XML use case)
> > b) Process SAML 1.1 Request/Response XML(Marshal from XML to 
> > Java use case)
> >    
>
> I have no idea at all, I don't use JAXB. I'm skeptical because validation
> support is so hit or miss in so many XML tools whether any non-trivial
> schema could ever be auto-generated into anything useful.
>  
JAXB validation is rock solid in my experience and can be turned off for 
perfromance boost.

> I made the decision not to generate the code because I wanted portability to
> C++. I don't regret it. It's not enough code to worry about, and the
> standard is a stable schema, so it's not like it's constantly changing.
>
> I also wanted more control over object creation, copying, etc. I did not
> want every sub-object to be parsing and reparsing XML all over the place.
>  
All good reasons.

>  
>
> > I am curious what other advantages the opensaml toolkit would provide 
> > above and beyond (a) and (b) when compared with the JAXB based approach 
> > described above.
> >    
>
> Well, for one thing, JAXB isn't going to handle digital signatures (or
> encryption in the future). That's most of the effort anyway.
>  
For that there another standard Java called "XML Digital Signature APIs" :

   http://www.jcp.org/en/jsr/detail?id=105

I have very positive experience with the Reference Implementation for 
that API that ships with JWSDP 1.4:

   http://java.sun.com/webservices/downloads/webservicespack.html

This one is in Proposed Final stage and very usable already (nearly 
done) :-)

For Encryption there is another standard Java API  "XML Digital 
Encryption APIs":

   http://www.jcp.org/en/jsr/detail?id=106

This one seems to be stuck in the JCP process for some time :-(

> There are also other classes for the SOAP binding and POST profile,
> particular on the C++ side these days, that do additional work and provide
> the needed hooks to customize behavior. As Shib has evolved, the underlying
> classes in OpenSAML have evolved to put the dividing line in the right
> place. I have some work to do to get the Java in shape in that respect.
>  
What are you using as a SOAP toolkit? Are you creating your own? If so 
you might consider using off-the-shelf
SOAP toolkits like JAX-RPC RI (from JWSDP 1.4) or Apache Axis.

I suspect that most SAML Authorities and clients would already be using 
a SOAP toolkit and if it is Java then it will conform to JAX-RPC 
standard java API which would make it pluggable. In such cases the extra 
SOAP toolkit from opensaml would be extra weight. Something to consider 
maybe.

Thanks again for your valuable help.

--
Regards,
Farrukh