Just as a quick info, as I didn't have much time to try it today: Installed a seperate instance of Tomcat (5.5), both client and server are up to the latest version. The same problem persists.
Am 13.05.2009 um 07:59 schrieb Martin Simons: > 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 -- 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
