Regardless of how your TGT expires, when it does and whether it's manual
or automatic via the expiration policy, SLO will initiate. You no longer
have an SSO session, and you will be logged out every application you have
authenticated to via CAS. 

 

Starting with 4.1 I think, you will have the ability to turn off SLO on a
per application basis. If you have applications that tend to stay in use
longer than your SSO session, you can exclude those from SLO, and when the
user logs out, simply redirect that logout to the CAS logout and kill the
session entirely. 

 

Another possibility is, your CAS client could keep your session alive by
sending a heartbeat signal. This depends on your application and the
client, whether it provides that feature. Even with that capability,
assuming you use the default expiration policy the signal is only going to
extend your inactivity timeout. Once you pass the hard timeout on the
application side, you're back to the same issue. 

 

Most tend to turn off SLO entirely, for reasons that are SLO-specific and
less CAS-specific some of which you have run into. 

 

 

From: Lapanja, Bob@POST [mailto:[email protected]] 
Sent: Thursday, August 13, 2015 2:10 PM
To: [email protected]
Subject: [cas-user] single log out and login-webflow.xml

 

Using 4.0.0

 

I'm configuring single log out on some services and I have encountered a
situation I would appreciate some clarity on.  For this particular use
case, we want the logout callback to be called if the user visits
/cas/logout directly, but not when the TGT expires and is cleared out by
the registry cleaner (accomplished thanks to logUserOutOfServices).  Some
users may spend a long time working in a single application.  However,
after doing some testing, I came across a third situation I hadn't
considered.

 

The user signs into ServiceA and continues actively using it, keeping the
application session alive past the point where the TGT expires.  The user
then attempts to sign into ServiceB.  At this point, it seems that
login-webflow checks the TGT for validity, and if it is invalid calls
terminateSessionAction.terminate, which fires the logout callbacks and
logs the user out of ServiceA.  Since this seems to be the same function
called during logout-webflow, does that mean that this scenario must be
considered to be the same as if the user explicitly visited /cas/logout,
triggering the same logout callbacks?

 

Since some (many) of our users have no concept of the distinction between
the application session and the PASS session, the logout could be
unexpected and the aborting of their active work could be frustrating.  Am
I missing something relevant about how people manage SLO's and users that
may spend a lot of time in a single application at a time?

 

Thank you for any information.

 

-bob

 
-- 
You are currently subscribed to [email protected]
<mailto:[email protected]>  as: [email protected]
<mailto:[email protected]> 
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to