Shibboleth Developers

["Scott Cantor" <>]

> 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.

Let me preface by saying that I am not talking about any specific
implementations, certainly not yours, because I don't use them. My
information is usually third hand, by inference, or from sites telling me
"our stuff won't do that" without any proof or evidence.

Unfortunately, I also can't control what bugs people report or complaints
that they make. In my experience, the people who are bothered by the
limitations are those of us with enough experience running this stuff to
recognize when there are going to be problems. But most people have a very
"oh well" attitude when it comes to bugs in their software and they won't
engage enough to demand improvement.

> Unless you know where to look, the "specs" aren't obvious.

http://saml.xml.org/saml-specifications
http://wiki.oasis-open.org/security
https://spaces.internet2.edu/display/SHIB2/TechnicalSpecs

If you don't know where to look, don't ask somebody, and go and implement
something, I can't see that resulting in a positive outcome. Note that the
vendors are included in that criticism.

> 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!

That's true, but that requires people *using* the alternatives to take the
time to survey them, and it leads to pages of claims about things that
somebody's pet project does wrong or doesn't do, and that pisses people off.
Personally, I don't much care, but that's been a problem.

> Would the time be better spent producing a compatibility kit for SPs. Best
> practices, metatdata, trust etc.

I do that by writing and commenting on specs in an open standards
organization. I spend far *more* time doing that than I'd prefer, seemingly
to no purpose given the lack of adoption. If you're tracking things and
listening to customers to understand what they need to see implemented,
that's great. But I'm afraid your implementation would be the exception, not
the rule.

And the reason we're talking about Java is that because there are a decent
number of libraries around that do some of the basic stuff, people have a
tendency to one-off some code in Java that they generally won't do in other
languages. So you tend to run into vendors running SPs on "some code we
wrote".

That's the question at hand; would a Shibboleth SP reduce that practice?
Maybe the question to ask is why so many companies feel compelled to do
that. That's a reasonable question to ask the people who have more complete
implementations. Why didn't they use one? We didn't have something we could
give them, so I've never viewed it as a Shibboleth question to ask.

> Yes you can get all this from the SAML specs

You must. Where the specs had gaps I have been filling them for years. The
expense of doing that has been very non-trivial for the project. Easily a
couple of months of work per year, I would guess.

> 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 ;)

I don't see the latter as practical or something this development team would
or could do. We don't have the personalities for it even if we had the time
and were so inclined.

I also don't think it's possible. These packages, with a few exceptions, are
often thrown together and then languish on a web site or in some larger
project umbrella because the authors are far too busy with their real jobs.
They didn't get into it to maintain something long term, and I think they
fundamentally misunderstand that that is a requirement here.

I should say, I suppose, that one option here might be whether we can find
an implementation that is already very good and just needs some polish and
extension. I don't know the answer to that either.

-- Scott