IIS 7.5 Server behind an F5 Reverse Proxy
Cantor, Scott
cantor.2 at osu.edu
Wed Aug 20 10:47:35 EDT 2014
On 8/20/14, 10:37 AM, "Meiselman, Ellen" <emeiselm at med.umich.edu> wrote:
>Which to me means a bad path tot he IdP metadata file, most likely. I
>then revisited the shibboleth.xml settings file and corrected the
>relative paths to /Metadata, /Session, etc. since they now have the
>reverse proxy-necessitated directory /content/in the
> path. I added handlerURL=/content/Shibboleth.sso" to the Sessions
>element.
Well, you can do that, but I really don't advise that unless you
absolutely have to. Your reverse proxy should map the entire vhost to your
entire vhost. Playing games with that will make your life infinitely
harder.
>Now if I browse to
>https://proxyserver.com/content/Shibboleth.sso/Metadata
>I get this message from the IdP:
That URL should never involve the IdP so you have a very fundamental
problem going on. Your system does not know about the virtualization
you're attempting because it doesn't think the request is for a handler
inside the SP.
>Now here is where I am confused still. The metadata.xml file in /etc/ was
>given me by my IdP, and was at least apparently working before I changed
>hostnames. The only locations it contains all refer to the IdP. So that
>is the Identity Provider metadata, correct?
Yes.
>I tried the endpoint .../Shibboleth.sso/Metadata on another content
>server I have that is functional. That endpoint gives me what looks like
>it must be SP metadata. Is that xml file
> entirely generated by Shibboleth according to some template? Or have I
>just not found the file yet? What controls what goes into that file?
It's generated on the fly to provide examples for people to work on. Your
system is broken so when you access it, it's dispatching to the IdP
apparently, at least based on what you said. That means the SP doesn't
believe that the request is for a handler, but for content.
That means it's not seeing requests come in with the values you think it
is. Turn up logging in native.log and see what the RequestMap is seeing on
DEBUG.
-- Scott
More information about the users
mailing list