CAS - AJAX request is not able to manage redirecting to CAS

[harasta]

Hello,

I'm using Spring Security 3.0.5 in combination with JSF 2.0 frontend (ICEFaces) and CAS authentication.

When a service ticket expires (user accomplishes SSOut from another window in the meantime), the first XmlHttpRequest from "still running" application forces new authentication. Spring Security filter tries to redirect the browser to the CAS in XML response. XML parser then reports parsing error and the result is HTTP error 302 - moved temporarily. The application stays irresponsive.

What should I do? I want my application to redirect the user to the CAS login page after that.
Thanks for any idea,

Vladimir

[Rob Winch]

I'm not sure I follow, so please expand upon your description if I am not. It appears that your AJAX request is not properly able to perform SSO. You will need to modify the CasAuthenticationEntryPoint to flex if the request is AJAX to be something else. Your JS code then needs to handle the custom response.

[harasta]

I'm not sure I follow, so please expand upon your description if I am not. It appears that your AJAX request is not properly able to perform SSO. You will need to modify the CasAuthenticationEntryPoint to flex if the request is AJAX to be something else. Your JS code then needs to handle the custom response.

Hm, you are actually right. ICEFaces and Spring Security are 3rd-party products that don't understand each other. It seems to be a general problem. I'm afraid I'm not experienced enough to flex the AJAX component and CasAuthenticationEntryPoint source codes. Maybe my collegues will manage it.

Thank you very much
Vladimir

[harasta]

Lately I read blog Spring Security 3 and ICEfaces 2 where Ben Simpson introduced JsfRedirectStrategy (see source attachment there). I realized that there are at least 2 situations in CAS environment when the session could expire: due to timeout and due to expiration of service ticket. Both situations should take care of AJAX request as well.

Unfortunatelly, the CasAuthenticationEntryPoint has currently really bad design because its commence() method is final. preCommence() method is not sufficient enough in this situation, it serves to only response headers change. I'd like to suggest rearrangement of that in the next versions of Spring Security:

public class CasAuthenticationEntryPoint implements AuthenticationEntryPoint, InitializingBean {

	private RedirectStrategy redirectStrategy = new JsfAwareRedirectStrategy();
...
	/**
	 * @see org.springframework.security.web.AuthenticationEntryPoint#commence(javax.servlet.http.HttpServletRequest,
	 *      javax.servlet.http.HttpServletResponse, org.springframework.security.core.AuthenticationException)
	 */
	public void commence(final HttpServletRequest servletRequest, final HttpServletResponse response, final AuthenticationException authenticationException) throws IOException, ServletException {

		final String urlEncodedService = createServiceUrl(servletRequest, response);
		final String redirectUrl = createRedirectUrl(urlEncodedService);

		preCommence(servletRequest, response);

		if (this.redirectStrategy == null) {
			response.sendRedirect(redirectUrl);
		} else {
			redirectStrategy.sendRedirect(servletRequest, response, redirectUrl);
		}
	}

	public void setRedirectStrategy(RedirectStrategy redirectStrategy) {
		this.redirectStrategy = redirectStrategy;
	}
...
}

I hope the redirect strategy is honest enough solution

Disclaimer: take it as is. AJAX is no standard. I believe that Ben's redirect strategy is suitable for all JSF 2 frameworks. If you use JSF 1.2 or even some javascript AJAXified framework, request and response headers will change. Changing the redirect strategy should help.

[jjarokerso]

We have the same redirection issue when using CAS and Spring Security. The issue occurs for ajax calls across different domains after a ticket timeout or logout event. I believe this is the same problem that Vladimir describes: redirection to CAS login page fails because it is on a different domain, server or port.

Would any Spring Security experts have ideas on how to best resolve this issue? We are evaluating a few solutions, such as

- Modifying the CAS filter so that an error message is delivered to the client and making the client responsible for logout/timeout event handling

- Eliminating CAS from ajax calls entirely by using a cookie approach and creating backend logic to associate a cookie with a user session and periodically check if the session is still active

Any suggestions would be greatly appreciated.

Jon Jaroker

[harasta]

Jon,

see my comments below:

I believe this is the same problem that Vladimir describes: redirection to CAS login page fails because it is on a different domain, server or port.

I don't think so. It is CAS principle to be placed elsewhere staying centrally accessible. Maybe, the browser can complain if the server redirects user to the different domain. It depends on the browser security settings. But this is not my case, my servers run in the same domain. The AJAX aware RedirectStrategy is sufficient enough in both cases.

We are evaluating a few solutions, such as

- Modifying the CAS filter so that an error message is delivered to the client and making the client responsible for logout/timeout event handling

I'm not any Spring Security expert, but I feel that to customize CAS authentication filter is very low level solution dealing with CAS communication protocols. This is very risky approach. Instead of that, I'm convinced there are several other places where AJAX aware RedirectStrategy should be used:
1. authenticationFailureHandler - if CAS fails to manage user's credentials
2. casAuthenticationEntryPoint - when service ticket expires
3. sessionManagementFilter - if you want to control session expiration
etc.

- Eliminating CAS from ajax calls entirely by using a cookie approach and creating backend logic to associate a cookie with a user session and periodically check if the session is still active

This sounds like requirement for some form of session management. Eliminating CAS from ajax calls entirely is mostly problematic due to mixed security requirements. You probably will end up with complex logic placed in the security filter which isn't responsible for that.

Maybe my comments will help you.
Vladimir