Single Sign-on (SSO) capabilities at the University of Hawaii are generally provided by either the Apereo Central Authentication Service (CAS) or Shibboleth Identity Provider (IdP).

CAS Session Management Information

The primary responsibility of the CAS server is to authenticate (AuthN) users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. A CAS SSO session is created when the server issues a Ticket Granting Ticket (TGT) to the user upon successful login.

• Ticket-Granting Ticket (TGT)
  • Successful authentication to CAS issues a TGT to the user which may be used for SSO
    
    • The TGT is stored as a browser session cookie
    • TGT idle timeout: 2 hour sliding window
    • TGT hard timeout: 8 hours from date of TGT creation
• Session Management
  
  • Each application maintains its own session state. *
  • Applications may choose to use or ignore the CAS SSO session state.

Shibboleth IdP Session Management Information

The primary responsibility of the Shibboleth Identity Provider (IdP) is responsible for user authentication (AuthN) and providing user information to a Service Provider (SP).

The Shibboleth IdP outsources its authentication of users to CAS. Shibboleth IdP sessions implicitly establish CAS sessions, but not vice versa.

• Implications: 
  • If you first log into Shibboleth IdP-enabled service (for example, Google@UH Gmail), you can later seamlessly SSO to CAS sessions
    
    • Some CAS-enabled applications may choose to not support SSO
  • First logging into CAS will not seamlessly SSO to a Shibboleth IdP session
• The IdP does not maintains its own sessions, distinct from the CAS session, The IdP relies on and uses the underlying CAS session *
  
  • Because the IdP relies on CAS for AuthN, it is subject to the previously discussed CAS session details *

Reference:

• https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631620/SessionConfiguration

Google Session Management Information

Circa summer 2018, Google has added a forced Shib re-authentication for G Suite.  Every 24 hours G Suite will automatically check for a current SSO session, and will force an SSO re-authentication if no current SSO session is found.

Previously, Google allowed the caching of SSO sessions in the browser, so while an SSO session may have expired, Google didn't check, effectively allowing a user to continue using the SSO session until the browser dumped the cache and triggered a new SSO authentication.