OpenSAML user discussion

[Farrukh Najmi <>]

Hi Scott,

I spent 30 minutes with JAXB and generated the SAML 1.1 bindings 
classes. I have not analyzed the generated code much yet. Note that 
bindings can easily be custmized for a wide array of use cases if 
desired. This is just the first attempt with default settings and no 
customization.

The bindings may be found at:

# The compiled java classes/interfaces generated by JAXB
http://ebxmlrr.sourceforge.net/tmp/oasis-saml1.1.jar

# The javadoc for the classes/interfaces generated by JAXB. Un-jar and 
browse index.html file
http://ebxmlrr.sourceforge.net/tmp/oasis-saml1.1-doc.jar

# The source java classes/interfaces generated by JAXB
http://ebxmlrr.sourceforge.net/tmp/oasis-saml1.1-src.jar

Note that you can safely ignore the xx.impl packages and XxImpl classes 
unless you care to see how JAXB generated code looks like.
When you have a choice between class Xyz and class XyzType the XyzType 
javadoc is more useful.

Notice that the package hierarchy follows the namespace hierarchy 
defined by the spec.
Also note that implementation is separated from interfaces and that 
clients typically use interfaces only.

I would be interested in any analysis of the generated bindings.

I would also be curious if a JAXB bindings based approached could be 
cosnidered by opensaml project for SAML 2.0 ( I can provide similar 
bindings for 2.0 in no time).

Thanks for sharing your thoughts.

--
Regards,
Farrukh




Farrukh Najmi wrote:

> 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.