Shibboleth Developers

[Alistair Young <>]

btw, apologies for lurking. I don't have much to contribute to the present 
portfolio but I do find the dev list a good source of profile usage 
information and pointers to comments on the standards.

Looking forward to Chad's Shibb future's talk at FAM10 in the UK. Funnily 
enough I'll be talking about a Java SP the day before...

cheers,

Alistair


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

On 29 Aug 2010, at 12:44, Alistair Young wrote:

> some interesting thoughts there Scott, thanks for taking the time to put 
> them together.
> 
> One thing I've seen more than any in the Java SP world is adopters want the 
> smallest possible footprint in their apps. Quite often, SAML/Shibboleth is 
> a very small part of their access portfolio, mainly educational customers 
> in the UK I would say, so it leads to a "that'll do for now" implementation.
> 
> Also, whereas the C++ SP is a standalone entity with its own dependencies 
> compiled in, a Java SP relies on the container to provide its dependencies 
> and if they conflict with the app's then that ends up with the vendor 
> writing one-off code to get round that, as you say. It's almost a version 
> of DLL Hell (Jar Hell!). Chad mentioned a Filter implementation but if you 
> can keep the filter as profile agnostic as possible and have the meat 
> elsewhere, you might get more adopters of a "standard" Java SP.
> 
> cheers,
> 
> Alistair
> 
> 
> -------------------
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal
>  Mòr Ostaig
> 
> On 28 Aug 2010, at 18:47, Scott Cantor wrote:
> 
>>> 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
>> 
>> 
>