User sessions mixed up when Java app deployed to Glassfish is fronted with Apache httpd

Cantor, Scott cantor.2 at
Thu Oct 30 00:17:05 EDT 2014

On 10/29/14, 6:47 PM, "Philip Durbin" <philip_durbin at> wrote:
>Users' sessions are getting mixed up!

Unless that session is the one the SP is managing, the SP can't be
involved in the issue. That session would be the one that has the headers
populated by the SP and that's really the only manifestation of that
session. It has nothing to do with the Java container's session, for
example. And if you're doing anything to try and bind them together, it's
distinctly possible that is being done incorrectly in some way.

>This is just a demo/beta site but obviously this is a show stopper for
>us moving forward with mod_shib in production. Even on the demo site
>I'm tempted to pull Apache httpd out of our setup because I don't want
>people are looking at the demo site to get scared by suddenly seeing
>that they are logged in as someone else! We never see this problem
>when we run only Glassfish. The scrambled user sessions has something
>to do with introducing Apache httpd into the mix.

Maybe, but I'm highly skeptical of that unless Glassfish itself is doing
something to expose a bug. That's exactly how everybody else has used the
software for a decade with nothing like this ever being reported.

><Location /shib.xhtml>
>  AuthType shibboleth
>  ShibRequestSetting requireSession 1
>  require valid-user

What's the relevance of that piece?

>I'm running on CentOS 6.5 and using httpd-2.2.15 which means I'm using
>mod_proxy_ajp, as the wiki recommends (rather than mod_jk). I'm
>running GlassFish Server Open Source Edition 4.0 (build 89).

I know absolutely nothing about Glassfish other than that it exists and it
seems to be a giant pain every time it comes up.

>Any advice is welcome! Please tell me what I'm doing wrong!

I don't see anything wrong, that's pretty standard stuff. But there's
nothing wrong with the SP used in this combination with every other
container I've seen used. AJP is used routinely with both Tomcat and Jetty
without any issues like this.

I suppose one thing you could do is switch to a mod_proxy_http approach,
as one has to use with WebLogic. That can be used with any container,
really, since it's just a reverse proxy to the container. It's not the
better option, but I guess it might highlight something.

>p.s. People reporting similar problems (and how tricky it is to
>reproduce reliably):

Hmm. Well, those seem to in part indict mod_jk, which is not code anybody
should use at this point, but you're not using it. They also seem to
suggest Glassfish is a common component, which suggests to me Glassfish
has a broken AJP implementation perhaps.


That last one seems to clearly be an application level issue.

As I said initially, it's critical to identify exactly what session is
really involved here.

There's actually a Shib-Session-ID variable/header used that does pass in
the session ID coming from the SP cookie. It might help to see if that's
actually showing a switch.

-- Scott

More information about the users mailing list