On Wed, Oct 17, 2012 at 3:35 PM, Andrew Morgan <[email protected]> wrote: > On Wed, 17 Oct 2012, Jason Whitener wrote: > >> We are in the early research stages of deploying cas at our college. >> In talking with another school, one of their headaches comes from >> dealing with multiple different timeout values across applications and >> cas. >> >> I'll try to summarize what the other school was telling me: >> >> Since the cas authentication has a timeout value, and the application >> has a timeout value, users become confused if, say, they started a >> session in one application, used up half the cas timeout value, went >> into another casified application, and then were timed out early >> because the cas session from the prior application ended. >> >> Is that a mis-configuration issue or a real issue that cas admins have >> to contemplate? If it is a real issue, what are some of the best >> practices around dealing with discrepant timeout values across >> multiple applications? >> >> thank you, >> >> Jason Whitener >> Portland Community College > > > I think you have a slight misunderstanding of how CAS operates (most people > do). CAS is only an authentication service. Each CASified application only > interacts with the CAS server once during a user's visit - at the beginning > when the identity of the user must be verified. After a successful > authentication, the application is responsible for it's own session > management and timeouts. > > In order to support Signle-Sign-On, the CAS server maintains it's own > session via a browser cookie named CASTGC (CAS Ticket-Granting-Cookie). The > CASTGC timeout is configurable. It determines how frequently a user must > re-authenticate when they attempt to use a new application. We set our > CASTGC timeout to 2 hours. > > In our experience, there is no notification sent to applications when the > CASTGC expires. However, I remember some discussions around SLO > (Single-Log-Out) by people who were interested in a CAS "Logout" triggering > a logout in all applications. I don't know the current state of this SLO > activity, but it's not happening by default.
Depends somewhat on your version...in 3.5 SLO callbacks are on by default, but the applications/clients aren't always prepared to handle them. Unicon almost always recommends deployers turn this off for enterprise deployments. see: https://wiki.jasig.org/display/CASUM/Single+Sign+Out http://jasig.275507.n4.nabble.com/the-misnamed-single-sign-off-or-if-you-prefer-single-log-off-SLO-td3713224.html Best, Bill Thompson Unicon > > If you'd like to chat on the phone about this, just give me a call. :) > > Andy Morgan > (541) 737-8877 > Oregon State University > > > -- > 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 -- 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
