How do stateless servers work?

Question

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?

Solution 1

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

Solution 2

A stateless service is a service that does not store any data on the application server. It reads or writes data to the database, returns a value (or not), and after that, any information on the task itself is forgotten.

A stateful service is used to perform transactions, that is a series of tasks that depend on the result of preceding tasks. The easiest example is sending an order at a web store, where you gather your products in a shopping cart, and when you check out, you enter your account data on one page, store it, then enter your billing address, store it, then confirm your order and conclude the transaction. Each step depends on the successful outcome of the preceding step, and data needs to be preserved until the last one of these steps is completed or the transaction is canceled, in which case there has to be a rollback to restore your account balance to the way it was before you checked out.

In most cases, you can implement transactions both ways, but if you were to use stateless services, your client application would have to take care of handling the proper order and completion of tasks, or you would have to find some other way to store the transaction information correctly and manage the rollbacks. That would be a stateful client-side, as you called it.

All of this is, however, quite general, and security and/or session handling would have to be considered in each of those cases. You can very well use session information to authenticate stateless service calls - you will just have to authenticate each call individually, for example by attaching a session id or user id or some other security token to the business data.