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).
...
- 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 maintains 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:
- https://shibboleth.atlassian.net/wiki/spaces/IDP4IDP5/pages/12656316203199506072/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.
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. |
...