PingAccess проблемы с проксированием целевых сайтов с помощью смеси HTTP/HTTPS

Я пытаюсь настроить PingAccess в качестве прокси (давайте назовем хост PA pagateway) для нескольких приложений, которые совместно используют веб-сессию. Я хочу, чтобы весь доступ осуществлялся через pagateway PA и использовал HTTPS, но внутренние системы не HTTPS.

У меня есть два сайта, app1:8080 а также app2:8080, Для обоих параметров установлено значение "secure" = no и "use header host host" = yes.

У меня есть прослушиватели, определенные на портах 5000 и 5001, которые оба установлены в "безопасный" = да.

Первая проблема, которую я обнаружил, заключается в том, что когда я получаю доступ к любому приложению таким образом (например, собираюсь https://pagateway:5000), после успешной аутентификации с помощью PingFederate, я получаю перенаправление на фактическое имя основного хоста (например, http://app1:8080), то есть любые последующие взаимодействия с приложением не осуществляются через PingAccess. Для пользователей вне сети они даже не смогут сделать это, потому что app1 хост даже не будет виден или доступен.

Я подумал, что, возможно, мне нужно было отключить "Использовать заголовок целевого хоста" для "ложь", но Chrome предлагает мне загрузить файл, содержащий коды NAK, ETX, ETX, NUL, STX, STX, и в журналах PA я получаю ошибку SSL:

2015-11-20 11:13:33,718 DEBUG [6a5KYac2dnnY0ZpIl-3GNA] com.pingidentity.pa.core.transport.http.HttpServerHandler:180 - IOException reading sourceSocket
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
    at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
    ...

Я не уверен точно, из какой части процесса происходит ошибка SSL (между браузером и pagateway, или же pagateway а также app1). Я думаю, может быть app1 возникают проблемы с неожиданным заголовком узла...

В другом варианте я отключил SSL на прослушивателе PA (мне также пришлось изменить URL-адрес обратного вызова PingAccess в настройках клиента PingFederate на http). Но когда я получил к нему доступ через http://pagateway:5000 Я получил общее сообщение об ошибке PingFederate в браузере и другую ошибку в журналах PA:

2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:148 - Invoking request handler: Scheme Validation for Request to [pagateway:5000] [/]
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:200 - Exception caught.  Invoking abort handlers
com.pingidentity.pa.sdk.policy.AccessException: Invalid request protocol.
    at com.pingidentity.pa.core.interceptor.SchemeValidationInterceptor.handleRequest(SchemeValidationInterceptor.java:61)

Кто-нибудь знает, что я делаю не так? Честно говоря, я немного удивлен перенаправлением на фактическое имя сервера, но после этого я озадачен тем, куда идти дальше.

Любая помощь будет оценена.

Источник

2 ответа

Решение

Обращались ли вы в нашу поддержку по этому поводу? Это звучит как что-то, что нужно будет углубить немного глубже, но я могу высказать несколько рекомендаций высокого уровня:

Взгляните на трассировку браузера, чтобы определить, когда происходит перенаправление на серверный сайт. Обычно это происходит из-за того, что заголовок Location в редиректе с бэкэнд-веб-сервера (по своей природе) является абсолютным URL-адресом, но указывает на него, а не на внешнее имя хоста.

Распространенным решением для этого является установка значения Target Host Header в False, чтобы он получал запрос неизмененным из браузера, и внутренний сервер должен знать, что он будет таким (если он хорошо работает за прокси-сервером).

Если бэкэнд-сервер не может этого сделать (что звучит так, как будто он не может) - вы должны посмотреть, как назначить правила перезаписи для этого приложения. Более подробная информация о них доступна здесь: https://documentation.pingidentity.com/pingaccess/pa32/index.shtml. В частности, "Правило перезаписи заголовка ответа" будет перезаписывать заголовки расположения в перенаправлениях HTTP.

К вашему сведению - "Неверный протокол запроса". ошибка, которую вы видите внизу вашего описания, может быть вызвана флагом "Требовать HTTPS" в вашем определенном приложении.

Источник

Есть ли у вас такая же проблема, если вы добавляете косую черту в конце ( https://pagateway:5000/webapp/)? Ваш сервер приложений перезапишет URL, основываясь на том, что он считает истинным хостом. Это сделано для того, чтобы обойти некоторые проблемы безопасности, связанные со списком каталогов.

Какой сервер приложений вы используете? Все серверы приложений уникальны, но я предоставлю инструкции, как решить эту проблему с помощью Tomcat.

  1. Добавьте глобальное правило, которое заставляет сервер приложений использовать имя внешнего внешнего хоста. Вот пример Groovy-скрипта:

def header = exc?.request?.header;

заголовок.setHost("pf.pingdemo.com:443");

что-нибудь();

  1. В файле Tomcat server.xml добавьте схему ="https" к соединению:
<Connector port="8080" protocol="HTTP/1.1"

           connectionTimeout="20000"

           redirectPort="443" scheme="https" />

Ура, там

Источник
Другие вопросы по тегам