OpenSAML user discussion

["Scott Cantor" <>]

> Yes, OpenSAML 2.0 will support all versions of SAML.  The current 
> OpenSAML implementation will remain in it's current CVS branch and will 
> be bug fixed, and maybe have new features added, for some period of 
> time.  In theory, OpenSAML 1.1 and 2.0, at this time, could run side by 
> side.

That wasn't my impression, but I assume by this you mean that even though
there's some package overlap, nothing directly conflicts?

That might argue for being more explicit about things and just creating an
org.opensaml2 subtree for all the new stuff (not meaning SAML 2, just
OpenSAML 2).

> > So the SAML 1.1 support in OpenSAML 2.0 can not be used as a drop-in
> > replacement for OpenSAML 1.1?
> 
> Nope, they will not be drop in replacements.  We decided not to preserve 
> backward compatibility with this new version.

I think the need for this pretty well disappears as long as the old jar and
new one can coexist (which as I said above is actually a surprise to me).

> > Will OpenSAML 2.0 support the SAML 1.x metadata specification?  If so,
> > is this support tightly integrated with OpenSAML 2.0 or can the
> > metadata bits be used in conjunction with OpenSAML 1.1?

There really is no "SAML 1.x metadata spec", there's just a profile of the
new stuff, so there's nothing else to implement. Using the new classes to
support a SAML 1.x deployment should be fine.

> I don't know if OpenSAML 2.0 will support SAML 1.X metadata, I hadn't 
> brought that up with Scott.  It would NOT be tightly coupled with the 
> SAML 2 metadata code if it was included.

It *is* the SAML 2 metadata code. It's a separate "usage" of that code, not
different code.

The other thing here is that by having an actual metadata "respository"
notion in the core classes, we can potentially use metadata in the binding
and/or profile implementations in the core, whereas now that's all in the
Shibboleth layer. I think the overall value-add from OpenSAML itself will be
larger due to that.

-- Scott