ASP.Net MVC Applications have four different sessions/timeouts that can impact (a) the user's session-state data, and (b) whether or not the user will have to re-authenticate for any given HTTP request.

The primary tool used to manage user sessions should the the ASP.Net Authentication session, because that directly controls redirects to the login page.

Recommended Settings

  • ASP.Net Authentication Session: 15 minutes - max idle time between page requests; if app is idle longer than this period user will be forced to re-authenticate on next page request.
  • Session Data: 20 minutes - max time to store user state data on IIS server between page requests; if exceeded during active session user will experience delay while state data is refreshed
  • Accelerator Session: hardcoded to login time + Session Data timeout + ASP.Net Auth Session duration; if Session Data expires during active session and Accelerator Session has expired, user will be forced to re-authenticate.
  • IIS Application Pool: default for rotating restart period or configure for specific times of day.

ASP.Net Authentication Session

Controlled by: The Web.Config setting <authentication><forms>

Default: 15 minutes, set in our generated web.config file.

Tracked By: An .ASPXAUTH cookie

Cookie Contents: A token indicating successful login.

Impact: This controls the flag Request.IsAuthenticated, which ASP.Net sets for each request to let the app know whether or not the user has successfully entered credentials. ASP.Net also manages redirecting to the login page and redirecting after successful login, using the configuration attributes loginUrl and defaultUrl. Finally, the attribute slidingExpiration is used to reset the session timer for every HTTP request.

When ASP.Net determines that the authentication session has expired, it automatically redirects the user to loginUrl. It does not modify any session state data tied to the user's, which is tracked by a different cookie.

Session Data

Controlled by: The Web.Config setting <sessionState>

Default: 20 minutes, set in our generated web.config file.

Tracked By: An ASP.Net_SessionId cookie

Cookie Content: Random number; may be reused from one Authentication session to the next for different user accounts logging in with the same browser without closing the browser.

Impact: If the user's session state gets cleared, then on their next HTTP request AB_MvcApplication::Application_PreRequestHandlerExecute() will check if the ASP.Net Authentication session is still actvie, and if so it will attempt to recreate Session["User"] using the Accelerator session cookie. This is an AB_ValidatedUser object, which can only be created by successfully calling the framework am_ValidatedUserAndGetSysEntity() service.

If either the ASP.Net Authentication session has timed out or the session cookie has expired or is invalid, the user will wind up redirected to the login url /Home/Index, with the originally-requested url passed as an argument.

Notes: The session data is explicitly cleared (a) when the user requests /Home/LogOff, (b) when the user requests (or is redirected to) /Home/Index. This ensures that whenever the user logs in they start with fresh session state, with no inappropriate data leaked through into their new authentication session.

Accelerator Session

Controlled by: Calls to AB_ValidatedUser.am_CreateUserSessionCookie() can create the cookie, with an argument to set the expiration period.

Default: Default expiration is 15 minutes from login

Tracked By: A session cookie

Cookie Contents: An encrypted string containing the user's Accelerator Framework userid, password, and security component token.

Impact: Used to recreate the Session["User"] AB_ValidatedUser object if the Session Data state information gets cleared while the ASP.Net Authentication session is still active. This is primarily a work-around for losing the session data due to application pool restarts because we typically use InProc mode for the session data.

IIS Application Pool

Controlled by: The Advanced Settings for the IIS Application Pool used by the MVC application.

Default: Application Pools by default will restart every 1740 minutes (29 hrs). The application pool also restarts automatically whenever any files in the application's deployment directory are modified.

Tracked by: Timer within the Application Pool process and/or IIS.

Impact: Clears Session Data when <sessionState> is configured to use InProc mode, which stores session state data within the application pool process' memory.

Alternate Configuration: The Application Pool can be set to restart at specific times of day when active users are unlikely to be using the application. The session state mode could also be changed so that restarting the app pool doesn't impact the session state.