Web Session Length Guidelines¶

Scope: OIT
Type: Guideline
Version: 2022

Timeline & Enforcement¶

By the end of 2023, all covered web applications SHOULD live up to this standard.

Exception Process/Risk Treatment Plan¶

Applications can deviate from the recommendation by confirming they meet the requirements of an applicable risk treatment plan or seeking an exception with the Unit Head.

Terminology¶

• Activity is defined as any authenticated communication from the user to the web application; web application response to activity may vary depending on technology stack
• Inactivity is the time since the last activity
• Session timeout is a logout that is automatically triggered when a session has been inactive for a specified duration
• Session timeout duration is the period of inactivity allowed before a session timeout occurs
• Global timeout is a maximum duration for a session even with activity.
• The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119

Requirements¶

Scope¶

1. This document covers web applications hosted by UCI
   1. That includes both applications from OIT and the wider campus community
   2. Federated applications hosted by other institutions and used by UCI affiliates are out of scope
   3. The Single Sign On (SSO) Identity Provider (IdP) is not governed by recommendations in this document

Logout & login¶

1. Users MUST always be able to log out by taking proactive action.
   1. When a user chooses to log out from an application that is integrated with UCI SSO IdP, only the application and IdP sessions are destroyed. Any other applications the user may be logged into will still have an active session.
2. Session timeout is a disruptive action. You should take steps to minimize the impact wherever possible.
   1. If user effort between activity might take longer than the session timeout duration, consider adding warnings that allow the user to stay logged in without browsing away.
   2. Allow the user to easily log back in and resume their work. If you push the user to a login page, preserve the URL they were on before you logged them out, and return the user there after they log back in.
3. Applications that provide access to Protection Level 4 data SHOULD force re-authentication via SSO to ensure that the user is who they say they are

Considerations¶

1. Workstation types SHOULD affect allowable session timeout duration
   1. Applications that are often used on shared workstations SHOULD use shorter session timeout durations.
   2. Applications that are only used on managed workstations can rely on the workstation session to lock, and can use longer session timeout durations.
2. User types SHOULD affect allowable session timeout duration
   1. Users who only see their own data can be allowed longer session timeout durations than users who can see data from other users.

Recommended session timeout durations¶

1. For users with access to Protection Level 4 data, use a session timeout duration of 15 minutes
2. For users with access to Protection Level 3 data, use a session timeout duration of 1 hour
3. For users with access to Protection Level 2 data or less, use asession timeout duration of 4 hours

Recommended global timeout duration¶

1. For users with access to Protection Level 2 data, use a global timeout of no more than 10 hours

Appendix¶

Shibboleth Service Provider (SP) Configuration¶

Setting Session timeout in Shibboleth SP¶

The Shibboleth SP can manage your inactivity timeout and global timeout in the Session tag. The lifetime and timeout attribute values are in seconds. Lifetime refers to the global timeout and defaults to 8 hours. The timeout is the session timeout duration and defaults to 1 hour. These defaults are appropriate for systems handling data up to Protection Level 3.

<Sessions lifetime="32400" timeout="3600" relayState="ss:mem"
  checkAddress="false" handlerSSL="true" cookieProps="https"
  redirectLimit="exact+allow" 
  redirectAllow="https://shib.service.uci.edu/ https://shib.nacs.uci.edu/">

Require Force Authentication¶

Force Authentication requires a user to sign in again even if they have an existing SSO session. To setup froce authentication, you can set the forceAuthn attribute to true in the SSO tag in your shibboleth2.xml. Note that this is a less pleasing experience, as users are forced to sign in multiple times accessing applications, so do this only if needed.

<SSO entityID="urn:mace:incommon:uci.edu" forceAuthn="true">
  SAML2
</SSO>