Shibboleth Developers

["Scott Cantor" <>]

> Why?  Because we want to do some interop testing across two 
> domains and the previous config doesn't work for that.  I 
> need to supply config files and metadata files to each of the 
> two domains prior to testing.

Since each hostname is unique, and doing cross-host cookies is a pretty
unusual case, I'm still not sure what the point is, but ok.

> That's exactly what I'm referring to.  The natural 
> progression seems to go from bilateral agreements to 
> federated trust.  If you give me an out-of-the-box 
> configuration with two *separate* entities, I can run this 
> configuration on a single host (my laptop) and later with minor
> (obvious) modifications reconfigure it for two real security domains. 
> Making the jump to InQueue after that should be relatively easy.

Agreed. The old sample used to combine one host in both roles and that's
gone regardless. But I agree that the InQueue parts should be an appendage
on top of the base, not the default. I believe the SP reflects this, and has
since 1.2.

For practical reasons, we simply MUST include it out of the box. Almost
nobody tests both ends. That's simply a fact. They want to run one half and
test against ours.

> If, on the other hand, you give me an out-of-the-box config 
> with two entities in a single domain sharing a single 
> metadata file, I have to work harder (conceptually) to 
> generalize that to a real-world scenario.

I don't understand how seeing only half the picture is better, but ok.

-- Scott