Skip to Content.
Sympa Menu

shibboleth-dev - Re: Shib 1.3 configuration

Subject: Shibboleth Developers

List archive

Re: Shib 1.3 configuration


Chronological Thread 
  • From: Tom Scavo <>
  • To: Scott Cantor <>
  • Cc: Nate Klingenstein <>, Shibboleth Development <>
  • Subject: Re: Shib 1.3 configuration
  • Date: Mon, 23 May 2005 21:50:49 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sEjoX3s3aH5ZgwnfJLuWR40Oeo78vJjO4dQlbxHOBDgK/xcf0TQtR/0qdEBfy7M5hTLx/hbAfJtjxV2dS6+U3Q/dNHnaBI51+Y/VrmLZzvUbddQyO6yVpGggdaOLhZa8OCy61L8khRuZB3TJ38I3E9oSCEIqlhLQ+gOqNMcroQg=

On 5/23/05, Scott Cantor
<>
wrote:
> > Sure, that's fine. The only reason I chose example.com is that the
> > example.* domains are reserved precisely for this purpose.
> > Other than that, whatever domain you pick you're going to
> > conflict with some real use of that domain either now or down
> > the road (same problem as .sso).
>
> That's exactly why I left them both as example.org. I think using anything
> else is less explicitly an example

You have example.org, example.com, and example.net to play with. It
would be nice if example.edu were in this group of protected domains,
but unfortunately it's not.

> and I think using two different values
> that are too close to tell apart is worse.

I don't but that's just my opinion. The top-level domain is enough to
distinguish the two to a discerning administrator trying to generalize
the default config.

> Can you explain what exactly a two subdomain test is for or why that would
> be something anyone else thinks is useful in a dummy configuration that
> isn't all that useful anyway?

Well, that's my point, I guess. The default config *should* be
useful. If you configure it right to begin with (which is of course
somewhat subjective) it will be easier to adapt it to other
situations.

Apart from being useful, it should be natural as well. In that
respect, the default config should solve the bilateral trust problem.
It's the natural evolution of the problem space, right? Didn't
bilateral trust agreements come first? Right, solve that problem
first. When I saw what it takes to solve bilateral trust, only then
did I understand the benefits of federation. You have to walk before
you run.

First prerequisite is that the default config run on a single machine.
This encourages people to download and test on their laptop or
whatever they have available. (You do want to encourage people to try
the software, right? :) To meet this requirement, any config will do
(one entity, two entities-one domain, two entities-two domains).

Second prerequisite is that the default config generalize with as
little pain as possible. By "generalize" I mean two separate hosts,
which is needed to solve bilateral trust in full generality. This
requires two entities-two domains. That opens the door to federated
trust.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page