SEC-1087: NTLM Filter and IE Post problems #1340

spring-issuemaster opened this Issue Jan 30, 2009 · 4 comments


None yet
1 participant

Bill Comer(Migrated from SEC-1087) said:

We are using NTLM Windows Authentication for a Single Sign On (SSO) project.

The Spring security Filter NtlmProcessingFilter for most of the time is absolutely fine.

However the are atleast two scenarios where this fails.

1) When the session is timed out and a form.submit() request is made.
Under this situation a windows logon box is presented. For a SSO application using NTLM this is not desirable.

2) If the page makes heavy use of dwr/javascript.
In this case the page makes repeated NTLM authentication requests and stack traces are observed with the message ‘This is not a Type 3 Message’.

There is a solution described in the jcifs documentation. Search for registry key. This solution works but is not suitable for many clients who would not give access to change registry settings on all their client PCs.

The fix described here applies to Spring-Security 2.0.4

Here is my suggested Spring solution to
As an addition the filter would be improved if the access on the utility methods were changed from private allowing the class to be extended more easily.

protected void doFilterHttp(final HttpServletRequest request,
final HttpServletResponse response, final FilterChain chain)
throws IOException, ServletException {
final HttpSession session = request.getSession();
Integer ntlmState = (Integer) session.getAttribute(STATE_ATTR);

final String authMessage = request.getHeader(“Authorization”);

// Check the special IE POST request with Authorization header containing
// type-1 message (see method javadoc)
if (this.reAuthOnIEPost(request)) {
if ((authMessage != null) && (authMessage.startsWith("NTLM “))) {
logger.debug(”POST Request with NTLM Authorization detected.“);
// decode the NTLM response from the client
byte[] src = Base64.decode(authMessage.substring(5));
// see if a type 1 message was sent by the client
if (src8 == 1) {
.debug(”NTLM Authorization header contains type-1 message. Sending fake response just to pass this stage…“);
Type1Message type1 = new Type1Message(src);
// respond with a type 2 message, where the challenge is null since we
// don’t
// care about the server response (type-3 message) since we’re already
// authenticated
// (This is just a by-pass – see method javadoc)
Type2Message type2 = new Type2Message(type1, new byte8, null);
String msg = Base64.encode(type2.toByteArray());
response.setHeader(”WWW-Authenticate", "NTLM " + msg);
} else {
….. existing filter code

chain.doFilter(request, response);

Fabrizio Giustina said:

a +1 for this patch. Just had the same problem on an application using ntlm authentication and I can confirm this fixed it.

Robrecht Anrijs said:

a -1 for this path: It is not completely fixed… Sometimes the following happens:

In our Test-environment everything goes fine, but in our production-environment: it fails.
In production, we have an apache server that distribute the requests to 2 other independent jboss-servers, somehow the response is sometimes corrupt.
It’s really hard to find why it happens, but I know that when I removed the suggested code, and use the standard NtmlProcessingFilter, the response is correct.

Danny Dion said:


I'm having the same problem using Spring Security with Google Web Toolkit.

I'm really a novice at this type of issue solving but I'd like to give the suggested patch a try, if someone can just help me a bit... I'm quite confused as to where the suggested code is supposed to be inserted. May I ask that you post the fixed method as a whole?

Thanks a lot,

Luke Taylor said:

NTLM will not be supported in the 3.0 codebase.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment