Shibboleth Developers

["Howard Gilbert" <>]

> -----Original Message-----
> > The handlerURL of the Sessions element must be an absolute,
> > complete URL(instead of "/Shibboleth.sso",
> > "https://localhost:8443/shibboleth-sp/Shibboleth.sso";.
> 
> 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
> ...
> 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.

The HandlerURL has nothing to do with the RequestMap of the Resource URL.
That's both the point and the problem.

You send a request for https://somehost:9443/secure/miers.opinions.

The RequestMap looks at https, somehost, 4993, and secure to decide what
Application this is and whether the file requires Shibboleth authentication.
If you decide it is sensitive information, then you ask the IdP to POST an
assertion to the AssertionConsumer. Now it may make sense that the
AssertionConsumer might be on https:, somehost, and 9443, but there is
nothing that specifically requires it. Logically you have to send the data
to the same machine or, right now, I won't be able to do the right thing.
However, that machine may have several names, and it may expose several
ports, and in order to duplicate the relatively promiscuous behavior of the
ISAPI filters I do not preclude the possibility that the handlerURL is
https://somehostalias:8443/Shibboleth.sso 

Now in a rational world the host name and port number that the secure data
uses would be the same hostname and port number that the Metadata officially
advertises as the AssertionConsumerService. However, if the data used to be
on another machine, the URL was given out, and then both the data and the
machine name moved last week to this server, while the
AssertionConsumerService URL was configured to another hostname last month
when I joined the federation and the SP and the machinename moved to this
server last week, then the code physically can protect the data that used to
be on another machine using the AssertionConsumer URL that used to be on a
third machine.

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.

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.