Expire a Session differently for different classes of users on a single site

[william conley]

Is it possible to expire a Session (require re-authentication) for different users based on the "class" of user ... or failing that manually terminate a session for a user who has had no activity in XX minutes?

[Bear Bibeault]

Sure. Don't rely upon session expiry for a "security timeout". Keep track of the user and their role in the session, and the timestamp of last access. If the current request occurs after the period allowed for that user's role, force a re-login.

As this is nothing that is Tomcat-specific, it's been moved to the Servlets forum.

[william conley]

Sounds like a good idea and a "Best Practice".

Now: How do I force a re-login?

I'm a php person ... not so much a Servlet jsp person ..., but I need to work this out in an existing .jsp application and need a reference point to start from.

[Bear Bibeault]

Use a servlet filter to make sure that a person is authenticated before going to a secured page (as well as to perform the timeout checking). When they exceed their timeout, force them to reauthenticate before they can proceed to the page.

[william conley]

Very general, but the concept must also apply to those already on the page. If they walk away from their machines, their session will expire automatically. But I need that to happen at a different rate for different people, based on Class (administrators - higher expiration time).

So it's not just about "entry", but about the expiration of the session at any location. Obviously this is already handled by the session system that's built in. I can easily increase this for everyone ... but I need it to be class based and on all pages not just the entry page.

At this point I am personally a bit of a beginner in the tomcat arena, but I am quite adept at PHP and see the parallels. I just don't know how to "kill" a session manually ... and then of course I'll need to add a utility to track "last usage" (unless there's a method to query the session to get last usage already) and then I can use the last usage to "kill" regular user sessions early (while allowing administrator sessions to survive to the end of the regularly scheduled session).

But all of this is greek to me in Servlet Land. LOL

[Bear Bibeault]

william conley wrote:Very general, but the concept must also apply to those already on the page. If they walk away from their machines, their session will expire automatically

That makes no sense. All that matters is when they make the subsequent request. It's either within the duration specified for their role or it isn't. The "moment of expiration" is uninteresting and unimportant.

and on all pages not just the entry page.

That's why you use a filter. Putting this logic on any page is a mistake.

At this point I am personally a bit of a beginner in the tomcat arena

This has nothing to do with Tomcat. It's a servlet issue that's applicable to any container.

I just don't know how to "kill" a session manually

You don't. Too many novices try to micro-manage the session. Don't make the same mistakes. The session itself is uninteresting. What's important is what you put into the session. Again, do not rely upon the session expiry for this. You will fail. Use the session -- don't rely upon the session.

and then of course I'll need to add a utility to track "last usage" (unless there's a method to query the session to get last usage already)

You're over-thinking it. Simply record the timestamp of each access in the session.

[william conley]

Thank you. In essence what I'm getting here is: store access time in the session and compare to it when each page is requested. Require a sign-in if the limit is reached based on my calculations as opposed to whether there is still a session. The existing application relies solely on the existence of the session (an expired session causes a sign-in request at present).

Now I have to find out how the existing application is handling the sign-in / expiration and override it.

Be patient with me, I have to twist my brain into jsp and I have not even begun to do so. I'm still in PHP mode (and have to go back there now and finish another application before I can look at this). I do appreciate the push.

[Tim Holloway]

Bear Bibeault wrote:Use a servlet filter to make sure that a person is authenticated before going to a secured page (as well as to perform the timeout checking). When they exceed their timeout, force them to reauthenticate before they can proceed to the page.

This only makes sense if you are using a user-designed webapp security system. Long-time Ranchers already know my position on user-designed security frameworks.

If you are using J2EE standard container security, you can force the user to re-authenticate by invoking session.invalidate() in J2EE code or session.logout in JEE code. That will log the user out, and thus trigger the server to run the login process automatically on the next secured client URL request.

Unfortunately, to get to a servletlistener that could handle this logic, I'm pretty sure you've already passed URL screening. So in order to secure the current request whose login status was changed in transit, you'll have to redirect back to the server for another go at the container security framework if your logout code was executed.

[Bear Bibeault]

Tim, can JEE security handle the requirement for differing timeout durations?

[Tim Holloway]

JEE concentrates on doing two things (authentication and authorization) and doing them with iron-clad reliability. No bells and whistles; you cannot have security exploits in code that isn't there.

However, the very simplicity of the core security framework means that it can be used as the underpinnings for more sophisticated endeavours. Case in point:

What I would do if I had various classes of users with differing timeouts would be to install a servlet listener at the head of the chain (in order to avoid possible exploits of later services). This listener could then use the username placed by the container into the HttpServletRequest as a key into a profile "database" (probably a hashtable). A variant of this would be to assign roles with different timeouts, but a user can have multiple roles.

Once I had the user's timeout interval, I could then check it against a session variable holding the timestamp of the user's previous request, and if exceeded, kick in the logout sequence.

For safety's sake, I'd also set the webapp's container session timeout so that in the event of a user's timeout interval being set too high, the container timeout would take precedence.

There are numerous variations possible on this theme, including container-specific ones (such as Tomcat Valves), but this particular strategy is container-independent while keeping its muddy little paws out of the business code.

[Bear Bibeault]

Tim Holloway wrote:Once I had the user's timeout interval, I could then check it against a session variable holding the timestamp of the user's previous request, and if exceeded, kick in the logout sequence.

That is what I proposed.

[Tim Holloway]

Bear Bibeault wrote:

Tim Holloway wrote:Once I had the user's timeout interval, I could then check it against a session variable holding the timestamp of the user's previous request, and if exceeded, kick in the logout sequence.

That is what I proposed.

Main difference was that I wanted to assert that a DIY security system isn't needed (or safe) for stuff like this. Even if the servletlistener gets disconnected or broken, the container will continue to provide the primary defense and ensure that no unauthorized URL requests get to the application code. Or even to the servletlistener code.

BTW, there was a second part to the original question, I think. It had to do with specifically logging out at the end of a set interval. And that, of course, cannot happen automatically. All we can really assert is that a session timed out by the container will be invalidated and destroyed at some time thereafter. "Thereafter" being whatever periodic sweep the container might make through the sessions (I don't think the spec covers when, or even if such a thing happens), or when the next user request comes in. Or when the app shuts down. Whichever happens first. Any "logout" code would have to be executed in the session destruction listener method.

[william conley]

That was an excellent discussion.

We'll see how the security is implemented and see if we can insert a preliminary check that can session.invalidate() at the appropriate moment based on existing user level (I'm not sure how they presently store the user class information, but it is avalable) and time-since-last (which we may or may not have to store manually in the session).

Also, this is a major client and they will want a lot of work in this system (or a full replacement in PHP which I don't see happening).

Any "logout" code would have to be executed in the session destruction listener method.

We will certainly test this and implement a logout command if need be.

[Harsha Ka]

Tim Holloway wrote:JEE concentrates on doing two things (authentication and authorization) and doing them with iron-clad reliability. No bells and whistles; you cannot have security exploits in code that isn't there.

Does this mean that container based security will be enough even for financial institutions where high security is required? Or do they need to have some custom security implementation also built in their system?

[Tim Holloway]

Harsha Ka wrote:

Tim Holloway wrote:JEE concentrates on doing two things (authentication and authorization) and doing them with iron-clad reliability. No bells and whistles; you cannot have security exploits in code that isn't there.

Does this mean that container based security will be enough even for financial institutions where high security is required? Or do they need to have some custom security implementation also built in their system?

I have worked most of my long and evil career in financial-service companies and financial technology companies.

And I can tell you flatly that NONE of the "custom security implementations" I've seen in that career were very secure.

Most of these DIY security systems are designed and implemented by rank amateurs as far as security goes. Their architects tend to be "clever" people with little or no formal training in security or encryption. Their primary job responsibilities are not security - it's just a less important side project. Their solutions tend to be designed to block people as long as they follow the rules, while being extremely vulnerable to attacks that simply run around the rules. Their interfaces must be explicitly coded right into the business logic of the apps, which means that the first clueless junior programmer who comes along in maintenance mode generally ends up punching holes in the security wall. The interfaces tend to be poorly-documented, so even senior people often don't get it right. Very often, when new functions are added, people forget to add security code - especially when deadlines are tight to begin with. Or, for that matter, when contractors are brought in.

Java is an extremely expensive platform to develop in. It takes more time and more work to do an enterprise-grade Java app than to simply zap out something in ASPs or PHP. So there has to be compelling business need to do so. Obviously, robustness and scalability are important, but one of the most important things of all is security. Few platforms have had security designed in from the very ground up, much less dedicate ongoing effort to specialty platforms built off of them. Java has, and the security was designed by full-time security specialists, not someone who was given the task in a heap of other things to do. And even with all that, as I'm sure you've noticed, Java has gotten a seriously bloody nose in the security department recently. Security is very hard to do. One weak link snaps the entire chain. Fortunately (so far) all the security issues have been in client-side JVM operation, not in the JEE security area.

The JEE standard security architecture is simple, robust, well-documented, and has more than a decade of proven worth. It wraps itself around webapps, protecting vulnerable code at the server level, and it permits multiple apps to share a common security Realm even when the apps were developed by different and unrelated organizations. For that matter, even when the apps are on different machines.

The world is full of broken software, dashed out in a hurry and poorly maintained. It makes software developers look incompetent and unreliable. Why invent yet another broken system when there's something that already does the job for 90+% of the apps? Especially since it works equally well for bare-bones servlet+JSP systems as it does for the more elaborate frameworks such as Struts, JSF, Wicket, Spring-web, and so on.

[Harsha Ka]

Thanks Tim Really useful insight