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'. 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). 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. 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). 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 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. 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. Does anyone have other insights/suggestions? By the way, both HTTPS and oAuth are also statefull. Regards, Ivo GX | Ivo Ladage-van Doorn | Product Architect | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | ivo.ladage-vandoorn at gxsoftware.com<mailto:ivo.ladage-vandoorn at gxsoftware.com> | www.gxsoftware.com<http://www.gxsoftware.com> | twitter.com/GXSoftware<http://twitter.com/GXSoftware> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101213/7e25c77d/attachment.html
