Nov 13th, 2010, 04:43 PM
Serialized Authentication tokens broken
From 3.0.0 to 3.0.4 the serialized version of AbstractAuthenticationToken has changed. The later implementations cannot deserialize instances of the older versions.
Shouldn't AbstractAuthenticationToken, and all descendants, declare a serialVersionUID, and implement writeObject and readObject? And as long as possible possible, these classes ought not to bump serialVersionUID.
The consequences for people who have stuffed a bunch of old tokens in a database somewhere, are catastrophic. Unless you can just erase the old ones and ask users to re-enter credentials, you have to execute some real hackery to promote beyond 3.0.0.
If you need a use case around serializing tokens, in our case, users create jobs that run periodically, and we serialized their tokens so we can authorize the actions of these jobs, later, when the jobs run. We probably have a way we can do this, in the future, without serializing authn tokens. We fortunately don't have deployed production systems with the serialized tokens . But we just found this problem out accidentally. How many others have already baked in old serialized tokens they'll never be able to promote to newer Spring security revs?
Nov 14th, 2010, 06:34 AM
Authentication objects are really just serializable to enable them to be stored in the HttpSession. They were never designed for long-term persistence. It should be easy to cache the user identity that goes with a job and establish a security context when you run it, without having to store the entire contents of the user's authentication object. If you really want to store the authentication object, I'd use a custom implementation, making sure it doesn't contain the password or other potentially sensitive information.
Nov 14th, 2010, 11:42 AM
Thanks Luke. I agree, saving the whole Authn object was overkill. We are replacing that strategy by rolling our own persistence along the lines you described.
Still, from an academic pov, there is still the possibility that a clustered webapp could have a build on one server running agains 3.0.0 and a build on another server running against 3.0.4. Doesn't sound like good CM but shit happens. Sharing the session among them would fail. I'm not saying this case is worth addressing, unless somebody else complains.
Thanks for the help.
Tags for this Thread