Protocol Deprecation (Was: Deprecation of SAML2NameID attribute ...)

[Cantor, Scott]

On 4/17/15, 12:59 PM, "John Dennis" <jdennis at redhat.com> wrote:
>
>Speaking of SAML v1 being deprecated I have some general deprecation
>questions. My understanding is Liberty ID-FF also deprecated and
>superseded by SAML v2. Correct?

Shibboleth has never supported ID-FF, we were doing some similar things in parallel but never using it. Functionally it's entirely redundant with SAML 2.

>Is there any significant deployments in the field which still rely on
>either SAML v1 or Liberty ID-FF?

There are plenty of SAML 1 SPs in federations that use Shibboleth, it's not going away any time soon, but it's a gradual disappearance. Most of it that's left tends to be due to historical approaches to IdP discovery that were used in early versions.

I have no real insight into how much deployment there is in other sectors of either. There are always people stuck running anything, mostly because they don't design to insulate their apps from the protocols, and insist on coding to APIs that lock them into running things unless they rewrite their code. It's a trade off of perceived deployment simplicity in exchange for lock-in.

> I ask because I'm working with some
>code that supports SAML v1 and ID-FF in addition to SAML2. Supporting
>these in addition to SAML v2 makes the code much more complex and
>appears to me to just be cruft that could be cleaned up. In 2015 is
>there any reason to continue to support these other protocols?

If you're only targeting newer deployments or people doing typical things today, very likely. At least in the Shibboleth world, nobody begrudges anything that implements only SAML 2 and not 1.

-- Scott