Shibboleth SP 2.5.2 on IIS authenticates with HTTP, not with HTTPS

[Cantor, Scott]

On 11/19/14, 8:30 PM, "James W. Anderson" <jamesanderson at coca-cola.com> 
wrote:

>The IIS site ID is 1, it’s listening on both http and https on ports 4160 
>(http) and 4161 (https) and is setting behind a load balancer/VIP that’s 
>listening on standard ports 80 and 443, using myfakedomainname.com as its 
>domain (actual domain withheld for privacy).
>
>If I access the site via http I get redirected. If I access via https it 
>passes me through to the site without any authentication. This seems 
>backwards to what I would expect from this configuration—I’d expect only 
>the https requests to require authentication.

The requirement for authentication is in the RequestMap, and there is no 
scheme specified, so it's neutral with regard to that question in terms of 
policy, but it's also applying that rule to the default ports only.

The site mapping is telling the software that a request to Site ID 1 
should be treated as though its non-secure port is 443 and its secure port 
is whatever the server reports to it, in this case probably 4161.

Thus, it's constructing the URL to map to policy as being on port 4161, 
and you have no such rule. You'll probably see that in native.log with 
logging high enough.

If you set sslport="443" and port="80" in the Site element, that may 
correct it. If not, you need to get some logging out to see what the 
RequestMapper is being handed.

You also do not want to specify scheme there if you're actually trying to 
handle both. If the correct scheme is the physical one, don't override it 
in the Site element.

In closing, note that IIS supports none of this properly. Virtualization 
is something Apache can do, but IIS does not, it has no ability to 
override what it reports to applications. Even with the SP working around 
that bug, your applications will still see the wrong information regarding 
name and port.

-- Scott