Shibboleth Developers

["Howard Gilbert" <>]

I have struggled with this. I can make some comments, and perhaps be
corrected by Scott.

> sorry for not being clearer -- so, before trying this, I should edit 
> the shibboleth.xml that comes  with the distribution, and wherever the 
> string localhost occurs, change it to the real name of my host

"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

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

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.
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.

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).

So while you should not globally change "localhost", you might certainly
consider changing "//localhost" everywhere. This will be required of course
if the origin and target are not running under the same server, and the
origin has to be changed to "//???:8080". To avoid further confusion, I
suggest a strategy.

"localhost" is a alias of 127.0.0.1. Other aliases can be set up in the
hosts file (which is x:\windows\system32\drivers\etc\hosts" in Windows).
I suggest that you create two aliases such as "origin.shibdev.yale.edu" and
"target.shibdev.yale.edu" and set them both to the actual external IP
address of your host, not to the 127.0.0.1 wrapback address. I don't know
that using the external address is required, but it seems a good practice.

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. After you get over the hump, it helps you keep things straight during
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.]

Now make a resolution to remember that you must use your real machine name,
and not any of these aliases, when communicating with your real WebISO (such
as CAS), because it will not know the shibdev names and will not know where
to redirect the Browser back to the HS unless you give it your external
machine name.