AuthenticationProcessingFilter and requestDispatcher throwing conneciton close erro

[harichandrasekhar]

Hi All,

I facing an issue implementing custom authenticationprocessingfiltering. Requesting help

Requirement : Customize a spring security application to bring under single sign-on. The single sign on soln will set users email address in the cookie as after successful login.
Environment : application deployed in Weblogic 10.3 secured using spring security

What is tried: Wrote a custom authenticationprocessingfilter extending the AbstractAuthenticationProcessingFilter and following methods were overridden
1. attemptAuthentication - to do the actual authentication by retrieving the email address using request.getUserPrincipal().getName and passing it to the authentication manager

2.requiresAuthentication - to check whether the requested URL requires authentication or not

3.successfulAuthentication - Redirect to the actual URL requested by client after successful authentication. Here where i have the issue. I wanted to redirect to the actual requested URL rather than defaultTargetURL. I was able to do that, but the actual method uses request.sendredirect rather than request dispatcher. because of this my request object which the client request is getting lost. Is there any specific reason why it is sendRedirect here rather than dispatcher. ??
Moreover i tried by changin it to requestDispatcher and i got the following error
java.net.SocketException: Connection reset by peer: socket write error

Evenif the error is thrown in the server, the application works without any issue. i read that there is nothing to worry abt this exception and we can ignore it, still for me to move it to production env there shouldnt be any warnings in the server. Any one can tell me why exactly with dispatcher this issue is????

[Rob Winch]

Just a random question...Have you thought about using one of the single sign on solutions that Spring Security already supports (i.e. OpenID, CAS)? I ask because looking in a cookie for the username is not secure means of authenticating since cookies are within control of the browser. This is because it is trivial for a hacker to set the cookie with any username they wish.

Regards,
Rob Winch

[harichandrasekhar]

Hi Rob,
Thanks for the reply.The single sign on soln we have is a standard implementation and security aspects are taken care. I didn't mention much abt the implementation details of the single sing-on. The issue is with redirecting to the url which client has actually request after authentication. Any hint to the issue would be much appreciated.

[Rob Winch]

Is there any specific reason why it is sendRedirect here rather than dispatcher.

The reason that you see a redirect is most of the time credentials are posted to the request and Spring Security follows the PRG pattern.

Any one can tell me why exactly with dispatcher this issue is????

It occurs when the browser kills the socket connection before the response is written out entirely. I have seen this error when there are connectivity problems between the browser and the server (often when firewalls or flaky wireless connections are involved). Have you tried pinging to see there is any oddities? If you remove Spring Security all together does the error still occur?

After re-reading your original post I noticed that your authentication mechanism was looking at the request object's principal. I assume that the user has already authenticated from something external to spring security? Are you wanting then to use Spring Security for authorization and the authentication is already done? If so, you may want to take a look at the Pre-Auth support since it appears the principal is already populated in the request object. This would allow for the code to easily continue with the filterchain rather than redirecting or forwarding.

HTH,
Rob Winch

[harichandrasekhar]

The reason that you see a redirect is most of the time credentials are posted to the request and Spring Security follows the PRG pattern.



It occurs when the browser kills the socket connection before the response is written out entirely. I have seen this error when there are connectivity problems between the browser and the server (often when firewalls or flaky wireless connections are involved). Have you tried pinging to see there is any oddities? If you remove Spring Security all together does the error still occur?

After re-reading your original post I noticed that your authentication mechanism was looking at the request object's principal. I assume that the user has already authenticated from something external to spring security? Are you wanting then to use Spring Security for authorization and the authentication is already done? If so, you may want to take a look at the Pre-Auth support since it appears the principal is already populated in the request object. This would allow for the code to easily continue with the filterchain rather than redirecting or forwarding.

HTH,
Rob Winch

"The reason that you see a redirect is most of the time credentials are posted to the request and Spring Security follows the PRG pattern."

But is this appropriate in a login process.One might loose all the request attributes here rite?.Is there any issue in over riding the SuccessfullAuthentication method and do a server side redirect rather than 302 redirect??.I was wondering why AuthenticationProcessFilter didnt do a doFilter after successfull authentication??? .
Unfortunately for me, im playin around with a third party app and the option to have preauthentication filter looks pretty tough, bcs of the way they ve implemented it.

[Rob Winch]

What is making it difficult to use the Pre-Auth?

I believe it is appropriate. When the user is logging in, the Spring Framework is takes control of handling the request (including creating and processing all request attributes). After it finishes, the framework sends the original request through to the developer at which point the developer can create and process their own request attributes. This flow prevents the developer from needing to handle the security related request. Additionally, it ensures the developer does not need to do anything different than if the user's flow was not even interrupted by a login.