Shibboleth Developers

["Howard Gilbert" <>]

> If you want to download the IdP or SP just to build it and watch
> metadata refresh messages appear in the log files you can do so very
> easily, but if you want to make it do anything interesting it needs a
> partner in a transaction.  

Before I am willing to connect up basic infrastructure to the outside, there
are some configuration checks I want to make. At the IdP end, I want to make
sure it works correctly with my real ID management sources. I want to make
sure that the AA is fetching attributes from the right place, and I may want
to test ARP configurations. I want to know this stuff works before I hook up
live data to any outside source.

At the SP end, I want to test the Resource Manager to make sure I am
accepting the right attributes and mapping them to the right aliases so the
access control decisions will be made properly given a real IdP. 

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.

When we deploy or upgrade Microsoft Active Directory technology, from NT to
2000, from 2000 to 2003 native, to Forest Trust, to R2, there is a period of
months in which clones of university Active Directory operate in isolated
lab environments simulating various kinds of connections and failures.
Putting anything out on the internal network is the last step, let alone
exposing it to the Internet.

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.