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.
Your replica idea was spot on I think. Many LDAP administrators don't think that way because they're use to paying huge per server fees. With OpenLDAP that's a moot point so that approach is best.
But you don't need OpenSSH to encrypt your data. You have the much faster native TLS encryption built into the server.
You configure your replicas to replicate using TLS only.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
If you understand how SSL works, and just need an introduction to using OpenSSL in your programs, have a read of Eric Rescorla's OpenSSL Introduction. PDFs available at http://www.rtfm.com/openssl-examples/.
For more information, buy his book!
I wouldn't run a full replica on a webhost, for various reasons... a lot of the data may not be relevant, thus it's a waste of disk, security concerns, etc.
Depending on your application, you might find nscd (name service caching daemon) to be useful, we certainly did in our largish institution. In our application we're primarily using LDAP for authentication on the web servers, and nscd is the perfect tool for caching that data... here's a quick excerpt from 'man nscd':
Nscd provides cacheing for the passwd(5), group(5) and hosts(5) databases through standard libc interfaces, such as getpwnam(3), getpwuid(3), getgrnam(3), getgrgid(3), gethostbyname(3) and others.
Anyway, with pam auth and nscd, it's no trouble to run TLS for all transactions, since the nscd cache keeps the overhead to a reasonable amount. In terms of replication, we have a master for all writes, then read-only replica for all queries from each major network division (two major networks plus dmz in our case) so that query traffic doesn't have to cross the firewall.
This scales pretty well in our case, and the idea is pretty extensible if your primary application is authentication type info.
~Acheron