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.
Most of the information needed can be set using standard Apache commands in the configurations that Apache supports.
ServerName
directive either in the main configuration or the proper virtual host. This could be the hostname of a web proxy that is handling the actual requests from users.VirtualHost
definition in Apache 2.0 and the Port
command in Apache 1.3. This is the port users must access, and not necessarily the port the virtual host is actually listening on.http
or https
) is set based on whether SSL is active on the incoming request. If this isn't accurate, you cannot rely on the web server to properly generate redirects and it must be supplemented by Shibboleth configuration. This will not correct redirects from elsewhere in the environment. You can use the ShibURLScheme https
Apache command to override the value determined from the request if all external access is handled with SSL through an offloaded device.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.
<ISAPI>
configuration element in ShibbolethXml defines the mapping from IIS Site/Instance IDs to virtual hosts.<Site>
element contains mandatory id
and name
attributes specifying the mapping from site number to canonical hostname respectively.port
, sslport
and scheme
can be specified per-site to override the data supplied by the client request.scheme
and port
be set to properly normalize requests so that redirects will route back through the SSL front-end. Note that sslport
is not used in this case (it applies to scenarios where both SSL and non-SSL ports are accessible for one virtual site/host, but not at the ports expected).