A 'slight idea' I have. I cannot speak for other people's experience nor for CAS versions other than 3.3.1. When I tried to use Single Sign Out, I remember 3 scenarios:
1) If using ONLY web.xml in the client app to configure CAS, I believe I managed to get it to work. 2) If I used Spring Security and configured things so that CAS forced the user to go to the client app home page every time after login - regardless of the URL the user typed - I believed I managed to get it to work. 3) If I used Spring Security and configured CAS to forward the user to the URL he typed before being redirected to the CAS login screen, I could not. I could either logout of CAS or logout of Spring Security, but not both. The CAS experts said that it should be possible to configure for this scenario and still do Single Sign Out, gave me a lot of hints, and seemed to believe very strongly that my problem wasn't a limitation in the integration between Spring Security and CAS. But nobody could show me how to fix my configuration to make it work. Since scenario (3) was what I needed (we allow bookmark use), I gave up on Single Sign Out. As a band-aid I only CAS-enabled apps that could stay signed in until the session in both CAS and the app expired. I also put a message in the login screen recommending that users *close the browser* completely when done. Not a perfect alternative but practical enough for my needs. If option (1) or (2) are acceptable to your environment, you should be able to find the info to make it work. Try searching threads from around February... I think that is when I got a lot of help on this from the CAS gurus. If you somehow figure out how to do (3)... PLEASE document it on the wiki and let people know in this email list. I'd love to enable Single Sign Out. I know it is not the best answer, but I hope it helps. bruno ________________________________ From: Martin Simons [mailto:[email protected]] Sent: Tuesday, May 12, 2009 2:54 PM To: [email protected] Subject: Re: [cas-user] Single Sign OFF Questions 3rd day in a row trying to tackle my logout issue. I've further delved into what actually arrives at my client app and figured that the logout-request from CAS arrives as a GET request and doesn't contain the parameters the Logout-Filter requires (judging from the client's source). I have also upgraded to the latest version of the Java client (3.1.5) which didn't make difference though (besides some nasty warn-exceptions on startup). Is there really nobody out there having a slight idea what the problem could be? Any help would really be appreciated! Regards, Martin Am 11.05.2009 um 23:01 schrieb Martin Simons: Another bit of information: On the CAS server side I see log-entries when logging in, but there is no activity in the log whatsoever when logging out? This is really confusing. Any ideas? Am 11.05.2009 um 21:35 schrieb Martin Simons: M, the logout-problem is still riddling me. I've followed your advice and tried to set up all filters with the same scope. Didn't work either though, just leading to an infinite redirect loop. Maybe I should post my general application setup after I provided you with my filter mappings already: The app is a wicket app mounted under "/app". There are freely accessible pages and restricted pages, the latter mapped to /app/account/* and /app/credits/* according to the mappings. If accessing the application via the root (meaning /, not /app), a JSP redirects to the app-folder which again will let Wicket redirect to the configured main page (namely /app/account/index). If firing a logout within CAS, I get the following log-entry: 2009-05-11 21:33:52,587 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] - <no ticket and no assertion found> 2009-05-11 21:33:52,587 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] - <redirecting to "https://auriga:8443/cas/login?service=http%3A%2F%2Fauriga%3A8080%2Faquila%3Bjsessionid%3D37D52120FCD6D42934A5620BBCF76CB3";> That's all. No log-entry tells me anything about the logout itself, just about some request coming in that obviously isn't handled the way it should be. Any idea anybody? Regards, Martin Am 08.05.2009 um 14:14 schrieb Marvin Addison: You have the SSOutFilter listed first, which is correct. The only other thing I would note is that the scope of your CAS filters is not consistent. Typically all CAS filters have the same scope, e.g. url-pattern is same across all since the CAS filters work together to support the CAS protocol. You might try setting them up with the same scope and see whether that helps. M -- 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]<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]<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 -- 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
