Clustered SSO with SPNEGO/KERBEROS

[j_ri]

Hello!

I have my own Authenticator for Tomcat and my own LoginModule supporting SPNEGO/KERBEROS.

In a non-clustered environment everything works fine, but if I have a clustered and configured Clustered SSO in Tomcat I run into Problems. If one of the cluster-nodes dies, the loadbalancer routes the request from the browser to another node in the cluster. The Problem is that the second clusternode tries to reauthenticate the cached credentials. Since the original login can be a certain amount of time before the reauthentication the cached credentials (=KERBEROS-Ticket) are not valid any more. So KERBEROS throws a "clock skew too great" error.

In the Tread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68777&postdays=0&postorder=asc&start=10 it is written:

It feels to me that in order to support true enterprise authentication (along with the already good clustered session support) a clustered aware authentication service would need to be developed. That while a Principal may not be able to be replicated, the underlying credentials in their various forms can. You also know when users authenticate and log off. It seems to me that this service could use these authentication events along with the underlying credential data to synchronously recreate a Principal on each node upon login, and clean up upon logoff. I suppose this creation could be deferred as long as you're willing to store the credential info and original authenticator mapping forever.

According to this it's obvious that my error is happening. But wht is the solution?
One idea could be to to turn up the "clockskew" in the krb5.conf to a whole day.
Another is to use a custom principal which is serializable and to store that in my (replicated)session to see if a user is already authenticated. But I don't know how difficult it is to intagrate this idea into my SPNEGOAuthenticator.

Any better (or easier) ideas?

Thanks
Jochen

[j_ri]

hello again,

after trying to manipulate some kerberos settings, I decided to try to force my JBoss server to propagate my serializable Principal around the cluster.

Unfortunately I didn't find a possibility for doing that.

Has anybody an idea how to force JBoss AS to propagate the Principal and not only username and credentials?

thanks
jochen

[twittemb]

Hello,

Why don't u store the principal in a distributed tables over the cluster ? The clustered SSO valve must work like this in order to make a call like that on each HttpRequest : request.setUserPrincipal (myPrincipal).

You can create a clustered table with JGroups, can't you ?

Hope this helps.

Best regards.

Thibault.

[twittemb]

"twittemb" wrote:
Hello,

Why don't u store the principal in a distributed tables over the cluster ? The clustered SSO valve must work like this in order to make a call like that on each HttpRequest : request.setUserPrincipal (myPrincipal).

You can create a clustered table with JGroups, can't you ?

Hope this helps.

Best regards.

Thibault.

[j_ri]

Hello Thibault,

thanks for your answer.
Unfortunately your idea doesn't help me, because the problem is not the web-layer, but the ejb layer.
My web-application makes a call to a stateless session bean (on node1 of the cluster) and 15 minutes later it makes another call to the bean (but this time the call goes to node2 in the cluster).

The web-appliaction is clever enough to recognize that's the same user-session and still has the principal. But the call to the second ejb gets intercepted by JBoss and the username and credentials (which got distributed in the cluster) are validated again...but unfortunately the credentials are too old now (a standard kerberos service ticket has to be validated within 5 minutes after it has been requested).

The Solution would be that the "jboss.security:service=JaasSecurityManager" MBean, configured in the jboss-service.xml in the conf-dir of a JBoss Server doesn't replay username and credential from the cache, but just keeps the information that the current user is already authenticated.

best regards
Jochen