Client Side Sessions

Question

I want clients of several related web applications to maintain their own authentication state. This improves scalability because session replication between cluster nodes is not required. And this simplifies the integration of various server technologies such as Java Servlets and PHP.

My plan is as follows:

• Set a signed and encrypted cookie with username and session expiration time after client authentication.
• When a client sends a request, the server decrypts and checks the cookie and grants or denies access depending on the cookie values.
• Session termination will be updated by resetting the cookie.

All servers that want to use a session should only know the cookie mechanism and decryption key. See Also: Client Level Session Status

Is this approach appropriate? Is it possible to integrate it into a servlet container / application server so that it is transparent to applications? The servlet should be able to use HttpServletRequest # getRemoteUser (), for example. Is it possible? Or do I need something above the container level, like Spring Security? Are there existing libraries for client-side session management?

Answer 1

Not a good idea. Storing vital data, such as session expiration and user name entirely on the client side, is too dangerous IMO, encrypted or not. Even if the concept is technically safe in itself (I can’t completely answer this question, I’m not an encryption expert), hacking could be facilitated without harming your server by simply purchasing an encryption key.

Someone who takes possession of the key can generate session cookies at their discretion, impersonating any user for some period of time that the classic concept of the session is designed to prevent.

There are better and more scalable solutions for this problem. Why not create, for example, a central session verification instance that all related servers and services could query? Take a look around the Internet, I am 100% sure that there are ready-made solutions that meet your needs.

Answer 2

This improves scalability because session replication between cluster nodes is not required.

First, using an HTTP session does not really stop you from scaling even when using HTTP session state replication (some mechanisms are smarter than others, by the way, for example, WebLogic in-memory replication does not have a lot of overhead). Secondly, do you really need this? Most applications (most) do not need session replication. Thirdly, I understand correctly: are you planning not to use an HTTP session at all?

(...) Set a signed and encrypted cookie with username and session expiration time after client authentication.

Do not do this! Do not store the username and other reasonable data used by the server in a cookie, this is a very bad idea! You really have to admit that this is just a matter of time before someone finds out how your system works and breaks it (especially if your cookie is a candidate for crib ). So, really, you have to store the data in a server-side session and only the identifier in the cookie, as if everything is working. It is much safer.

Is this approach appropriate?

No. And you do not need this for an interoperable single character (if this is what you are trying to build). Just use a centralized authentication solution like CAS Jasig , which has libraries for various technologies.

Answer 3

I do not agree with the posters, saying that this approach is unsafe. Variants of this are used in a number of well-proven systems, such as Rails and Play !, precisely for the reasons you drew, and are perfectly protected when implemented correctly.

Answer 4

This is actually not the way sessions are performed. The cookie itself should not transfer the data of the session itself, it is just a link to it.

What the cookie contains is usually a Session ID , which is then associated with data on the server.

If you do not have a central data session server to access other servers, I suggest getting it :).

Answer 5

You can avoid data duplication in a cluster environment by using a state server - a server that is well known to all cluster nodes and supports session data for all users. Each time a user executes a request, he sends a cookie with a session identifier to the application server; this one should get the session from the state server. This is possible for asp.net development, but I'm not sure how simple Java supports this approach.

Answer 6

As Pekka said, this is not a good idea. You can intercept your cookie with sensitive session data. Even with SSL using fiddler2, decrypt traffic