Shibboleth Developers

["Scott Cantor" <>]

> The gotcha is that I cannot manufacture a handlerURL from first principles
> on a machine that has potentially many interchangeable handlerURLs that
will
> all do the same thing. Only one of them may match my published Metadata
and,
> last time I looked, the specification doesn't guarantee that I even have
> access to my own Metadata Entity description.

The original SP does require that the host/port be the same between the
resource(s) and the ACS. The lone exception being an https:// ACS supporting
http:// resources if the default ports are used.

Of course, this is an absolute requirement if you drop the cookie from the
ACS. You can drop the cookie from the resource and then pass something in
Relay State (TARGET) to recover the session key to attach to the session at
the ACS, and in that case, yes, they don't have to be the same. As I recall,
that is in some way what you're doing or at least allowing? I remember
discussing it.

> It is precisely because the handlerURL logically has nothing to do with
the
> secure resource (target) and the RequestMap that I am in a quandary, and
the
> simplest thing is to require that a complete URL (matching the one in my
> federation Metadata) be configured into the sp.xml.

I didn't see it as a problem that the vhosts have to match, and once I
decided that, it wasn't a big leap to compute the handlerURL's first half
based on the resource URL. Actually Derek really did most of that, I just
didn't change it. I recall your reasoning, however, so I'm not really trying
to rehash it. If I had the energy, I might go back and change it, but
there's a lot to do that's higher on the priority list.

Anyway, I think we have a couple of points here...

- Relationship between ACS URL and resource URL wrt the vhost
- Actual location of ACS path on vhost

(Of course, ACS can mean any handler of functionality in the software,
including logout, etc.)

In the first case, I think you support a feature the C++ doesn't. What I
think we're trying to figure out, though, is whether you *could* allow a
relative path in the case that the resource vhost is the one to use. In
other words, why not assume that unless the user overrides it in the way
that you describe? That seems like the 99% case...

The second issue seems more tied up in some of the platform differences, but
I'm coming to believe I got it wrong, even if it did work. I may also
disagree with the direction that these web servers are heading in (actually,
I just plain do), but it's a fact regardless.

It seems like the second issue is actually the more immediate one in terms
of influencing how we help people set up the software though, since it's
currently just different by default and that just has to be noted.

Am I off-base somewhere?

-- Scott