Shibboleth Developers

[Gregory Haverkamp <>]

On Wed, Aug 25, 2010 at 12:02 PM, Peter Schober <> wrote:

Given that there are many ways to do that with currently no clear
winner (which design/framework/API etc. to target) it's likely that
whatever the project chooses, there will always be some (many?) among
the targted audience who'd prefer one of the other approaches.

So I'd definitively prefer to let the v3 IdP only suffer from the
"usual delay" and not introduce additional delay.

I generally concur with this.

My Java-focused IT developers would absolutely prefer to use a Java-based SP.  It just seems to make them feel more comfortable.  However, a couple hundred apps are going to have to be Shibbolized (err, domesticated?) over the next couple of years, and it's not the least bit clear to me that a non-container-based Java solution is going to ease that process in any way.  So, a Java Shibboleth SP means waiting for the development of a filter implementation of the new libraries, followed by that praying someone other than me provides a container-based solution in the timeframe I need, using the container of choice in my enterprise.  All to provide functionality that already exists in the C++ SP, or, if the developers are really insistent, they could get by picking up OpenSSO from ForgeRock or OIOSAML or one of the other alternatives.  

Meanwhile, there's new functionality listed in the feature planning for IdP v3 that I could use today to fill a need nothing else fulfills today, and which I may have to hack together myself in the short-term anyway.

All of which is to answer the original question posed by saying, "Yes, I see demand.  Yes, the roadmap looks swell to me."  But I'd sure hate to see it delay IdP v3.

Greg