two apache instances using one shibd process possible?

Gernot Hassenpflug ha4h-grnt at
Tue Feb 12 22:11:33 EST 2013

"Cantor, Scott" <cantor.2 at> writes:

> On 2/1/13 3:27 AM, "Gernot Hassenpflug" <ha4h-grnt at> wrote:
> >
> >I understand that
> >- the session information is stored in shibd; and
> >- each apache process with the mod_shib module caches session information.
> They cache it for efficiency but the only state is in shibd.
> >Presumably success happens when the IdP redirect request is
> >intercepted by an apache instance belonging to the process where the
> >initial access was made.
> Only if there's no shared session cache, yes.

Hello all,

Thank you for the feedback, I've determined that the problem is that
the authentication requires some form of stickiness / persistence, so
I cannot use simple non-sticky load-balancing on the front-end servers

I've added stickiness at the load-balancer backend definition for
handling the Shibboleth.sso/* requests and this solves the problem. Of
course, that backend is not balanced anymore if the requests all come
from a proxy server, but that is for now an acceptable problem.

> I don't understand the rest. If you have a shared shibd, it will work, if
> not, not. Using a shared process is reasonable on one machine, much less
> so going over a network.
> >I thought from reading
> >
> >that I could run two apache processes as though they were on different
> >boxes.  I believe this works exactly as it should.
> Then I don't know what you're asking.

I don't know how to express the problem correctly, but I hope the above makes it clear enough that the thread can be useful in the archives.
> >However, nginx in front of these two instances defines a backend
> >comprising both of them:
> >
> >upstream backend {
> > server;
> > server;
> >}
> I know nothing about nginx or what that all means.
> >So this presumably causes httpd and shibd to have problems, since
> >there is no telling which instance of which apache process will handle
> >any particular request.
> It doesn't matter if they use one shibd. The Apache code is stateless,
> 100%. There's nothing that lives beyond one request other than data cached
> for efficiency.

>From Scott E. Cantor on 3/11/11 (Google's date format, no idea what
date that actually is, I assume either March or November 2011):

"You have a session with the SP, and even if you make that session short-lived, it has to span at least the SAML POST + one redirect. If that crosses servers, it fails. After that, if you can start your own app session from the first redirect, you're off the hook."


The nginx definition, using the upstream module with its IP hash
persistence functionality (there are several other alternatives, but
we do not want to use out-of-trunk modules at this stage), then
becomes something like this:

upstream authbackend {

upstream backend {;;

where "authbackend" is used for Shibboleth.sso/* requests, and "backend" is used for non-Shibboleth requests.

> >Would it be necessary to have session-awareness in the front-end, or
> >is there some way to avoid the problem as is? Or perhaps I am mistaken
> >in what my problems are?
> Sounds like it to me.

Yes, stickiness was required.
It seems that the problem is now understood and solved.
Gernot Hassenpflug

More information about the users mailing list