Я пытаюсь реализовать HTTP-прокси на Java, который добавляет встроенную проверку подлинности Windows ко всем запросам.
Я имею в виду, по сути, согласование правильной схемы аутентификации между прокси (в домене) и сервером, что, насколько я понимаю, должно привести к созданию какого-то токена, который можно просто добавить к запросам в заголовке авторизации. .
Дело в том, что мы пытаемся использовать Selenium Grid с агентами за пределами домена. Поэтому согласование аутентификации непосредственно в браузере не работает.
У нас уже есть BrowserMobProxy для обработки базовой аутентификации, однако нам также нужен WIA.
Есть ли у кого-нибудь идеи, как я могу сгенерировать этот необходимый токен? Или, может быть, я ошибаюсь, и этот подход по какой-то причине вообще не работает?
Любая помощь будет оценена по достоинству!
Прокси может быть частью домена. Я обновил свой пост, чтобы отразить это.
Обычно вы присоединяете компьютер к домену, а не к прокси. Таким образом, сервер, на котором работает прокси, должен быть частью домена. В Windows он будет использовать некоторый DPAPI. Это связано с шифрованием для входа в систему и/или входа в систему. Единственный способ обойти это - иметь отмычки/брелок для ключей. (а плагин в браузере?) Браузер также должен быть на машине, которая является членом домена. Вам нужно вручную создать профиль, перейти на сайт, защищенный аутентификацией Windows, и при необходимости ввести учетные данные. Закройте браузер и используйте тот же профиль для сеанса веб-драйвера.
@browsermator: Это полубрехня. Аутентификация не является шифрованием (даже если она основана на шифровании под капотом), и не требуется никакого «главного ключа для домена» — клиенту нужно знать только свой собственный ключ Kerberos (который он напрямую извлекает из его пароль), все остальное обрабатывается протоколом. В большинстве случаев для клиента даже не требуется членство в домене (требование FAST-бронирования является скорее исключением, чем правилом).
Вероятно, вы правы... Я просто представляю, как можно перенести хеш с компьютера с Windows, где он защищен DPAPI и доменом. Излишне говорить, что DPAPI сложно обойти: Learn.microsoft.com/en-us/previous-versions/…
@browsermator: Очень легко обойти DPAPI, если DPAPI вообще не используется. Аутентификация Kerberos никоим образом не использует DPAPI. Более того, вам не нужно извлекать или передавать какой-либо хэш из Windows — ключ создается самим паролем пользователя (т. е. здесь нет ничего вроде «пароль расшифровывает ключ», поэтому нет необходимости в DPAPI), поэтому если вы знаете пароль, вы можете использовать любое клиентское программное обеспечение Kerberos для связи с KDC и получения билетов.
если все, что вам нужно, это имя пользователя и пароль, вы сможете вручную создать новый профиль, вручную войти в него... закрыть браузер. Затем настройте Selenium на использование этого профиля при запуске драйвера. Если это не сработает, вам придется использовать роботоподобную платформу для ввода имени пользователя и пароля вручную. (Раньше был способ поместить имя пользователя/пароль в URL-адрес, но я не думаю, что он больше работает.) См. эту тему: stackoverflow.com/questions/10395462/…
Вы также можете проверить новый протокол Bidi на наличие onAuthRequired: selenium.dev/documentation/webdriver/bidirection/…




Я бы проигнорировал NTLM, если это возможно; все пытаются избавиться от этого, а не иметь его больше.
Судя по всему, Java имеет встроенную поддержку Kerberos как часть JAAS, которая может либо использовать свою внутреннюю реализацию (для которой необходимо предоставить учетные данные, например, в виде таблицы ключей), либо интегрироваться с собственным SSPI Windows (который может автоматически использовать AD службы). реквизиты для входа). Теоретически, пока используется SSPI, он может работать с Kerberos и NTLM. Есть еще одна реализация, Apache Kerby, но она кажется гораздо более простой.
Обратите внимание, что HTTP Negotiate использует SPNEGO — это два уровня оболочки вокруг фактического необработанного токена Kerberos (AP-REQ), просто чтобы избежать путаницы при чтении документации и попытке отправить неправильный тип «токена Kerberos». Стандартным интерфейсом Kerberos является GSS API (который создает свои собственные токены, которые по сути просто содержат в себе токен Kerberos), и Java может делать это изначально, но многие протоколы Windows используют SPNEGO, который является еще одним промежуточным уровнем (тот, который мультиплексирует Kerberos и NTLM), и большинству веб-серверов специально требуются токены GSS<SPNEGO<Kerberos>> вместо простых токенов GSS<Kerberos>.
Я не имел дела с Java в такой степени, но kerb4j выглядит как то, что вам нужно, чтобы обрабатывать все от вашего имени (получение билетов Kerberos через Apache Kerby, генерация токенов GSS-SPNEGO и т. д.).
Спасибо за очень подробный ответ. kerb4j кажется именно тем, что мне нужно.
не уверен, что вы сможете сделать это за пределами домена... но это «переговорный» вызов: ietf.org/rfc/rfc4559.txt Он обрабатывается браузером и будет выполнен только в том случае, если сайт находится в «локальной интрасети» и/или «доверенной» зоне. Вам может понадобиться главный ключ для домена и/или доступ к связке ключей для создания этих сертификатов/токенов. Было бы крайне небезопасно передавать такие закрытые ключи.