Shibboleth SP in front of HA-Proxy in http mode

Nate Klingenstein ndk at
Mon Sep 10 02:46:12 EDT 2018


My understanding would match yours.

If you can fix or resolve the httpd host, the best way I could have thought
of with Shibboleth 2.x would have been to use the exportAssertion
functionality built into the Shibboleth SP.  That way, the assertion would
have passed all the security checks.  Your Java application would take the
header, resolve it, and receive the assertion.  At that point, it's
basically parsing the XML to pull the attributes and set the environment
variables yourself.  I don't know if you could set a passable exportACL at
the httpd host, though.

But, it's not documented in the Shibboleth 3.x Wiki.  Some of the code
appears to have persisted -- I was able to set the exportAssertion flag,
but I then get an assertion count of 00 along with no separate header nor
URL to query, so I'm guessing it wasn't fully implemented.  If I downgrade
to 2.6.1, the assertion count is 01 and the query URL is present.

So, this particular workaround is not likely to work with the supported

Hoping someone has a better idea,

On Mon, Sep 10, 2018 at 4:09 AM, Jakub Danek <jakub.danek at> wrote:

> Hello,
> I would like to get a confirmation that my understanding of the process is
> correct.
> Our customer has the following proxy setup (which would be very difficult
> to change for various reasons).
>    1. Apache httpd with Shibboleth SP
>    2. Nginx proxy
>    3. Ha Proxy in http mode
>    4. Java servlet container (tomcat)
> Servers are listed in the way requests pass through. Numbers 3 and 4 are
> technically inseparable as it is an Openshift cluster deployment.
> My understanding is that under such setup it is not possible to pass
> attributes to the java application via env variables, since there is no
> sane way I can expose the AJP port from Openshift (other than assigning the
> application a fixed IP which is out of the question). We are stuck with
> HTTP proxying.
> My experiments with various configurations have been unsuccseful so far,
> but I would like to get a confirmation from someone more experienced.
> Thanks in advance!
> Jakub
> --
> For Consortium Member technical support, see
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list