Proxying server setup help

[Peter Schober]

* Antony den Dulk <antony at selestiasolutions.com> [2016-01-20 00:31]:
> I have the following setup:
> - an internal server with IIS that talks with Tomcat - Shibboleth is
> installed in IIS - https://internal.domain.com
> - an external server that proxies to the internal server -
> https://external.domain.com
> 
> The external server is used to proxy to various internal servers and
> distinguishes the various servers using paths.
> - https://external.domain.com/division1/app1 -> https://external1.domain.com
> - https://external.domain.com/division1/app2 -> https://external2.domain.com
> - https://external.domain.com/division2/app1 -> https://external3.domain.com
> 
> I am trying to set this up so that Shibboleth sends the correct URI in
> the Authentication request, something like
> https://external.domain.com/devision/app/Shibboleth.sso/SAML2/POST.
> Instead I am getting a URI in the form of
> https://external.domain.com/Shibboleth.sso/SAML2/POST.

(N.B.: Whenever I say "routed" I meant "reverse-proxied" below.)

Not sure how well that matches your requirements but too many years
ago I integrated shib with a web hosting environment where individual
backend web servers (not sharing shib sessions) would share duty for
handling the www.example.org vhost, and some reverse proxy web server
would route requests to one of he backend web servers based on the
requested URI (/foo vs /bar vs /foo/bar etc.).
(I.e., in its basic mode each request_uri only lived on a single
specific backend).
In addition to that thousands of vhosts existed (foo.example.org,
bar.example.org, etc.) which usually would route all request URIs to a
single backend (i.e., everything in a non-www.example.org vhost would
be on the same server; though foo.example.org/bar could still have
been routed to a different server, account and file system directory
than any of the other content or paths).
So for vhosts /other/ than www.example.org the shib handlers on all
backend web servers were the usual ^/Shibboleth.sso ones.

To handle the www.example.org case, where depending on the request URI
a different backend web server would process the request -- which also
means SAML protocol messages would have to be routed to the right
backend, and so the couldn't be all using ^/Shibboleth.sso as
handlerURL -- we ended up exposing the backend via distinct publicly
accessible handlerURLs, i.e. all backend web server shared the same
ApplicationDefaults/@entityID for the www.example.org vhost (and key
material for that SP), plus each backend web server additionally had
its own ApplicationOverride, with its own entityID and handlerURL and
key material.
The individual handlerURLs encoded the "id" of each backend, say 42,
and the front end proxy statically routed those requests to the
specifc backend. E.g. /webserver42/Shibboleth.sso/... would be routed
to websrv42.example.org for handling of www.example.org/vogon/poetry

All of those entities only used a single IDP, and that IDP knew all
SPs and all their many ACS endpoints and entityIDs. (The SAML Metadata
for those was created programmatically from the same system that
managed the web hosting environment, e.g. any TLS-enabled vhost would
automagically also be shib-enabled, allowing users to opt-in to
shib-protection via the usual directives in .htaccess files. Only for
lazy sessions we needed a tiny wrapper around the handlerURL --
a mod_perl PerlResponseHandler -- so that subjects needing to use lazy
sessions wouldn't need to know what backend web server their content
was on, and possibly change it if we decided to move their data to
another web server.)

Not sure how useful any of this is to your situation, but feel free to
ask and I'll try to remember the details.

Note that one alternative I considered (and decided against, for
resilience reasons) was handling all SAML protocol messages and Shib
interactions on a single dedicated backend web server (so
www.example.org/Shibboleth.sso would always be routed to the same
webserver, say, shib.example.org, no matter what request URI was
accessed on www.example.org) and then share the shibd on that server
with all other backend web servers so sessions would magically be
available on the other servers w/o them actually processing the SAML
themselfs.
-peter