Spring security without session replication

[subhashish]

Hi,
We are building a web application and will use Spring security 3.1 for authentication and authorization. We are thinking of building it in a "stateless" way where a minimal user state information is stored as encrypted cookies and nothing on the server. This is to achieve scalability of course.
However, since Spring security puts the security context in HttpSession, this will mean a need to replicate HttpSession across nodes in a cluster. Is there a way Spring security can be made to store the security context as enrypted cookies? That way we can forego the overhead of replication (some scenarios might necessitate synchronous replication).

Thanks,
Subhashish

[spgmx]

I bet a serialized the securitycontext is to big for a cookie...
But try it... look into the HttpSessionSecurityContextRepository and adapt the code to store the context in a cookie

[subhashish]

Looking into the serializable things that the context contains, it's only the string representation of principal and a collection of granted authorities i.e username and all associated permissions. Basically boils down to storing a few strings. Should not be too big for cookies IMO. Let me give it a try. Will post back the results.

[spgmx]

Such a big cookie maybe contra-productive in terms of scalability. Every request and response will piggyback it.

[Rob Winch]

Please keep in mind security is complicated and if you are implementing your own strategy you are likely going to miss something. For example, encryption guarantees confidentiality but does not guarantee integrity which is more important in this instance. You also need to worry about things like replay attacks, you lose the ability to forcibly terminate sessions, and countless other problems (too many to go into in a forum).

If I were you, I would determine if there really is a scalabily problem with using HttpSession. If there is, try consulting your containers documentation and/or forums (you may have a setup issue). Additionally, most containers will allow using a standard "big data" solution for your HttpSession. For example, you could swap out HttpSession with something like Memcached or Terracotta. This way you are not having the world of security ride on your shoulders. If your container does not allow swapping out of the HttpSession, you can write an SessionRepository that uses one of the "big data" solutions (i.e. large cache, nosql db, etc).

[subhashish]

Both of you've made good points. I must confess the size of the cookies as well not doing this the "standard" way was at the back of my mind. Our container is Tomcat 7. Let me explore session clustering with terracota or memcached instead.