IIS прокси для Apache с прохождением проверки подлинности домена - PullRequest
2 голосов
/ 27 июня 2011

наш клиент имеет интранет, работающий в Linux (Apache, PHP).Авторизация обеспечивается диалогом входа в систему, сеансом в PHP.

Клиенту необходимо не запрашивать пароль у компьютера с ОС Windows, вошедшего в свой домен, а использовать имя пользователя / пароль вошедшего в систему пользователя.

Совместная работас apache ldpap выходит за рамки, из-за соображений безопасности.

Решение состоит в том, чтобы использовать ISS на выделенном компьютере в качестве прозрачного прокси-сервера с перезаписью на сервер Apache Linux, работающий в интрасети, но с прокси-сервером, передающим информацию аутентификации (логин, пароль)к серверу apache.

Возможно ли реализовать это решение?Если это так, пожалуйста, дайте мне совет.

Заранее спасибо

1 Ответ

2 голосов
/ 27 июня 2011

Я предполагаю, что причина, по которой Apache с LDAP находится вне области видимости, заключается в том, что имя пользователя / пароль обрабатывается приложением PHP. Это предположение некоторые из использования диалога входа в систему.

Исходя из этого предположения, у прокси-решения, которое пересылает пароли, есть некоторые проблемы, связанные с аутентификацией между двумя доменами. Скорее всего, было бы невозможно синхронизировать пароли между двумя доменами. У вас будут проблемы, когда новым пользователям придется ждать, пока произойдет синхронизация, прежде чем они смогут получить доступ к приложению. Смена пароля также может вызвать проблемы с входом в систему до выполнения синхронизации. У вас также есть проблемы с получением действительного пароля ....

Способ проверки подлинности домена заключается в том, что Internet Explorer специально пытается выполнить проверку подлинности на удаленном сайте, если первоначальный запрос вызывает проблемы. Это может быть NTLM, обычная аутентификация или что-то еще; Дело в том, что обмен учетными данными обрабатывается с помощью заголовков HTTP и запроса / ответа веб-сервером. К тому времени, когда веб-приложение выполняется в IIS, веб-сервер выполняет проверку LDAP, и приложение знает только имя пользователя, но не пароль. (В тех случаях, когда используется NTLM, пароль фактически никогда не обменивается при квитировании вызова / ответа. Клиентская сторона демонстрирует, что знает правильный пароль через вызов / ответ.)

Вероятно, единственный способ сделать это - заставить приложение IIS проверить пользователя через LDAP, а затем найти учетные данные этого пользователя в приложении PHP. Как вы сопоставляете пользователя домена Windows с пользователем в приложении PHP, вероятно, через домен \ имя пользователя. Вместо проксирования приложение может зашифровать имя пользователя / пароль и передать зашифрованную полезную нагрузку в качестве параметра запроса приложению с помощью перенаправления. Пользователь входит в систему, ответ перенаправляет их в приложение PHP через URL-адрес, к которому в качестве параметра добавлена ​​зашифрованная полезная нагрузка.

Шифрование может быть выполнено с помощью общего секрета между приложением .Net и приложением PHP. Лучшим решением было бы зашифровать его открытым ключом SSL-сертификата приложения PHP. Таким образом, ключ периодически меняется, и вам не нужно обновлять общий секрет с обеих сторон.

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

...