Shibboleth Developers

["Scott Cantor" <>]

> Even with all that, fronting a container with Apache httpd and the
> Shib SP probably is only a tiny fraction of the effort needed getting
> all this to work (such as customizing uPoral, writing portlets, etc.)

And yet people make strategic decisions based on how quickly you can setup a
dummy system...

> As for the existing Java SPs: It seems to me properly documenting the
> available alternative Java SP projects/products would be time better
> spent, but then this is not the Shibboleth projects mission.

Our concern, without casting aspersions (well, I'll cast them, and people
can just think me an ass anyway, they already do), is that we don't see
forward movement on those projects/products in supporting the features we
think are necessary. Most of them centering around metadata and trust, and
you all know what I'm talking about.

My speculation was that people in Java doing one-offs on top of opensaml now
would produce a better hack if they were building on top of a more
value-added code base than what currently is (by design) in opensaml. So
that's one aspect of it.

The more complex question is whether we could head off some of those
one-offs, which is a much harder question. Nobody likes using other people's
code, but we can make it look dumber to do it.

I really don't know if we've missed the window on this or not. It's quite
possible we have.

The point here is that we started talking about this more because the
deficiencies I see in those implementations are significant enough to hurt
this project, not so much because of the practicality of producing a
replacement.

-- Scott