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

Reply via email to