How do stateless servers work?
I try to understand this. Normally each time user login system, server side will create a session, while user client side there is cookie. When people talk about stateless serverside, stateful client side, what do they mean? server side no need use session keep track user? only use cookies on client side to check user? mean if I change server, user will not notice it and still can resume using the service?
How to configure spring-security to to do this?
Answer
Tracking a user across servers is tricky for true stateless server side. Most of the time things are sorta stateless server where logins are the exception. However, the big deal with stateless servers is that it makes clustering very simple so you can scale horizontally.
In Java you can make it stateless using either cookies to store credentials, or using distributed hashes. Generally, people accept using something like memcache and say they are stateless because the state is stored outside the webserver. That allows the user to use any webserver in the farm and still be safely authenticated. In Java we have plenty of distributed hash implementations that you can use with spring so you don't have to use memcache to do this.
The other option is to use cookies to store a cryptographic secure hashed ticket called an HMAC. Using cookies avoids using the Session so the webserver is stateless. With HMAC you can sign a block of data that cannot be forged or created by a 3rd party and is guaranteed to be originated from you. This doesn't require outside server resources (the cache) to authenticate the user so it can scale better, but there are some security concerns you have to be aware of. FYI Google uses this technique to scale horizontally. One HMAC's aren't like SHA1 or other cyrpto-hashes. They require a secret key that has to be on each server in the farm. That also has to be protected with symmetric encryption key to make sure it's stored securely on the server should someone get ahold of the file. Also HMACs information is stored in the clear so while you can put the username or email in the cookie the actual crypto hash is available to anyone. If someone were to get ahold of that cookie they could masquerade as that user. That's why HMACs are typically valid for only a certain amount of time. After that they expire so if someone does get ahold of them they can't access that account forever.
So HMACs have this weakness and you should be careful about what applications you use them in. It would be a really bad idea for Paypal to use this scheme because all I have to do is get your secure cookie then transfer all your funds to me. The big upside is everything is your app is truly stateless.
The final option is to store your java sessions in a distributed hash. Php and other platforms will dump their sessions in the database, the poor mans distributed cache, or dump them into memcache. With Java you can do the same thing. You can put your session objects into the distributed cache too. This option has fallen out of favor because people think "cool now I can dump whatever I want into my session and it will be stateless." However, as with all distributed caches there are limits on transfer speed, replication time, and payload size are linked. This is true for Java or Memcache. Keep your sessions small, and this works well. Throw everything into the session and you go right back to scaling issues you have with a single server. And really it's probably worse than if you had just made your server stateful because sometimes grid computing is worse than single server.
Update: Here are a list of Java distributed caching libraries you can use to do this:
http://www.manageability.org/blog/stuff/distributed-cache-java