Shibboleth Developers

[Tom Scavo <>]

On 5/23/05, Scott Cantor 
<>
 wrote:
> >
> > https://idp.example.org/shibboleth
> > https://sp.example.com/shibboleth
> >
> > In my (limited) experience, using two separate domains makes it easier
> > to upgrade the out-of-the-box config.
> 
> I have a hard time seeing how introducing an easy to mistype difference
> that I barely spotted would be helpful...

You could make the difference more pronounced, but I was trying to
stay within the example.* family of domains (which is what they're
used for).  Maybe that's more trouble than its worth.

Here's my experience with this stuff.  The config files I was given
had a single entity acting as both an IdP and SP (one providerId). 
This made it difficult to know when either the SP or IdP were being
referred to in the config.  Using a combination of the Guides and
trial-and-error, I separated the IdP and SP into two:

https://idp.example.org/shibboleth
https://sp.example.org/shibboleth

Next step was to continue breaking it down to two separate domains:

https://idp.example.org/shibboleth
https://sp.example.com/shibboleth

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.

> > Related to this, the config files should not assume InQueue
> > membership.  Instead a bilateral trust relationship between
> > idp.example.org and sp.example.com should be hardwired in.
> > Configuring to InQueue out-of-the-box adds significant complexity to
> > the install, I think.
> 
> One metadata file is complex? Until InQueue shuts down of course, at
> which point we'd substitute the self-registration federation.
> 
> I did suggest to Walter that the IdP stop treating InQueue as the
> default RelyingParty though. Maybe that's what you're referring to, the
> SP really doesn't have much InQueue in it.

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.

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.

Tom