Impact of SSO on session time out

Question

I need to implement SSO between a windows domain and a J2EE web appliction.

I've been thinking what the impact of this would be on the web application's session timeout. We have a 2 hour time out.

If we implement a seemless SSO, then I think it might become confusing for the user.

The SSO will make it appear that the web application is immediately available.

I'm worried that they will start filling in forms then go for lunch (or something) and come back after their session has timed out. However, it might not be immediately apparent that this has happened, since the SSO will just sign them on again (but now with a new session).

Has anyone any experience with anything like this and how to handle it? Do we just need to implement some form of extra messaging to tell the user that their previous session has timed out and their work has been lost?

Answer 1

I think you definitely need to pop-up an Alert box of some kind if the user's session is reset. Get them to click OK on the message and redirect them to the home page.

Also, I think a 2 hour timeout sounds like a bad idea if you're doing it how I think you are. Do you mean the user has 2 hours from when log in to work before their session times out? Wouldn't it make more sense to have something like 10 minute timeout but with the timer getting reset whenever the user sends a new request within that session.

Answer 2

The timeout is not a static fixed time measured from login but rather a dynamic measure of inactivity.

On sites we hav buit with this functionality after 10 minutes or so the web page goes back to the login page (JS used) and the user can start again if they want.

If they are busy with a long process where they are reviewing results or something then check the mouse move or some sublte key like that indicating they are still busy.

Answer 3

Old question, but in case anyone runs across it:

Try really hard to store no state in the server session. Client, fine; back-end server persistence (like a database), fine. Just nothing in between that would get lost. When the user is seamlessly re-authenticated, they don't notice the switch. Duration of timeout becomes irrelevant.

This answer is actually more feasible now, six years later, as there are several front-end frameworks that will store your data for you. You can still use Spring Security (say) on the server, as the authentication is still there with the new session; it should regenerate your security info (SecurityContext, UserDetails, etc.) on the fly. Whatever request gets or sends data should then "just work."