Shibboleth SP in front of HA-Proxy in http mode

[Jakub Danek]

Hi,

On 10 September 2018 at 10:49, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Jakub Danek <jakub.danek at yoso.fi> [2018-09-10 09:34]:
> > I was asking merely to confirm that the environment variables won't
> > work in our scenario
>
> 4 layers of 4 different web server implementations (3 of them
> proxying) for a single service certainly doesn't look pretty to me.
> Securing that (to prevent header spoofing on each layer) and making
> sure each layer sees the original IP address (for auditing and
> debugging purposes) also seems rather involved. YMMV.
>

Not much I can do about that. Especially that part why there is extra nginx
(and not httpd/haproxy) inbetween is beyond my comprehension. We have to do
our best with the world we are living in. However, access-wise, only the
first (shibboleth sp) proxy is accessible from the outer network (which
actually makes this scenario viable, imho).



>
> Personally I think it should be possible to access Tomcat via AJP from
> the front-end httpd+shib even if Tomcat runs in OpenShift with a
> dynamic IP address, as you're seemingly already able to access that
> same service over HTTP (even if that involves several layers of
> indirection via several HTTP proxies): *Something* has to know the
> current IP address Tomcat runs at, either from dynamic service
> discovery or some form of scripting. Using more automation I guess the
> relevant config snippet for httpd (where to point mod_proxy_ajp to)
> could also be updated and httpd reloaded dynamically.
>

Openshift does not expose ports or IP addresses of individual pods by
default - it uses haproxy and own internal DNS for domain-based routing
(public DNS basically points a wildcard subdomain to the Openshift router
which then routes to individual services based on the actual full domain).
"Public" ip address can be assigned, but that would involve more of
management/maintenance hassle. With the scale of our customer, that would
be a problem, afaik.


> Finally, instead of carrying forward the SAML Assertion and trying to
> verify that further down the chain (as Nate suggested) you could use
> mod_proxy_jwt_auth as mentioned/contributed on this list a while ago.
>

Thanks, I will look into that as well.

J.

>
> -peter
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180910/57d65477/attachment.html>