Shibboleth Developers

["Scott Cantor" <>]

> The handlerURL of the Sessions element must be an absolute, 
> complete URL(instead of "/Shibboleth.sso", 
> "https://localhost:8443/shibboleth-sp/Shibboleth.sso";.

This partly overlaps with the other issue, but it suggests other potential
problems.

The hardest part of the system is authoritatively determining the request
scheme, hostname, and port. Relying on the client for that means that any
configuration based on those values (e.g. the RequestMap) is suspect unless
you cover every possible client-supplied variant in your map. That's
impossible. I chose to normalize requests to a baseline, relying on Apache
when possible, but IIS doesn't offer me that option (thus the ISAPI
section).

Regardless, the end result is that I *know* how to treat the requests
properly, and so a relative path is workable. The code supports other
syntaxes though, including an absolute URL, or everything but the hostname.

I don't know whether Java can be "trusted" to supply the effective scheme,
hostname, and port or not. If it can, I wouldn't think allowing a relative
path would be unworkable, since the effective value would just be computed
as in the C++ version.

But it doesn't really signify a "difference" between them. In either case,
you have to know the hostname to know what the metadata would have to look
like, since the relative path is only a part of the URL.

The bigger issue is whether there are any holes in which the client can
supply a hostname that in turn gets used by the SP to make any decisions. If
so, there's a bug (which can be fixed either by addressing the problem or by
disallowing any use of the SP to determine per-request settings and pushing
it to web.xml or something).

-- Scott