Announcement Announcement Module
Collapse
No announcement yet.
spring-security-kerberos SPNEGO + FORM is not working with IE Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • spring-security-kerberos SPNEGO + FORM is not working with IE

    Hello, we are finishing new application with combined authentication SPNEGO + FORM. Our configuration is pretty much the same as in the spring-security-kerberos-sample application. However this configuration is a bit problematic (i.e. it does not work ) with our beloved Internet Explorer.

    Internet Explorer (tested with IE9 / W2008R2) is trying to reauthenticate with every POST. This was solved by the old NtlmProcessingFilter#reAuthOnIEPost in now deprecated spring-security-ntlm. With SpnegoAuthenticationProcessingFilter it might be solved by skipIfAlreadyAuthenticated, however that alone does not solve anything. It must be acompanied by correct AuthenticationSuccessHandler, which will recognize POST and just returns 200 so that IE resends the POST data.

    With combined SPNEGO + FORM this gets even more complicated. If the user authenticates via SPNEGO and then changes authentication using login page, still IE will try to reauthenticate with SPNEGO with each POST. If you want to use SpnegoAuthenticationProcessingFilter#skipIfAlready Authenticated, that will replace FORM authentication with the SPNEGO one. So in this case it makes SpnegoAuthenticationProcessingFilter completely useless.

    Is there some flaw in my analysis or do I really need to write my own SpnegoAuthenticationProcessingFilter to solve this?

  • #2
    We were able to disable Internet Explorer's pre-authentication via DisableNTLMPreAuth in registry (see http://support.microsoft.com/kb/251404). We probably won't be able to convince customer to set this in his domain. It just sort of just verifies that even SPNEGO/Kerberos authentication is affected by this configuration. And that is why I am a little bit confused - there is no source at kb.microsoft.com, which suggests that Kerberos should behave in this way...

    Comment


    • #3
      I am even more confused - the Authorization header contains suspicious part "NTLMSSP". So the browser is probably sending NTLM authentication instead of SPNEGO. It does not make much sense to me. Will try investigate further...

      Comment


      • #4
        Oh no, I've fallen into a trap I knew about... Kerberos does not work correctly if the server and the client are on the same machine. I think I can end this "monologue discussion" .

        Comment


        • #5
          So... we have finally solved our issue. The problem was in NTLM PRE-AUTH (sending empty POSTs with NTLMSSO token) and the root cause was not the fact we were connecting to the server from the same machine, but that IE thought that its NTLM authentication was successful.

          The exact conditions when Internet Explorer is falling back to NTLM are a bit complex. However the root of our problem was, that for the initial NTLM token (sent instead of Kerberos) we were returning response code 302 with redirect to a login page (using SimpleUrlAuthenticationFailureHandler). My belief is that IE understood this as a success for the NTLM authentication and from that moment the NTLM PRE-AUTH mechanism kicks in.

          What we have done is we switched SimpleUrlAuthenticationFailureHandler to use FORWARD instead of redirect and in the LoginController:

          Code:
          @Controller
          @RequestMapping("/login")
          public class LoginController {
          
              @RequestMapping
              public String renderLogin(HttpServletRequest request, HttpServletResponse response) {
                  if (request.getAttribute(WebAttributes.AUTHENTICATION_EXCEPTION) != null) {
                      // Important for IE so that NTLM will be handled as unsuccessful
                      response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
                      // See http://tools.ietf.org/html/draft-sha...hentication-01
                      response.addHeader("WWW-Authenticate", "Form");
                  }
                  request.setAttribute("loginPage", true);
                  return "login.login";
              }
          
          }

          Comment

          Working...
          X