Web servers have built-in support in various ways for triggering redirections by returning new absolute URLs when resources move. Part of this functionality involves "normalizing" requests so that the scheme (http or https), hostname, port, and path of a request can be determined and used consistently when generating redirects.

When the Shibboleth ServiceProvider software issues AuthnRequest messages, a pair of absolute URLs are constructed representing the requested resource and the eventual AssertionConsumerService URL to return the requested assertion to. In some cases, the ShibbolethXml configuration can supply an absolute URL to use, but in most cases these URLs are constructed dynamically based on the normalized request URL. For this reason, it is essential that the system be configured with accurate information about the externally visible scheme, port, and hostname on which each virtual host runs.

Problems with redirect generation most frequently occur in accessing the SP's protocol handlers (e.g. https://gotham.supervillain.edu/Shibboleth.sso/SAML/POST) and in the final redirect back to the requested resource. Broken redirects most frequently manifest as 404 errors or RedirectLooping (or sometimes simply attempts to access a server over the wrong port). Rather than trying to address each of these in detail, it's more useful to discuss how these redirects are created and what must be properly configured.

Unfortunately, configuring this information is highly non-portable, and sometimes outright impossible. Web servers often claim to support virtual hosting, but this support has limits. It particularly falls apart in proxy configurations in which users access SSL-enabled front-ends to non-SSL web servers. This is not supported properly by most web servers and is not an advisable configuration. Modern servers have the CPU capacity to handle SSL traffic quite well and you will save a lot of time and effort by not needlessly optimizing yourself into a corner. At least, please read this topic before posting questions. If you don't understand it, then please ask yourself if you really need to complicate things by supporting a web server deployment that you don't fully understand.

When possible, Shibboleth pulls most of the information used to normalize these URLs from the web server and the request. The following configuration details highlight how this is done and the exceptions.

Apache-based web servers:

Most of the information needed can be set using standard Apache commands in the configurations that Apache supports.

IIS Web Server:

IIS does not appear to support proper normalization of requests natively. Therefore, ShibbolethXml includes facilities for the routing of incoming requests based on IIS site identifiers and the incoming scheme, port, and hostname can be overridden using it.