jboss authentication issues
I've spent a couple of days poking around the internals of JBoss/Tomcat authentication code, trying to fix a problem on a customer site. They were seeing random logouts sooner than the session timeout settings.
The culprit turned out to be my misunderstanding of how a LoginModule would be used, since we have implemented a custom login module to fake a single-sign-on with another application they use. Our original intention was that the other application would use a temporary 'ticket' to log in to our application. After the user is logged in the ticket could be disposed of.
Unfortunately, while JBoss keeps a cache of authentication information, it is a timed cache where entries cannot be refreshed. It doesn't rely on it: when something is not found in the cache, JBoss checks with the LoginModule again. Since it reauthenticates for every (secured) page access, the effect is that the LoginModule gets asked to validate the same password every so often, even when there seems to be no corresponding user activity, since it's fallen out of the JBoss authenication cache.
This combined badly with a system where we were throwing away tickets after they had been used, making a later check with the LoginModule fail. Obviously the solution was to make tickets live long enough that people won't notice, but this has other implications.
In the end I'm left wishing that we hadn't chosen to use J2EE declarative security for our application. It seemed like a good idea at the time (3 years ago now), but I don't think it gained us much that we couldn't have done with a servlet Filter, and we've had to jump through hoops to make some alternate login methods work.
The culprit turned out to be my misunderstanding of how a LoginModule would be used, since we have implemented a custom login module to fake a single-sign-on with another application they use. Our original intention was that the other application would use a temporary 'ticket' to log in to our application. After the user is logged in the ticket could be disposed of.
Unfortunately, while JBoss keeps a cache of authentication information, it is a timed cache where entries cannot be refreshed. It doesn't rely on it: when something is not found in the cache, JBoss checks with the LoginModule again. Since it reauthenticates for every (secured) page access, the effect is that the LoginModule gets asked to validate the same password every so often, even when there seems to be no corresponding user activity, since it's fallen out of the JBoss authenication cache.
This combined badly with a system where we were throwing away tickets after they had been used, making a later check with the LoginModule fail. Obviously the solution was to make tickets live long enough that people won't notice, but this has other implications.
In the end I'm left wishing that we hadn't chosen to use J2EE declarative security for our application. It seemed like a good idea at the time (3 years ago now), but I don't think it gained us much that we couldn't have done with a servlet Filter, and we've had to jump through hoops to make some alternate login methods work.
