JBoss clustering when using form-based authentication

[tkitchens]

We're using JBoss 3.0.4 with Jetty. We use form-based authentication. I've read everything published on setting up JBoss clustering and it seems pretty simple. I'm pretty sure I have everything setup correctly. However, when I try to login to one of the servers in the cluster, the server apparently attempts to serialize the org.jboss.jetty.security.JBossUserRealm object, which contains the user's authentication credentials, to the other servers in the cluster. When it does this, the org.mortbay.j2ee.session.TypeCheckingInterceptor checks to make sure the object (in this case the JBossUserRealm object) is one of the serializable types. JBossUserRealm is not Serializable , so an IllegalArgumentException - "distributed attribute value must be Serializable,EJBObject,EJBHome,UserTransaction or Context" is thrown.

Am I misunderstanding something here? Shouldn't I be able to use clustering in conjunction with form-based authentication? And, shouldn't I expect to be able to login to one server in the cluster, bring down that server instance and have the session failover to another node without requiring the user to login again, assuming I have a load balancer in front of the cluster? I know that I can do this with other app servers.

Any help would be appreciated.

Tim

[slaboure]

Can you please fill-in a bug on SF for that?

http://www.sf.net/projects/jboss


Cheers,


Sacha

[tkitchens]

Sacha,

I searched the bug list two days ago and didn't find any related bug reports. So, I just went back and logged a bug report, then searched again and noticed that someone else had just yesterday logged the same bug - the only difference was that he was doing basic authentication, instead of form-based.

Seems odd to me that no one has run into this. Could it really be that we are the first to try to use any type of container-managed authentication AND clustering together? Kind of strange. Anyway, I took a quick look at the class that's causing the problem - org.jboss.jetty.security.JBossUserRealm - to see whether I could make the necessary changes. Looks like there are quite a number of classes that need to be made either Serializable or their references made transient, if in fact this is even possible.

In the meantime, any pointers or thoughts are welcome, as we'd have to completely change our architecture, since there's a huge difference between delegating authentication and session management to the container and having to manage that in your own code. Changing our architecture is really not an option at this point.

Thanks,
Tim

[slaboure]

Hello Tim,

Yes, this absolutely needs to be fixed. People don't see it maybe because it works when using session based auth (and not form-based). Have you checked if the same occurs with Tomcat clustering or not?

Cheers,

sacha

[tkitchens]

Sacha,

Haven't actually tried it with Tomcat, but if I'm correct in that the Tomcat equivalent of JBossUserRealm is JBossSecurityMgrRealm, then it appears that you'd have the same problem with Tomcat.

BTW, I see that a fix for Jetty has been added to the 3.2 code base. I'll check into that and see whether it fixes the problem for Jetty. However, from the description of the fix - i.e. made the JBossUserPrincipal Serializable - I'm not very hopeful, as the server needs to serialize much more than just this object for authentication replication.

Thanks,
Tim

[slaboure]

Any feedback? Was the fix ok for you?

[tkitchens]

Sacha,

I checked out the 3.2 branch and tried the fix that Scott Stark made. Looks like the serialization errors are gone, but I sent Scott an email that a NullPointerException problem was introduced when an instance variable, which was marked as "transient" in the JBossUserPrinciple class, was referenced on a node other than the one that the user originally logged in on. He plans to fix that, but I believe these changes still need to be merged into the 3.0 branch (we currently plan to use 3.0.6 for our current project).

However, while this fix makes the user's HTTP session available across the cluster (i.e. replication doesn't break), users are still forced to login on any new node that their session fails over to when the primary goes down. According to Scott, this is because there is no distributed single sign-on and there are no short-term plans to implement this. So, I guess the best we can get in the near-term is to have any state we're persisting in the session replicated to other nodes, but require the user to login again should a node fail. However, we can't even get there until Scott's fixes are merged into a 3.0 release.

Thanks,
Tim

[juhalindfors]

Can you please add a bug report for this on sf.net? thank you. Cheers,,


sacha