Site

The <Site> element provides a piece of functionality missing from IIS, namely the ability to obtain canonical scheme, host, and port information about an incoming request without just relying on the HTTP request. In addition to being untrustworthy, the client request also contains physical details about the request, which may be completely different from the logical details, which is an issue any time virtualization is involved.

As an example, consider a proxy or load balancer that runs at "https://service.example.org", and that sits in front of a pair of IIS servers running on port 8080 without TLS enabled. The actual HTTP request to one of those servers might represent the URL "http://ws1prod.example.org:8080"

If the SP relies on IIS to tell it what to do (which is what applications should do), it will produce redirects or reference itself in SAML messages using the latter URL, and not the former. That's broken. This is why IIS does not support this use case and why you shouldn't use it that way. Apache supports this. Use Apache.

Having said that, if you want a partial solution that supports broken applications running on a broken web server, you can work around the issue by manipulating the content of a <Site> element that corresponds to the IIS web site in use using settings like the following:

<Site id="1" scheme="https" name="service.example.org" port="443" />

As with all scenarios involving this feature, the content there is the logical data, not the physical. It will be the same on every server operating behind such a load balancer.

For a similar case where the back-end URLs are TLS-enabled on port 8443, you would need to replace the port attribute in that example and use sslport="443" instead. This allows a single system to be physically hosting both TLS and non-TLS virtualized sites at the same time, so the port is virtualized based on whether the physical request uses TLS or not.

Attributes

The following attributes are supported:

Child Elements