HttpClient 4.1.1 возвращает 401 при аутентификации с NTLM, браузеры работают нормально

Я не эксперт по этому вопросу, но во время аутентификации NTLM с использованием http-компонентов я видел, что клиенту нужно 3 попытки для подключения к конечной точке NTML в моем случае. Это своего рода описано здесь для Spnego, но это немного отличается для аутентификации NTLM.

для NTLM с первой попытки клиент сделает запрос с Target auth state: UNCHALLENGED и веб-сервер возвращает статус HTTP 401 и заголовок:WWW-Authenticate: NTLM

клиент проверит для настроенных схем проверки подлинности NTLM должен быть настроен в клиентском коде.

вторая попытка, клиент сделает запрос с Target auth state: CHALLENGED, и отправит заголовок авторизации с токеном, закодированным в формате base64:Authorization: NTLM TlRMTVNTUAABAAAAAYIIogAAAAAoAAAAAAAAACgAAAAFASgKAAAADw== Сервер снова возвращает статус HTTP 401, но заголовок:WWW-Authenticate: NTLM теперь заполняется закодированной информации.

3-я попытка клиент будет использовать информацию из WWW-Authenticate: NTLM заголовок и сделает окончательный запрос с Target auth state: HANDSHAKE и заголовок авторизации Authorization: NTLM который содержит больше информации для сервера.

в моем случае я получаю HTTP/1.1 200 OK после этого.

чтобы избежать всего этого в каждом запросе документация в главе 4.7.1 говорится, что один и тот же токен выполнения должен использоваться для логически связанных запросов. Для меня это не сработало.

мой код: Я инициализирую клиента один раз в @PostConstruct метод EJB

        PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
        cm.setMaxTotal(18);
        cm.setDefaultMaxPerRoute(6);

        RequestConfig requestConfig = RequestConfig.custom()
        .setSocketTimeout(30000)
        .setConnectTimeout(30000)
        .setTargetPreferredAuthSchemes(Arrays.asList(AuthSchemes.NTLM))
        .setProxyPreferredAuthSchemes(Arrays.asList(AuthSchemes.BASIC))
        .build();

        CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
        credentialsProvider.setCredentials(AuthScope.ANY,
                new NTCredentials(userName, password, hostName, domainName));

        // Finally we instantiate the client. Client is a thread safe object and can be used by several threads at the same time. 
        // Client can be used for several request. The life span of the client must be equal to the life span of this EJB.
         this.httpclient = HttpClients.custom()
        .setConnectionManager(cm)
        .setDefaultCredentialsProvider(credentialsProvider)
        .setDefaultRequestConfig(requestConfig)
        .build();

используйте то же самое экземпляр клиента в каждом запросе:

            HttpPost httppost = new HttpPost(endPoint.trim());            
            // HttpClientContext is not thread safe, one per request must be created.
            HttpClientContext context = HttpClientContext.create();    
            response = this.httpclient.execute(httppost, context);

освободить ресурсы и вернуть соединение обратно в диспетчер соединений, в методе @PreDestroy моего EJB:

             this.httpclient.close();