Shibboleth Developers

[Scott Cantor <>]

Tom Scavo wrote:
> So you're looking at this from the standpoint of support, which is a
> totally valid point of view.  I'm just trying to understand all the
> ramifications.

Sure, but there's also an element of me for pragmatic reasons saying 
that, well, this isn't PKI anymore, it's a new thing, and we should do 
what makes sense pragmatically for this domain of use.

> From what I've seen so far, the grid world is immersed in PKI, yes.

Well, ok, but does "grid world" == "the administrators that will be 
responsible for deploying the AA"? That's the part I keep stumbling 
over. To use an example, I run the AA for OSU right now. I have nothing 
to do with research computing at OSU. Am I the one that would be 
approached about deploying this, or is this totally separate?

> Ultimately, we will ask our users to add an AA endpoint to an existing
> IdP deployment.  We would like the installation and configuration of
> GridShib (including the metadata files) to be completely separate from
> Shibboleth, which is turning out to be quite a challenge.

Meaning that I can't use my existing AA endpoint? Even if I run 1.3 and 
I add the necessary plugins? I guess I wasn't clear on what the 
technical integration here looked like.

I don't think the configuration should be completely separate. But I 
think the starting point should be if you're presuming a new Shibboleth 
deployment and not an existing one. If it's an existing one, your 
starting point and Shibboleth's starting point are meaningless anyway. 
You're documenting from an unknown baseline, and that's a very different 
thing.

> So we will ask our users to first install, configure, and test a
> Shibboleth IdP.  That's why we have such an interest in Shibboleth
> install scripts, config files, metadata, and documentation.  If
> installing Shibboleth is easy, installing GridShib on top of that
> should be even easier.  It's a win-win situation for everybody.

I know, but I've made this case before. It's *not* easy. It will never 
be easy, because we can't tell people how to deploy SAML using a simple 
recipe. We can only describe how to deploy a prototype installation that 
will bear no resemblance to a real, functional, integrated deployment 
that is part of their campus infrastructure.

From a marketing standpoint, that sounds bad. But it's the truth, IMHO.

If your documentation explained to me in high-level terms what it is I'm 
adding to my deployment, and what the implications are, I'd be able to 
use it. If you tell me "change this file" or "run this script", I 
probably can't because my production deployment is nothing close to what 
we ship.

-- Scott