Hi Ivo, 2010/12/13 Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com>: > Hi All, > > Another question. We are continuously speaking of the fact that our > application should be stateless. Hence no sticky sessions and preferably no > session replication. The word HttpSession is considered to be a ?dirty > word?.
Keeping (conversational) client-state on the server is considered unRESTfull because of the countermeasures (sticky sessions / replication) required to make that scale. It effectively voids the benifits the (HTTP) web architecture provides. HttpSession is a mechanism that promotes keeping client side state is therefore is considered dangerous although it may still serve a purpose. REST does not imply there is no state and that an application should be stateless which would be kind of impractical. There is application state in any real world application (architecture). It is just saying you must not hide the client-side state on the server. > Our client session should be completely stateless; some secure token is > generated, handed over to the user and the user sends that token along with > each request to the application server. Since the application server is > stateless, the end-user can be load-balanced to any node which verifies the > validity of that token. The token can be secured by adding a signature > (using a non-decryptable encryption method), generated by signing stuff like > IP number, a timestamp, a nonce and userid with some private key. To prevent > unencrypted data to be send over the line (using HTTP), the token as a whole > can subsequently be encrypted using another, decryptable, encryption > methodology. It seems pretty secure, as all data send over the line is > encrypted and a private key is involved. > > However! A client side session can never be sure, when the application > server is completely stateless (and with ?completely stateless? I really > mean ?completely stateless?; the server doesn?t store any session related > state). If the application server is stateless, once a malicious user has > found out the encryption methodologies and private keys, he instantly has > access to all users, as he can create its own tokens at will. Those tokens > will be accepted by the server as it is stateless and thus cannot verify > that this token was indeed generated by itself (or other node in its > cluster). So you need application state at the server side. That does not imply session state (as in HttpSession). The danger you are describing with regard to a static security token is a problem of the security protocol (which is why for example oAuth is a questionable solution for serious matters). It is not a consequence of not keeping session state, > Hacking the token is eased by the fact that the token itself contains all > information to do so and that our encryption method is open to the public > (the source is public). So a hacker already knows how the token is created > and can create a small application running on its own computer, replaying > our encryption methodology trying arbitrary secret keys until he has found > the proper key. Again, this is a problem with static security tokens. There is no reason (besides maybe the oAuth spec) why a token could be uniquely generated for each request/response in an interaction. > So again; a client side session with a known encryption methodology can > never be secure. There is no way the application server can really check the > validity of the token, as long as the server does not persist a list of > distributed tokens (making it statefull). Correct and there is nothing in REST that says you can not do this. > So to allow a real secure solution, the application server must hold a > session state. Some central authentication server could be responsible for > distributing tokens, and it should remember what tokens have been My understanding of many discussions online is that this approach is indeed a reasonable solution. > distributed to whom and when. To prevent a single point of failure, this > authentication server could be clustered and the distributed tokens store > should be synchronized between the nodes in that cluster. So yes, to be > honest, we will re-implement HttpSession and session replication. We in fact > moved the problem from end-user ? app server to app server ? auth server. I do not know if the store should be "replicated" or what you mean by that. It does not really matter either as that is an implementation detail of the service (and could be implemented in a RESTfull way as well). The only point is that the public interfaces should be RESTfull allowing the architecture to leverage HTTP. A quality that would be killed when you are just storing data in a HTTPSession. > So my conclusion is that it is impossible to have a secure solution which is > also completely stateless. Best solution IMHO would be to implement an > (distributable) authentication server, distributing random secret keys. > Those secrets are added to the end-user tokens, making it secure. It?s not > completely stateless (the keys must be replicated over all nodes in the > cluster), but it is secure. Sounds reasonable. I know there is a lot of discussion online and I'd like to get some insight in how other (serious) frameworks handle this topic. > Does anyone have other insights/suggestions? just the links I just googled :) http://www.infoq.com/news/2010/03/REST_security http://www.infoq.com/news/2009/06/rest-ts > By the way, both HTTPS and oAuth are also statefull. So is TCP but that is not really the point ;)
