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

Cantor, Scott cantor.2 at
Thu Oct 30 11:32:25 EDT 2014

On 10/30/14, 9:42 AM, "Philip Durbin" <philip_durbin at> wrote:
>I'm having trouble understanding what you mean.

You can't diagnose a session issue without digging into precisely which
"session" is being munged. Sessions don't really exist, of course, they're
a fiction imposed on the software layers by the association of requests
with a key, which you probably know. So there are many such "sessions" in
the picture, and I was saying that to start out we'd want to identify
which session is implicated.

> I agree that the
>scrambled sessions probably has nothing to do with the Shibboleth SP
>"shibd" process that's running. In fact, I'm pretty sure that if I
>were to stop shibd and uninstall mod_shib and the rest of the
>Shibboleth package that the problem would continue. When I decided to
>evaluate mod_shib as a solution I knew that I'd need to introduce
>Apache into our setup, that I'd need to front Glassfish with Apache to
>use mod_shib. If memory serves, I introduced Apache first (months ago)
>and we started seeing the problem, even without Shibboleth installed.

Ok. I wasn't ruling out mod_shib being involved, just that it probably
would need to be some kind of interaction between layers, and I wanted to
know which layers were in play for the session that was switching.
Basically, how each session was being related together and where.

>I hope I'm not unintentionally overloading the term "session".

It's unavoidable.

> When I say users' sessions are mixed up what I mean is that an anonymous
>is suddenly logged in as someone else. From what I understand, since
>we're using Java, what controls this is the JSESSIONID cookie that
>looks something like this:
>Set-Cookie: JSESSIONID=1190b53dc5cf345521d7e6e2ad5a

That's one such sesson. It's not a session the SP knows anything about,
and the data the SP sets into the headers is *not* related to that Java
container session in any way. So another way of saying this is that saying
they're "someone else" needs to be clarified. What establishes who
"someone" is? The SP attribute headers? A Java security context of some
sort? Both? Etc.

>1. JIRA: "The session spontaneously switches to another user. The
>JSESSIONID cookie of the victim is set for the "perpetrator" (in
>complete ignorance as well as innocence), leading to the
>session-stealing behavior."

That's a cute one. I haven't seen that, but I see what you mean. Certainly
that's a potential issue, I guess. The SP itself sets cache headers to
force expiration of responses when it sets up a session. It's of course
possible that some other code doing its own session doesn't do that.
That's why it's often risky to use tools like a SSO scheme in front of an
app but then ignore that session in favor of something internal to the
app. It's common, and often useful, but it can lead to security bugs like

>I don't protect the entire application behind Shibboleth.

See above. That can sometimes be risky.

> The general
>public should be able to browse the site. People with Shibboleth
>accounts click "Log In", select their Institution (using EDS), log in
>via their IDP, and are re-directed to /shib.xhtml which processes the
>Shib attributes and either logs users in or prompts them to confirm
>the creation of their account in our app.

The trick is, what happens then? If the SP session is then ignored, and
maybe not even used for all the subsequent requests, then the session
being switched here is apparently the Java session. So I would say what
you have here is an application issue with the way it's using that session
perhaps, or something that's causing a session cookie to be set, as in
those caching bugs you noted.

>I'm not sure I completely understand the suggestion to try
>mod_proxy_http instead. Are you saying that we would no longer use AJP
>at all? I can't seem to find much information on this.

Yes, I'm suggesting if the issue turns out to be AJP (or to rule that
out), you can do what WebLogic does, and use a reverse HTTP proxy in
Apache to do the front-ending. You switch the ajp:// forwards to http://
or https:// forwards, and use headers to pass the attribute data in. That
also means preventing any direct http:// access to the back-end Java
server at all costs, since those headers could be spoofed. It's not an
uncommon way to front-end containers.

It can be a bear to configure, which is why AJP is preferred as simpler.
And I doubt that AJP is really involved here, but it's all about ruling
things out.

>Glassfish certainly could be the problem. I don't know. I was hoping
>it's a simple misconfiguration on my part.

If it is, it would be an issue with app configuration, nothing you've
posted relating to the Apache or SP part.

>Again I'll re-iterate that we don't have any problem with
>scrambled sessions when we use only Glassfish, when there is no Apache
>in the mix.

Yes, that certainly would suggest it's not the app.

>Ok, good to know. At the moment I'm not even looking hard at the
>Shibboleth angle. I think the SP is innocent, which is why I didn't
>even bother giving the version number (2.5.3 for the curious). Mostly
>I'm appealing to the kind people on this list because others might be
>introducing Apache into their Java app server setup.

I've done it for many years with packaged apps like Confluence and Jira,
but I don't have any experience with custom apps for the most part in
Java. We do have a number on campus, again no issues there. But they use a
session from the SP to span the whole app.

>Thanks for reading this far. I wish I could say I'm enjoying my
>experience adding Shibboleth support to our Java application. It's
>been a long, hard road already and we're not even there yet. Again,
>this session scrambling bug is hard to reproduce yet critically
>important to squash.

The fact that it requires Apache is a consequence of the payoff from
building code that addresses all languages and not just Java.

The best way for us to improve other aspects of the experience is to hear
what was bad. We have no resources other than diverting developers from
coding to work on documentation, but it's still critical to know what docs
are bad, when that's a factor. Comments in the wiki pages themselves are
fine too.

-- Scott

More information about the users mailing list