Should i limit ASP.NET user sessions to a single active session?

Question

I am designing an internal asp.net 4.0 application where user gets into the system without entering any login and password. This is a timesheet application and user is authenticated via system user name (compare system user name with the user table in the DB). Each user belongs to certain group and each group has different access permissions.

Apart from saving last login date and time, do i need to save the unique session id with each user in the DB (saving last session id in the user table and checking if the users has valid session).

Is this a good practise to keep the user session alive until he logs out or close the window (no matter how long he leave the window open)?

Normally session level details are saved in the database where user is getting into the system via user login and password but in my application there is no login page.

Answer 1

Apart from saving last login date and time, do i need to save the unique session id with each user in the DB (saving last session id in the user table and checking if the users has valid session).

No, you do not, as it's possible for a user to have more than one session while attached to the database.

A user can easily go into a private browser instance and access the site. Viola, new session.

You're not really gaining a security benefit to check to see if the session id matches, and on top of that, you'd have to hook into the session ended event and wipe the last session id from the database; if the user's session times out and they come back later, their session ID will be different and it will be valid.

Is this a good practise to keep the user session alive until he logs out or close the window (no matter how long he leave the window open)?

You could keep the session alive by having an AJAX callback in your pages that pings the server before the session timeout.

However, I'd say this is an absolute no-go. It's a security issue. If someone leaves the workstation open, and the page open, then someone else can access the site under that user.

Even if the user forgets to close the browser, and leave the workstation open, at least the session will time out and the user can't access the site.

Of course, that assumes the scenario is not using Internet Explorer, it will pass the credentials of the logged in user to the site automatically. However, if other browsers are used (Safari, Firefox, Chrome), then the Windows credentials are still used, but the user is presented with a username/password dialog, so you get a minor modicum of security there.

In general, keep the session timeout. Don't circumvent it unless you have a very good reason.

Normally session level details are saved in the database where user is getting into the system via user login and password but in my application there is no login page.

You shouldn't be doing anything to actively link a session in your database, unless it's for tracing purposes only. When a user logs into your application, you're dealing with the user, you don't care to make choices based on which session ID they have (that number is random and meaningless for this task), you want to make choices on the user .