Shibboleth Developers

[Alistair Young <>]

> "how can we fix that?"
speaking as a Java SP developer, the first step in addressing this question 
is how do we know there's a problem in the first place? By "we" I mean people 
who develop Java SPs that need to interoperate with the Shibboleth 
implementation. Unless you know where to look, the "specs" aren't obvious.

Someone mentioned in this thread that the time would be better spent 
enumerating the alternatives already available and as someone else said, the 
frameworks upon which one can develop a Java SP are without number, almost!

Would the time be better spent producing a compatibility kit for SPs. Best 
practices, metatdata, trust etc. Yes you can get all this from the SAML specs 
but from what I've read the question seems to boil down to two options. 
Either produce another Java SP to add to the available ones but develop it 
"properly", or instead of developing one, become a "standards enforcer" (in 
the nicest possible way) by helping SP developers see the errors of their 
ways ;)

cheers,

Alistair


-------------------
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig

On 27 Aug 2010, at 06:16, Scott Cantor wrote:

>>  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.
> 
> That's kind of the problem from the Shibboleth project perspective. The 
> more apps that "get by" with insufficient metadata and trust management, 
> the more our community has to suffer. Those implementations are simply not 
> viable operationally, and the question we're trying to answer is "how can 
> we fix that?". Can we get them to take their software seriously (clearly 
> with OpenSSO, the answer's probably no, that code is dead), or do we have 
> to fill the gap?
> 
> -- Scott