Shibboleth Developers

[Nate Klingenstein <>]

> The only way to put the thing through necessary tests before exposing 
> it to
> the outside world is to have both an IdP and an SP that work against 
> each
> other. During this phase I am not playing around just to look at the 
> log
> files. I am comparing my understanding of the configuration with actual
> behavior.

This is a good point, and I agree in some cases.  One of the 
differences between Shibboleth and the examples we've looked at so far 
is that in many cases an entire enterprise will only want to operate 
one half -- or less, if you count the WAYF -- of Shibboleth.  There 
will still be many sites who are only looking to build an SP or only 
build an IdP.  I'd rather not introduce more points of failure for 
these people than we need to.

I'm obviously not on a campus IT staff, so I need to ask; is there a 
reason it is inherently preferable to test these technologies with an 
internally hosted test site versus a remote one, beyond the ability to 
fiddle around with it more directly if you want to fully understand the 
capabilities on both sides?  Doesn't this seem to move away from a 
simpler installation to a more complex one?

> I am sure there are some people who are in a rush to deploy something 
> just
> to see that it works, and they may not be satisfied with a clean room 
> test.
> The rest of us want to test something to make sure that it doesn't 
> fail, and
> that requires a controlled environment.

The question I'm left with is what constitutes "controlled".  The 
self-contained IdP and SP combined deployment seems to require a site 
to understand more about the SP, IdP, and Shibboleth before putting 
either in production than deploying either individually against a test 
service or prospective partner.  This might be good or bad.

It's completely possible to do a completely internal deployment today, 
and it's also possible to test against the remote service.  It's good 
to have both capabilities.  To answer Scott, I think the real question 
is which we want to be the default.  For the sake of introducing as few 
new pieces of software and components and as little confusion as 
possible, I want the default to be testing against a known entity like 
InQueue's successor.  It's just proven easier and more intuitive for 
most people so far.