Single Sign-on (SSO - Grants user a Ticket ) capabilities at the University 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 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.
- 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
- If you first log into Shibboleth IdP-enabled service (for example, Google@UH Gmail), you can later seamlessly SSO to CAS sessions
- The IdP does not maintain 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:
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.
| Note | ||
|---|---|---|
| ||
CAS and web app sessions are 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. |