Deep linking into CAS + acegi secured application

[des09]

My application needs to properly handle deep links when the user is logged into cas but not the application, but this is not working correctly. I can see where the AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL _KEY is being set in the session, but on the next request (after cas successfully authenticates,) the session value for that key is null in AbstractProcessingFilter.successfulAuthentication( ...)

Am I missing somethig?

[des09]

Seems the session ID is different for the initial request, and the request to j_acegi_cas_security_check, should these two requests be using the same session?

(btw, I checked that I am not switching domains between the requests )

[des09]

Did some more investigation, seems like vanilla cas filtering without Acegi will show the same behavior - ie, sessionid is not the same after logging into cas as it was on the first (unauthenticated) request to the application.

This is a pretty big gotcha. If the session is lost, I can't think of any other ways to preserve the as sending the initially requested url to CAS in the service parameter would require some significant mods to the ServiceProperties#getService() mechanism currently used.

(I also tried putting in a filter before any others that sets a session attribute, then forces a browser refresh by meta tag. I did this in the hopes that the first session was getting dropped beacuse the response was a redirect, but it didn't help.)

[Ben Alex]

I am not sure this is correct, as I've successfully authenticated to CAS and had the previous pre-authentication HttpSession preserved when I come back into the original application.

Are you using URL-based ;jsessionid perhaps, and thus there is no client-side session cookie to persist the session ID?

[des09]

I am not sure this is correct, as I've successfully authenticated to CAS and had the previous pre-authentication HttpSession preserved when I come back into the original application.

I agree, its a wierd phenom, and it should just work, but it doesn't... at least not in my app. I saw the session changing with Acegi, and also with the cas-client filter (no spring, no acegi.) I thought it might be because the browser sees a redirect instead of a 200, so it misses the cookie, but when I replaced the redirect with a meta tag refresh, same behavior.

] Are you using URL-based ;jsessionid perhaps, and thus there is no client-side session cookie to persist the session ID?

No I am just using vanilla sessions. I did consider using url rewrite ;jsessionid=whatever as a workaround, but realized I would need extensive code to pass the sessionid to all the way to the TicketValidator, as that needs to send a matching service url.

My current workaround is subclassed CASProcessingFilter and CASProcessingFilterEntryPoint to set and read a cookie with the initial URL, and populate session attribute ACEGI_SECURITY_TARGET_URL_KEY after calling ProcessingFilter.attemptAuthentication(request); Interesting that this works, as it implies no problems with setting cookies... If more info comes to light I'll update this post, for now, the ugly hack is working.

[sysnajar]

Hi all ,
I also encountered the same problem , it is only for IE7 though (Firefox2 and Google Chrome works fine) , at least for my machine.

I'm running CAS server 3.3 and Spring security 2.0.4 ...

Any suggestion ?

thanks,
Owat