Authentication in clustered web application without sticky session

Question

I have built JSP/Servlet/Struts application in the past on a cluster of app servers. Each app server has its own JVM running the Servlel Container. All of the HTTP requests come into a hardware load balancer, which directs the requests to one of the app servers in the cluster.
I have wanted to use the Java HttpSession management without any kind of distributed session provided by the app server. We have used "sticky" sessions. The application writes a cookie to the client on the first request. The load balancer looks for that cookie on subsequent requests and directs the request to the server that originally wrote the cookie. This ensures that all requests within the same session are handled by the same application server. This also means that if I do request.getSession().setAttribute("authenticated",true) on one request, when I do request.getSession().getAttribute(authenticated) on subsequent requests in the same session, I can be sure the value will not be null. This allows me to create a filter that checks for that session attribute on each request, and if it is false or null, redirect the request to some sort of login page. Otherwise I can be sure the user has logged in.
I want to build a stateless/non-session based application that can still handle authentication. What I mean by that is that I don't want the load balancer to have to send requests for the same session all to the same server. I would like the load balancer to send each request where ever it wants. That means the simple authentication example I explained in the last paragraph would not work. The user could login on server A, but then on a subsequent request during the same "session", the user's request could be handled by server B. In that case, the session attribute would be null, and the app would think that the user has not logged in.
My application can require that users have cookies enabled, so therefore I can assume the user is accepting cookies (I would have something to check that and redirect the user to an error page saying "turn cookies on" if cookies weren't on). I think one thing that I could do is use encrpytion with a key that is shared between all the servers in the cluster. For example, user logins in on server A, server A writes a cookie with the contents "username,1109272102009". The first part being the username that the user successfully authenticated as and the second part being a timestamp for when the cookie was created. The contents of the actual cookie would be encrypted and I would send the ciphertext as the value of the cookie. When server B gets the cookie, it can decrypt the ciphertext (using the same key as was used to encrypt the data on server A), and check that the username is valid and that the timestamp does not exceed some timeout. The timestamp in the cookie would then have to be updated for the next request.
So my question is (thanks for sticking with me and reading this really long post), has anyone done anything like this before? Is what I have described totally ridiculous or insecure? Are there any books or articles that describe a pattern similar to this that has been know to work well?

Answer 1

I have worked on a web site that did exactly that.
The cookie contained a little bit more information - there was a small amount of user data that were needed on heavily accessed pages.
You'll have a problem if your web application uses attributes. We solved this by keeping most stuff in hidden inputs (backed up by hidden input cryptographic checksums in places where forgery was a concern.) HttpSession attributes have some problems and gotchas.
A few possible fine tunings:
Add a random number to the cookie. Should make known plaintext attacks harder.
Add some extra stuff to the cookie, so that any random hex string that happens to decode to "xZoiyqw,15" isn't accepted. It's easy to try a million cookies until you get "<something>,<integer>" but getting "<something>,<integer>,HelloHowAreYou" is a lot harder.
Be paranoid in checking the format of the cookie. If you add a random number, check that it is all digits etc. Belt and suspenders: also check that the time stamp isn't in the future (allow e.g. 15 seconds future time, in case different servers' clocks are a bit off.)
Don't update the cookie at every hit, only if the time stamp is older than a couple of minutes. Saves encryption CPU power.
After encrypting, prepend a short version number to the cookie. E.g. if the hex cookie is ABCDEF, make it 1ABCDEF. If you later e.g. change the encryption algorithm, change version to 2 and you can easily skip any obviously non-decipherable cookies. A second version number within the cookie might or might not be useful.
Even though you can make random load balancing, consider not doing that. E.g. a server might pull the user's name from the database into memory cache. You get less database traffic and smaller caches if the user still goes to the same server. If a server goes down, only then switch him elsewhere. Downside though: if one server is "half alive" (doesn't respond to requests but alive enough so the load balancer doesn't notice the malfunction), all users bound to that server see a 100% failure.
Benchmark cookie decryption time when selecting the crypto algorithm. How many hits per second you can get and how many you need.
Guard your crypto keys like the crown jewels. Change them periodically and whenever someone in your company (especially IT department) gets the pink slip.