Как я могу убедиться, что Liferay использует TLS для аутентификации
Обратите внимание, что речь идет об обмене данными между Liferay и сервером LDAP, а не об обмене данными между браузером пользователя и Liferay.
Я спрашиваю об этом здесь, поскольку за 30 минут на форумах liferay я получил нулевое количество просмотров (кроме моего), и я хотел бы решить это сегодня, если это возможно...
Я посмотрел на:
http://www.liferay.com/community/wiki/-/wiki/Main/LDAP
http://www.liferay.com/community/wiki/-/wiki/Main/LDAP+integration
Я также прочитал это:
http://www.liferay.com/documentation/liferay-portal/6.1/user-guide/-/ai/ldap
И я провел много поисков и обнаружил, что многие люди настраивают CAS и упоминают LDAP в своих постах.
Проблема в том, что я (пока?) Не заинтересован в реализации CAS. Я хочу настроить демо-сервер для людей и позволить им войти в систему со своими учетными данными LDAP/AD. Я выбрал привязку, так как у меня нет доступа к логину, который позволяет мне (и, следовательно, liferay) видеть указанные пароли.
Я знаю, что это безумие, но я также не хочу, чтобы их пароли отправлялись в открытом виде.:)
Ни один из документов Liferay не обсуждает, как гарантировать, что Liferay запускает TLS. Я не эксперт по LDAP, так что, возможно, это обычно обеспечивается сервером LDAP или AD, но даже в этом случае было бы неплохо, если бы документы сказали что-нибудь о том, как обеспечить, чтобы злой сотрудник или злой злоумышленник сети могли не слушайте запросы входа в систему life-ray, чтобы получить доступ ко всем вещам.
Из того, что я прочитал, правильная вещь для текущих реализаций LDAP - для клиента инициировать связь TLS для чувствительных запросов
http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html
Так Liferay делает это? Нужно ли что-то настраивать, чтобы включить его?
Тот факт, что http://issues.liferay.com/browse/LEP-4225 возникает, когда я работаю в Google, вызывает серьезные сомнения относительно того, действительно ли это реализовано в Liferay (однако я замечаю, что это против "старого liferay")...)
По сути, я прошу кого-то, кто на самом деле знает, чтобы выяснить, что / не доступно, и нужно ли мне что-либо делать для обеспечения безопасной связи с LDAP/AD.
Обратите внимание, что в настоящее время меня не интересуют клиентские сертификаты или другая аутентификация клиента (liferay) на сервере LDAP. Просто надежно делегируйте аутентификацию LDAP/AD.
РЕДАКТИРОВАТЬ: я только что подтвердил (с Wireshark), что в конфигурации по умолчанию "тестовое соединение" отправляет мой пароль в виде открытого текста, так что это, кажется, реальная проблема
РЕДАКТИРОВАТЬ 2: Также подтвердил, что при входе в систему пароль отправить в виде открытого текста. Зашифрованное решение явно необходимо.
2 ответа
Исправляя мой первоначальный ответ после того, как я, кажется, неправильно прочитал вопрос - после редактирования становится понятнее, что подразумевается соединение LDAP.
К сожалению, я не могу дать хороший ответ из коробки прямо сейчас, но, надеюсь, некоторые полезные советы:
Когда вы используете соединение LDAP через SSL, вам необходимо убедиться, что tomcat (инициатор соединения) доверяет сертификату, который предоставляет сервер LDAP. Скорее всего, этот сертификат не выдан известным и доверенным органом (например, он, вероятно, самоподписан).
Помните, что SSL не только означает шифрование, но и доверяет другому концу, которому он заявляет: было бы глупо полагаться на шифрование, если какой-либо посредник может заставить вас подключиться к себе в зашифрованном виде. Таким образом, вы хотите какое-то подтверждение личности того, к которому вы подключаетесь.
Когда вы заходите в Google "LDAP SSL Java", вы получаете много хитов, дающих хорошие примеры и объяснения, как настроить виртуальную машину Tomcat (и ее хранилище ключей). Да, это виртуальная машина, для которой вам нужно настроить доверие. http://docs.oracle.com/javase/jndi/tutorial/ldap/security/ssl.html содержит основные указатели (во вступительном абзаце) с указанием
После установки и настройки JSSE вы должны убедиться, что клиент доверяет серверу LDAP, который вы будете использовать. Вы должны установить сертификат сервера (или сертификат его CA) в базе данных доверенных сертификатов вашей JRE. Вот пример.
# cd JAVA_HOME/lib/security # keytool -import -file server_cert.cer -keystore jssecacertsДля получения информации о том, как использовать инструменты безопасности, см. Журнал по безопасности платформы Java 2 Учебного руководства по Java. Для получения информации о JSSE прочитайте Справочное руководство по JSSE.
В основном: если вы не использовали keytool, вы, вероятно, не настроили доверие к сертификату вашего сервера LDAP в вашей виртуальной машине Liferay. Помните, что вы еще не закончили, вам все равно нужно включить хранилище ключей, которым манипулирует keytool, в вашу виртуальную машину. Я ожидаю сообщения об ошибках, связанные с доверием, в лог-файлах. Поскольку вы не предоставляете файлы журналов и не предоставляете информацию о том, какое доверие вы установили, сделайте это или сообщите мне, если вам нужна дополнительная информация
Исходный ответ (до выяснения, что подразумевается LDAP-соединение):
Проверьте конфигурацию по умолчанию portal.properties Liferay и переопределите ее в $LIFERAY_HOME/portal-ext.properties. Там вы найдете значение по умолчанию
#
# Set this to true to ensure users login with https. If this is set to true
# and you want your HTTP session to contain your credentials after logging
# in, then the property "session.enable.phishing.protection" must be set to
# false or your credentials will only be available in the HTTPS session.
#
company.security.auth.requires.https=false
Если вы установите значение true, у вас может быть все, что вы хотите.
Это, конечно, предполагает, что у вас уже настроен и работает https (например, если вы заходите по https://localhost/ или везде, где живет ваш сервер (или https://localhost:8443/, если вы используете пользовательский порт 8443). Как вы это делаете, это вопрос настройки вашего сервера приложений. Как только Liferay ответит правильно, когда вы получите к нему доступ через https, вы можете применить все остальное.
Приложения должны передавать пароли в открытом виде по безопасному соединению для смены пароля и для аутентификации, потому что современный сервер каталогов профессионального качества имеет возможность проверки качества пароля и истории паролей. Предварительно закодированные пароли нельзя проверить на качество или историю. По этой причине правильно настроенный сервер каталогов не будет принимать предварительно закодированные пароли.