Leaving SecurityFilterChain with redirect problematic?

[Stephan Mueller]

Hello,

I'm using Spring 2.x and utilize a Spring SecurityFilterChain for authentication.

The chain is defined as follows:
1) spring...CommonsRequestLoggingFilter
- add custom stuff to log messages

2) spring...HttpSessionContextIntegrationFilter
- handling of the SecurityContextHolder

3) custom filter for logouput about authentication state

4) spring...ExceptionTranslationFilter
- handle spring...AuthenticationExceptions, thrown during the following authentication process

5) jespa...SecurityService
- Jespa's (ioplex.com) library for NTLM authentication

6) custom filter to obtain UserDetails from LDAP based on the successful authentication from filter 5


Now, if NTLM authentication fails, the jespa library throws a jespa.SecurityProviderException. This means, that the ExceptionTranslationFilter will not recognize this authentication. The jespa library defines, that when the NTLM authentication fails, it redirects the request to a fallback location (i.e. error page).
This in turn means, that if the NTLM authentication fails, I'll leave the FilterChain with traversing it completely. (additionally, the API contract of the Jespa library does not allow to throw something else then a SecurityProviderException. I've checked with their support. They need this to do internal cleanups if the authentication fails)

My question is: Is this problematic? Does the filterchain always have to be traversed completely? I fear that the chain may be in an inconsistent state and I get unexpected side-effects if the the filter 5 just jumps out of the chain with a redirect. I couldn't find the answer in the docs until now. Could you please clarify this? I'll happily provide additional information if needed.

Regards,
srm

[Stephan Mueller]

Uhm, okay, I've found this in the Filter API
"A typical implementation of this method would follow the following pattern:-
1. Examine the request
2. Optionally wrap the request object with a custom implementation to filter content or headers for input filtering
3. Optionally wrap the response object with a custom implementation to filter content or headers for output filtering
4. a) Either invoke the next entity in the chain using the FilterChain object (chain.doFilter()),
4. b) or not pass on the request/response pair to the next entity in the filter chain to block the request processing
5. Directly set headers on the response after invocation of the next entity in the filter chain.
"

4b) looks the answer to my question but I still want to verify this with you