Slashdot Mirror
Best Practices for Writing LDAP Aware Apps?
Saqib Ali asks: "I am in a process of writing a web application, that makes quite a lot of transactions with the LDAP server. I would like to find out, what are the best practices in encrypting the traffic from the web application server to the LDAP server. I understand, I have few choices: SSL, TLS/SASL (supported by SunOne/OpenLDAP), and the traditional STUNNEL. Any ideas, on the best way to provide encryption? . What is the value of 'encrypting everything' and cost of encryption (encryption is process intensive)? I would also like to locally cache the data I receive from the LDAP directory. Are there any solutions for doing that? Or should I just cache the data in a SQL database running locally on the WebApp server?"
I'm not an expert on this, but as far as I know there shouldn't be that much difference between these alternatives, except in terms of practical functionality and hassle factor. So depending on your application you should just pick whichever one of these is easier for you to use. Otherwise, Transport Layer Security is a fairly standard thing and I doubt that one of those methods is particularly more vulnerable (or less) or more efficient (or less) than the others. SSL is great, for instance - just self-approve your certificates (and maybe auto-regenerate them every X weeks).
:-) Also, if you're going to be sending masses of data across a fast connection (eg transferring a div-x or something) then it's probably fairly useless to go and encrypt all that, unless you've got a particular reason to be worried about someone snooping on your pr0n download :-)
An ssh tunnel does things well nicely as well, and is probably the simplest of the simple ways of implementing this. Assuming you're writing in Java, there's a couple of ssh java libs on freshmeat which you can use to automatically set up the tunnel, et voila - access the port as if it was on the local server, and it all gets tunneled out securely.
As for the value of encrypting everything, I don't see how it can ever be a bad idea unless you're running this on your LAN at home
Daniel
Carpe Diem
My advice? Run OpenLDAP locally, and replicate the entire LDAP directory locally. Use OpenSSH tunneling (using port forwarding) to encrypt the connections between the master LDAP server and the local slave.
This way, your replication process can be over the slow SSH tunnel, but your transactions can be fast as they are local.
Where I work we avoided a lot of software complexity (and freed all but one machine from the CPU overhead of encryption) by putting extra NICs in the machines and running unencrypted over crossover cables.
This obviously doesn't scale to large numbers of servers, but it's something to think about for a small implementation.
I would also like to locally cache the data I receive from the LDAP directory. Are there any solutions for doing that? Or should I just cache the data in a SQL database running locally on the WebApp server?"
Caching locally in an SQL database is not going to be very efficient - as a general rule, LDAP reads are going to be faster than SQL reads. Caches are for speed, not reliability. If time on wire is your concern, run a local LDAP slave. For raw speed, use MLDBM or similar for your cache - you really can't get much faster without writing an application specific cache that sits in memory.
I forget what 8 was for.
The OpenLDAP library provides a mechanism for local client side caching of results from queries against an LDAP directory. For more info check out the ldap_cache man page.
There have been several good suggestions so far but, I'd like to add something to keep in the back of your mind. One of the big complaints with various systems, Microsoft for instance, is a lack of interoperability.
I would recommend using a solution that is going to be compatible with the most other systems without unnecessary complexity. Some recommend using SSH as an easy method. This is fine for Linux systems but, what if you need to later add Microsoft or Novell systems? SSH may still be doable but, it will be far more difficult. Keeping things interoperable is very important for the future. I'd recommend that you use TLS as it will be the most interoperable secure solution.
On the matter of caching, this is adding unnecessary complexity. Remember Keep It Simple Stupid(KISS). If you need local LDAP access, don't manufacture some convoluted caching system, instead use a local LDAP server. LDAP already handles everything for you. You'll also discover that a good LDAP server won't add too much load to your system. And if you want a GREAT directory and LDAP server, take a look at Novell's eDirectory, it offers very high performance, massive scalability, replication, partitioning, cross platform support and more.