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).
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 to grant access to their applications and resources 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
- 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
- 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
- If you first log into Shibboleth IdP-enabled service (for example, Google@UH Gmail), you can later seamlessly SSO to CAS sessions
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 *
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:
* 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.