How can I ensure Liferay uses TLS for authentication

Question

Please note, this is about communication between Liferay and the LDAP server, not communication between the user's browser and Liferay

I'm asking this here since I got zero views (other than my own) in 30 minutes at the liferay forums, and I'd like to solve this today if possible...

I've looked at:

http://www.liferay.com/community/wiki/-/wiki/Main/LDAP

http://www.liferay.com/community/wiki/-/wiki/Main/LDAP+integration

I've also read this:

http://www.liferay.com/documentation/liferay-portal/6.1/user-guide/-/ai/ldap

And I've done a bunch of searching and found lots of folks setting up CAS and mentioning LDAP in their posts.

Problem is I'm not (Yet?) interested in implementing CAS. I want to set up a demo server for folks and allow them to log in with their LDAP/AD credentials. I've opted for binding since I don't have access to a login that allows me (and therefore liferay) to see said passwords.

I know this is crazy, but I also don't want their passwords to be sent in the clear. :)

None of the liferay docs discuss how to ensure that liferay starts TLS. I'm not an LDAP expert, so perhaps this is normally enforced by the LDAP or AD server, but even in that case it would have been nice if the docs said something about how to ensure that an evil employee, or evil network intruder can't simply listen to life-ray log-in requests to gain access to everyone's stuff.

From what I've read, the right thing for current LDAP implementations is for the client to initiate TLS communication for sensitive queries

http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html

So does Liferay do this? Do I need to configure anything extra to enable it?

The fact that http://issues.liferay.com/browse/LEP-4225 comes up when I google, throws signifcant doubt on wether or not this is even implemented in Liferay (I notice however that this is against "old liferay"...)

Basically I'm asking for someone who actually knows, to clear up what is/isn't available and whether or not I need to do anything to enable secure communications with LDAP/AD.

Note that I'm not interested in client certificates or otherwise authenticating the client (liferay) to the LDAP server at this time. Just securely delegating authentication to LDAP/AD.

EDIT: I just confirmed (with wireshark) that in the default configuration "test connection" sends my password in cleartext, so this seems to be a real problem

EDIT 2: Also confirmed that login attempts send the password in clear text. An encrypted solution is clearly necessary.

Answer 1

Correcting my original answer after I seem to have misread the question - it's clearer after the edit that the LDAP connection is meant.

Unfortunately I can't give a good answer out of the box right now, but hopefully some helpful pointers:

When you use an LDAP connection through SSL, you need to make sure that tomcat (the initiator of the connection) trusts the certificate that the LDAP server presents. Most likely this certificate is not issued by a known and trusted authority (e.g. it's probably self-signed).

Remember that SSL not only means encryption but also trusting the other end that it's the one that it states to be: It would be stupid to rely on encryption if any man-in-the-middle can cause you to connect to itself, encrypted. So you want some proof of identity of the one that you connect to.

When you google "LDAP SSL Java" you get a lot of hits giving good examples and explanations how to configure tomcat's virtual machine (and its keystore). Yes, it's the VM that you need to configure the trust to. http://docs.oracle.com/javase/jndi/tutorial/ldap/security/ssl.html contains basic pointers (in the introductory paragraph), stating

Once the JSSE has been installed and configured, you need to ensure that the client trusts the LDAP server that you'll be using. You must install the server's certificate (or its CA's certificate) in your JRE's database of trusted certificates. Here is an example.

# cd JAVA_HOME/lib/security
# keytool -import -file server_cert.cer -keystore jssecacerts

For information on how to use the security tools, see the Java 2 Platform Security trail of the Java Tutorial. For information on the JSSE, read the JSSE Reference Guide

Basically: If you didn't use keytool, you probably haven't set up trust to your LDAP server's certificate in your Liferay VM. Remember that you're not done then, you still need to include the keystore manipulated with keytool into your VM. I would expect trust-related error messages in the logfiles. As you neither give logfiles nor information on what kind of trust you established, please do so or let me know if you need further information

Original answer (before clarification that LDAP connection is meant):

Check Liferay's portal.properties default configuration and override it in $LIFERAY_HOME/portal-ext.properties. There you'll find the default value

#
# 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

If you set this to true, you might have everything you want.

This of course assumes, that you have https already set up and running correctly (e.g. if you go to https://localhost/ or whereever your server lives (or https://localhost:8443 if you use a custom port 8443). How you do this is a matter of configuring your application server. Once Liferay answers correctly when you access it through https you can enforce the rest.

Answer 2

Applications must transmit passwords in the clear over a secure connection for password changes and for authentication because modern, professional quality directory server have the capability of checking password quality and password history. Pre-encoded passwords cannot be checked for quality or history. A correctly configured directory server will not accept pre-encoded passwords for this reason.