Тестирование веб-сервиса с SoapUI и аутентификацией Windows - PullRequest
45 голосов
/ 27 мая 2009

Можно ли включить учетные данные домена Windows для тестирования моей веб-службы с SOAP UI?

Я нашел страницу свойств, но IIS просто отвечает «неправильными учетными данными».

Ответы [ 5 ]

58 голосов
/ 18 сентября 2009

SoapUI, похоже, не работает напрямую с аутентификацией NTLM, но вы можете использовать прокси-сервер, такой как Burp Suite, для аутентификации за вас.

  1. Загрузите Burp Suite с http://portswigger.net/burp/ и проверните его.
  2. На вкладке «Прокси: перехват» в Burp нажмите кнопку, чтобы отключить перехват.
  3. На вкладке «Прокси-сервер» в Burp убедитесь, что для нее задан неиспользуемый порт, по умолчанию установлено значение 8081
  4. На вкладке «Настройки» Burp поставьте галочку «сделать аутентификацию www» и добавьте настройку сервера, на который вы хотите попасть. Также отметьте «запросить учетные данные при сбое аутентификации»
  5. Переключитесь на вкладку "Прокси: история" Burp, чтобы вы могли видеть запросы, проходящие.
  6. В SoapUI выберите «Файл»> «Настройки», затем выберите «Настройки прокси». Введите хост "localhost" и порт "8081".
  7. Используйте SoapUI как обычно. Он будет отправлять запросы через Burp Proxy, который выполнит NTLM-аутентификацию за вас.
12 голосов
/ 07 марта 2012

soapUI 4.5 только что добавил поддержку NTLMv2, что сводит на нет необходимость в Burp Suite.

6 голосов
/ 18 июня 2014

Принятое решение будет работать в большинстве сценариев. Однако, если служба использует делегирование для доступа к ресурсам на других серверах, вы столкнетесь с проблемой двойного перехода с проверкой подлинности NTLM, которую использует прокси Burp. Прокси-сервер успешно аутентифицируется в службе, но последующие вызовы, сделанные службой другим ресурсам с использованием делегирования, завершатся неудачно.

Проблема хорошо описана в этой статье:

http://blogs.msdn.com/b/besidethepoint/archive/2010/05/09/double-hop-authentication-why-ntlm-fails-and-kerberos-works.aspx

Самый простой обходной путь, который я нашел для этого, заключался в использовании Fiddler в качестве прокси. В меню «Правила Fiddler» выберите «Автоматическая аутентификация». Затем обновите настройки SoapUI, чтобы использовать fiddler в качестве прокси-сервера (по умолчанию это localhost: 8888). Теперь ваши звонки будут упакованы в учетные данные, которые можно делегировать.

Если вы используете LoadUI для выполнения тестовых случаев SoapUI, средство запуска SoapUI будет использовать настройки прокси-сервера SoapUI, и ваши вызовы будут продолжать работать.

1 голос
/ 02 апреля 2013

Текущая версия SoapUI 4.5.1 не работает с аутентификацией Windows, но ночная сборка снова работает хорошо.

Загрузить версию для ночной сборки

1 голос
/ 27 мая 2009

Я думаю, что SoapUI может поддерживать только аутентификацию NT для WSDL.

Вы можете увидеть некоторые детали того, как это реализовано здесь:

(Кстати, этот поиск в Google не выглядит многообещающим для вас !)

...