Skip to Content.
Sympa Menu

mace-opensaml-users - RE: opensaml toolkit and JAXB generated bindings for SAML 1.1 XML Schemas

Subject: OpenSAML user discussion

List archive

RE: opensaml toolkit and JAXB generated bindings for SAML 1.1 XML Schemas


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Farrukh Najmi'" <>
  • Cc: <>
  • Subject: RE: opensaml toolkit and JAXB generated bindings for SAML 1.1 XML Schemas
  • Date: Wed, 13 Oct 2004 22:03:15 -0400
  • Organization: The Ohio State University

> For that there another standard Java called "XML Digital
> Signature APIs" :
>
> For Encryption there is another standard Java API "XML Digital
> Encryption APIs":

Right...but those are APIs, not libraries. Sun has a library that implements
it, and I don't know what JDKs it supports or doesn't support, but until
there's an open source implementation of them, it's fairly difficult for me
to consider them. Once the Apache library supports the JSRs, then it's
reasonable for OpenSAML to interface with the signature and encryption layer
with that API, certainly.

But that's not a "solution" along side JAXB. SAML developers should not be
interacting with that API. It has to be part of the overall object model.

Secondly, and as somebody else noted, it's just not that simple. Tools like
JAXB have a nasty tendency to corrupt XML and break signatures. Matter of
fact, standard XML schema validation does normalization that breaks
signatures. It's very hard to make this work.

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

The use of SOAP in SAML is extremely minimal by design (worthless in fact).
Hand generating the envelope is less code and less work (and faster). The
only exception might be if you're using WSS to authenticate the SAML
exchange and that's largely underneath the SAML layer. In general, I won't
use anything that isn't open source and usable on multiple JDKs. I already
have too many dependencies on things.

Aside from that, I've yet to hear many people say anything positive about
Axis. But that's not coming from me, I have no experience with it.

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

There's no real weight to the SOAP in OpenSAML. It's about 50 lines of code,
maybe less. If I added some kind of an "architecture" to make it run, that
would be extra weight, IMHO.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page