opensamlV3 compatibility question

[Brent Putman]

On 2/15/16 12:26 PM, Francesco Barcellini wrote:
> Hello,
>
> I used opensaml V2 and I'm trying to migrate to V3 version. 
>
> After library migration the following java code did not compile;
>
> SAMLMessageDecoder decoder = new HTTPRedirectDeflateDecoder();    
> BasicSAMLMessageContext messageContext = new BasicSAMLMessageContext();
> messageContext.setInboundMessageTransport(new 
> HttpServletRequestAdapter(req));
>
> because the compiler didn't find the classes BasicSAMLMessageContext
> and HttpServletRequestAdapter.


Right, those don't exist anymore.  Read on...


>
> As declared in this url
>
> http://shibboleth.net/pipermail/announce/2015-May/000112.html
> /
> //the "compatibility between V2 and V3 is extremely substantial"./

It probably isn't sufficiently clear there in that note, but what is
really meant is compat between the v2 and v3 IdP's, from a deployer's
perspective.  Support for legacy config files, endpoints and so on.

Compat for stuff at the Java level is a completely different story.  For
example, plugins for the IdP v2 would not work as-is in the IdP v3. 
There's both simple class/package changes as well as in most cases
complete architectural changes at the software level.



>
> Starting with new project that need a migration from old V2 libraries
> to new V3 libraries I would be "extremely"
> sure that all the V2 classes are presents in V3 packages.  Is this
> guarantee?
>

No, not at all.  This is discussed in detail in our Java product
versioning policy. [1]  We're very strict about what we will change in a
patch, minor and major release.  Specifically, for a new major version
there is no guarantee of API compatibility at all.

So at the level of Java code, they aren't (necessarily) guaranteed to be
compatible at all across major versions. The v2 and v3 stacks, both IdP
and OpenSAML, at some level are completely different in that, at a
minimum, every single class lives in a new package.  Any Java code being
migrated from one to the other would at a minimum need to have imports
changed.  In some cases there are some simple class renames, e.g.
"-Helper" -> "-Support".  In some cases some more substantial
refactoring to different classes which have different APIs.

In reality, most of OpenSAML is largely functionally the same and has a
similar API between v2 and v3, and a very large percentage of classes
(modulo the package qualifier) are largely 1-for-1.  That includes
things like XMLObject providers, XML Signature and XML Encryption
support, and other security-layer components.  In fact it changed much
less than the IdP v3, where most everything was completely rewritten for
the new Spring Web Flow architecture.

The thing that changed most substantially in OpenSAML v3 is the
messaging support components:  the encoder/decoder support for bindings,
the message contexts and the fundamental way that inbound/outbound
message data is processed.  That's a totally different set of components
and API.


> So, about my example code where is my error?

It's just a completely different API now for the decoders and message
contexts.  What I would suggest is looking at some existing examples in
the unit tests, for example for SAML 2 bindings. [2]  The v3 API is
still very simple, just different and more flexible.  The complex v3
message context inheritance hierarchy turned out to be a real nightmare,
that's why it got changed.


[1]
https://wiki.shibboleth.net/confluence/display/DEV/Java+Product+Version+Policy

[2]
http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-saml-impl/src/test/java/org/opensaml/saml/saml2/binding/decoding/impl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160216/bdec8dd0/attachment.html>