Jetty/Tomcat encrypted cookie-based session storage?

Ruby on Rails has supported signed cookie-based sessions for quite some time, with a few encrypted implementations s开发者_开发知识库pringing up since then. Python and PHP also have implementations.

Does such a beast exist for the Java servlet containers Jetty or Tomcat?

We've received significant performance gains over RDBMS-based sessions with the PHP implementation in our clustered environment, and I'd be interested in trying something similar with one of our Java applications (which currently uses Jetty 7).

I'm aware of other ways to achieve this goal (memcached, synchronized in-memory caches) but I believe that for our particular needs the limitations of this storage method (sessions finalization before output, in-efficient storage after the 4K cookie size limit, reliance on an ultra-secret server-side key) are outweighed by the simpler deployment environment for this particular application.

If an implementation doesn't exist, does anybody have any ideas why it wouldn't? (e.g. Java sessions are typically larger than 4K, and so aren't as amenable to this storage method)

We have implemented the Session-In-Cookie and used it successfully in a Tomcat cluster to allow session-sharing among 20 nodes and thus enable zero-outage deployments. I have just written the first part of a two-part series on the implementation here: http://blog.shinetech.com/2012/12/18/simple-session-sharing-in-tomcat-cluster-using-the-session-in-cookie-pattern/. This part deals with the basic implementation, the security aspects will be covered in the second part.

I'm not aware of anything in either container that would serialize a HttpSession to a cookie for you. You could achieve this sort of thing by implementing a Filter that would be able to serialize session state to a cookie on a response to a web client and deserialize it on the request. You are still bound to any client side cookie limitations and you should carefully consider the security implications of the state you are storing client side and/or how much you trust the client presenting the cookie.

It seems like there are two questions here:

1. Java/J2EE implementations of effectively stateless session-management.
2. Secure session implementations.

Regarding the first question: Yes, depending on the size of the session-graph (deep nesting of all session variables/objects) the cookie size limitation (which is effectively an HTTP Header limitation) is a significant factor. If the session-graph neatly fits inside the HTTP Header limitation (which is to some extent configurable on the web-server side) and/or can be augmented with REST based URL query parameters (to alleviate some of the state information on the server) ... then a cookie implementation is possible. This would be programmatic versus container-managed however.

Regarding the second question: Securing sessions is another matter. The notorious JSESSIONID common cookie in Java/J2EE systems is a simple token key to the in-memory or disk-cached session on the application server. It is just a map key. With that key, anyone can steal or impersonate the user-session. This is probably one of the weakest links in the entire container-managed session apparatus. There are commercial secure-session products available that prevent session-hijacking by cookie stealing, prevent replay-attacks (that can defeat SSL by capturing the replaying the encrypted login conversation to obtain a session) and other attack vectors. One product I am aware of can do this with no changes to the code (via a security filter). However, I am not aware of any general frameworks or open-source initiatives to plug this hole, probably because it requires a level of expertise that is beyond general application development.