Versions Compared

Old Version 3

changes.mady.by.user mhodges

Saved on

compared with

New Version 4

changes.mady.by.user Baron Fujimoto

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shib Session Management Information

...

  • Implications: 
    • If you first log into Shib (say for Gmail), you can later seamlessly SSO to CAS sessions.
    • First logging into CAS will not seamlessly SSO to a Shib session.

...

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

Info

The difference between CAS and the IdP is that CAS is commonly used by applications closely affiliated with, or "internal" to the University of Hawaii system. CAS relieves these applications of the need to directly manage user authentication themselves. The IdP is typically used by external or "federated" organizations grant access to their applications and resources using by allowing users to authenticate using their University of Hawaii credentials.

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.

  • Successful authentication to CAS issues a TGT to the user which may be used for SSO
    • TGT idle timeout: 2 hour sliding window
    .
    • TGT hard timeout: 8 hours from date of TGT creation
    .
  • 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
      • (warning) Some CAS-enabled applications may choose to not support SSO
    • First logging into CAS will not seamlessly SSO to a Shibboleth IdP session

  • An IdP SSO session is created upon a successful CAS AuthN. There are three timeout values associated with an IdP session:

    • idp.session.timeout: 60 minutes
    • idp.authn.defaultLifetime: 60 minutes
    • idp.authn.defaultTimeout: 30 minutes
  • The IdP maintains its own sessions, distinct from the CAS session *
    • (info) Because the IdP relies on CAS for AuthN, it is also subject to the previously discussed CAS session details *
    • Also, as with CAS, each application can (and usually does) maintain distinct sessions with the browser *

Reference:

 

Note
title* Sessions, sessions, sessions

All these sessions are pretty much independent and distinct: any session can exist with or without any other session, and the expiration of any one session does not imply the expiration of any other session.