Shibboleth Developers

[Scott Cantor <>]

> "localhost" appears in four different contexts.
> 
> 1) as part of a URL, as in "https://localhost/...";
> 2) as part of a DN, as in "CN=localhost, O=..."
> 3) as RequestMap name, and Site name for ISAPI filter.
> 4) as part of a configuration file name, as in localhost-sites.xml

(4) of course is meaningless, it's a filename. (1) and (3) are basically the
same usage, localhost is referring to a hostname in a URL requested by the
browser, sent back in a redirect to the browser, etc. It's a standard web
address usage. Only (1) is really distinct and is needed because SSL on the
server end requires that the name match what the browser requests, and of
course, we don't have scripts to autogen a cert after prompting for a
hostname.

> These are four distinct and, I believe, independent uses of the string
> "localhost".

I think only 2 actual uses are important and distinct, but it's certainly
true that globally replacing the string isn't correct, you're right.

> Since the DN is embedded in the certificate, you can't change CN=localhost
> here without reissuing the certificate. It is not clear if you have to.

You have to if you're going to use the certificate for SSL and run the
target and AA on separate servers. In that case, the metadata has to have a
non-localhost URL pointing at the AA, and of course the hostname needs to
match the cert or the libcurl code will refuse to connect, as it must.

> Certainly, the CN here is not a fully qualified DNS name. Now certainly if
> CN=localhost is in the metadata, then the other Relying Party will check
> the certificate sent to verify that the subject in the certificate is the
> subject that the metadata says to expect. I have not found, however, that
> there is any check that "CN=localhost, O=Shibboleth Project,C=US" actually
> constrains the DNS name of the endpoint to have "localhost" as its
> hostname.

Where metadata is concerned, the name is just a string to be used to match
between sites.xml and trust.xml and possibly to validate the certificate by
comparing the Subject or subjectAltName to what's in the string. If you say
trust "localhost", and the cert says "localhost", then it will work
regardless of what machine you use. But not if you need to do SSL against it
and go off-host.

> Certainly when ISAPI maps all requests to Site 1 to "localhost", and then
> the RequestMap tells it that in that document tree the "/secure" is
> protected, none of this has anything to do with and is insensitive to the
> URL that you use to access the site (although IIS is sensitive to that URL
> in mapping the request to Site 1, but that is an entirely different
> configuration hidden away somewhere else).

Well, I wouldn't say "nothing". Those settings need to match what the
browser is expected to send to access the site or weirdness will eventually
ensue. The point of the Site element is that IIS provides *no* method to
determine the vhost's name except by what the browser sent, which is not
normally what you want to trust.

> Then rather systematically configure the target alias in any URL that
> represents the target
> (http://target.shibdev.yale.edu/shibboleth/Shibboleth.shire) [note the
> addition of a context name here which is not in the distribution], and
> configure the origin alias in any URL that represents the origin (.../HS,
> .../AA). This would help the newbie to remember which "localhost" applies
> to which.

Right, that's basically what the installer could/should do after it knows
what the proper hostname actually is.

> debugging. Now crosscheck the changes to the origin (as in
> localhost-sites.xml) with the changes to the target (in shibboleth.xml) to
> make sure the strings match exactly [we have a lot of names for the same
> machine, and windows is case insensitive as to file and directory names,
> but the checks in the code match strings exactly. If the strings 
> don't match byte for byte, you get a bad consumer URL or a provider not
> found.]

In the providerId case, the definition of the thing is that it's case
sensitive (SAML defines such matching rules for strings). In the other case,
that's a simplification that we could arguably make to the code.
Technically, it's a different endpoint, and you could argue that it should
stay case sensitive since Unix web servers generally are.

-- Scott