Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Could the folks who are voting to close as off topic please clarify where they think I should ask this question. If this should be moved to some other stack exchange then please do move it... I'm not getting much response here anyway. –  Gus Feb 16 '12 at 14:56
    
Oh lovely, no liferay tag here. This really is liferay specific... Someone care to make one? –  Gus Feb 16 '12 at 23:11
    
thx for creating the tag, to whoever did it :) –  Gus Feb 22 '12 at 19:10
    
see if my edited answer helps or gives more information. Re the tag: You're welcome ;) –  Olaf Feb 24 '12 at 11:32
add comment

migrated from stackoverflow.com Feb 16 '12 at 16:09

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 0 down vote accepted
+50

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.

share|improve this answer
    
This causes firefox to complain about: An error occurred during a connection to localhost:8080. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) --- And no request is sent to ldap at all. –  Gus Feb 21 '12 at 16:32
    
Are you sure you didn't set your https port to 8080? This looks like firefox tries to do https through the port that has only http - obviously this will fail and not do anything. Will add a precondition to my answer right now. –  Olaf Feb 21 '12 at 20:30
    
I was rather hoping not to have to set up https for my local box for this. Certainly the mode of communication between liferay (in tomcat) shouldnt be tied to the mode of communication between the browser and the tomcat server. Before I go spend a couple hours creating keys and setting up tomcat (and liferay) for https, can you explain to me why you think this relates to the ldap-tomcat communications? Certainly https will be in use in the final install, but I'd like not to mix https setup with ldap setup if at all possible. Change one thing at a time... etc –  Gus Feb 22 '12 at 18:57
    
sorry, misread the question - it's clearer now after the edit. –  Olaf Feb 23 '12 at 22:15
    
Yeah, your edit was what I had accomplished yesterday... The setup is categorized as "unstandardized" and deprecated by LDAP v3 (see RFC4513). The method in 4513 allows secure communication over port 389, and would probably also require the keytool/trust setup. I have to admit disappointment at JSSE requiring VM level configuration, and disappointment that Liferay doesn't use Ldap v3 communications given that that RFC was published in 2006. Given that you've arrived at the same workaround as me, and put in the effort I think I will give you credit :) –  Gus Feb 24 '12 at 15:10
show 2 more comments

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.

share|improve this answer
    
From what I've read, that would be true of the initial connection, but not subsequent communications. So Anonymous (or other untrusted user) would be used to login initially, and then upgrade to TLS to send the user's credentials over an encrypted connection. The password would be clear within the encryption, but not visible to the likes of wireshark. Unfortunately, I was able to see the user's credentials in addition to the initial login when I snooped the connection. See my link to the java (oracle) tutorial on how to use LDAP/TLS (in java). –  Gus Feb 16 '12 at 14:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.