two apache instances using one shibd process possible?

[Gernot Hassenpflug]

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

> On 2/1/13 3:27 AM, "Gernot Hassenpflug" <ha4h-grnt at asahi-net.or.jp> 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
(nginx).

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
> >https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering
> >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 127.0.0.1:81;
> > server 127.0.0.2:81;
> >}
> 
> 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."

Reference:
https://groups.google.com/forum/?fromgroups=#!topic/shibboleth-users/-tZCDqZ_GyM


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 {
  ip_hash;
  127.0.0.1:81;
  127.0.0.2:81;
}

upstream backend {
  127.0.0.1:81;
  127.0.0.2:81;
}

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