Proxying server setup help

[Antony den Dulk]

On Wed, Jan 20, 2016 at 11:56 AM, Peter Schober
<peter.schober at univie.ac.at> wrote:
>
> (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).

This sounds right - it pretty much is the same setup up until this point.

> 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).

I am not sure I understand what you are saying here. Is the IP address
of foo.example.org the same as www.example.org? If so, then the server
should know that foo.example.org should be reversed proxied to the
same server as www.example.org/foo. Is that what you are describing
here?

> 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

Do you happen to have an example of this? I can then see if I can
adapt it to my situation.

Thanks for the response,
Antony