The problematic scenario is: 1) User does Single Sign On and starts working with service A. 1) Ticket expires but session continues in service A since logUserOutOfServices is false. 2) User then connects to another service, service B which forces them to login again and create a new ticket. 3) User then performs Single Sign Out which logs them off service B however it does not log them off service A.
I realize that this problem is quite "normal". By setting logUserOutOfServices to false i am allowing the user to remain authenticated in service A without being authenticated by CAS. I really do want to log my user out of service A when the ticket expires it's just that i would like to be able to prolong the expiry of the ticket according the the users activity. The same way a web session does. Perhaps the best solution to my problem would just be to increase the default ticket expiry from 2 hours to something greater, but i understand that i would be reducing security and increasing load on the server. On Thu, Apr 26, 2012 at 1:02 PM, Scott Battaglia <[email protected]>wrote: > The configuration change you made should do exactly what you want. What > problems are you seeing with that? > On Apr 26, 2012 6:17 AM, "Max Pimm" <[email protected]> wrote: > >> I'm new to CAS so i may be missing something quite obvious.... >> >> I have the default ticket expiration policy that causes tickets to expire >> after 2 hours. >> >> When the ticket expires this automatically triggers a Single Sign Out in >> my webapp. (The default behaviour of the ticket registry i believe) >> >> This is a problem when a user is active in the webapp since after 2 hours >> they are forced to login again (even if the webapp session has not expired). >> >> How should i configure CAS to avoid this problem. >> >> I have tried disactivating the single sign out in the ticketRegistry.xml >> (p:logUserOutOfServices="false" ) however this also prevents my user being >> logged out of the webapp when they do a single sign out (cas/logout) which >> i don't want. >> >> I imagine that this is quite a common scenario. What am i missing? >> >> Max >> >> >> >> >> -- >> 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 > > -- 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
