Scott, this sounds very much like my problem. I have upgraded both the client and th server to the latest versions last night, but I'll check again when I get home tonight.
Thanks, Martin Am 13.05.2009 um 04:58 schrieb Scott Battaglia: > Martin, > > Which version of CAS are you using? > > If you're not using 3.3.2 you may have fallen prey to this bug which > was fixed in 3.3.2: > http://www.ja-sig.org/issues/browse/CAS-772 > > Cheers, > Scott > > > On Tue, May 12, 2009 at 10:53 AM, Martin Simons <[email protected] > > wrote: > Hi Bruno, > > I'm in fact using scenario (1): Very "standard" configuration using > only the filters as described on the wiki (the config has been > posted to the mailing list before). The CAS server is out of the box > and only extended by the > SearchModeSearchDatabaseAuthenticationHandler and the required > libraries. I guess it can't be setup any simpler than that. The > client app purely relies on the credentials provided by CAS and > doesn't store the user's login-state itself. > > Thanks, > Martin > > > > > > Am 12.05.2009 um 22:37 schrieb Bruno Melloni: > >> 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] 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 >> >> >> -- >> >> >> >> 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 > > -- > 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
