Shibboleth Developers

["Howard Gilbert" <>]

> The C++ handlerURL is not just /Shibboleth.sso. It's one of three possible
> syntaxes:
> 
> /Shibboleth.sso
>       Relative path, so the scheme, host, port come from resource
> 
> https:///Shibboleth.sso
>       Special syntax, scheme is fixed, but host/port come from resource
> 
> https://host:port/Shibboleth.sso
>       Absolute URL, everything is predetermined
> 
> This accomodates a lot of different cases. If the Java code wanted to, it
> could perhaps only support the absolute handlerURL syntax, or it could
> support all of them, but have the hostname determined by matching the
> client's request against something in web.xml or shibboleth.xml.

Yes, this is the solution to my problem. The only nuance is that since Java
is context relative (unlike Apache and IIS where the filter is global), it
will be either
https://host:port/shibboleth-sp/Shibboleth.sso
or
https://host:port/{RM-Context}/Shibboleth.sso

Either should work equally well in the code, and the difference between them
is which is specified in the Metadata since the only one who actually cares
is the IdP.

Although I could map the relative forms to use the RM-Context URL, this will
only work reliably if the resource request came in over SSL so I have a
usable port number to work with. If I had to guess an SSL port number, I
would have to try 443 which is the wrong answer in the example configuration
and is often the wrong answer in many Java servers (8443 being just as
common a choice). So rather than take a chance on sending the Assertion to
some other Web Server that is sitting on the default port, it seems safer to
strongly urge the fully qualified version in the documentation.