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.
You can find a good load of information on directory services etc from various sources. I have found lots of on information on STUNNEL. There is also lots of LDAP info at LDAP Top 100.
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.
Moderators, check the parent's links before moderating. Insightfull? Yikes.
you could use KDE's kioslaves, and make you app awaire of a lot more than LDAP.
File, document and data access. KDE provides a network-transparent file, document and network protocol access architecture using the KIOSlave I/O objects. When a new KIOSlave is "dropped in" a system its services are automatically available to all KDE-compliant applications. This modular, plug-in nature of KDE's data architecture makes it simple to add additional protocols (such as IPX) to all of KDE.
A large number of protocols have already been implemented, from HTTP, SFTP/FTP, telnet/SSH, POP/IMAP, NFS/SMB/NetBIOS, LDAP, WebDAV (new) and local files to man and info pages, SQL queries, audio CDs, digital cameras, PDAs and even shell commands. All requests can be bookmarked for simple and quick retrieval of often-accessed data.
thank God the internet isn't a human right.
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
This is for a small setup. Veriations include running a set of LDAP replicas behind your webfarm firewall, etc.
LDAP is a great tool for virtual user setups. We've converted our entire campus network to have all authentication go to LDAP, and neither IT department nor the users have ever been happier.
Good luck
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
A quick generic note - if you just want an encrypted channel, stunnel (or sshd tunnels) are good enough and eliminate a lot of complexity from your setup.
But I've rarely see situations where I want encryption but don't care who the other party is. If you want to make sure that the LDAP master is who it claims to be, you really need to use SSL with mutual authentication (since the server will also want to verify the identify of its clients). You can probably set up stunnel to verify this, but I personally prefer to keep authentication as close as possible to the tools that need it.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
On a semi-related topic, does anyone have a good pointer or two on writing an SSL aware app, or porting an exsiting app to use OpenSSL?
Background:
My school is turning off non-encrypted access to the the tn3270 machines, and I can't seem to find any free tn3270 client that support SSL. Being a Computer Science student I figured I'd add the capabilities myself, but I have no idea where to begin.
So how about it? Can anyone point me to a howto or relavent documentation?
This may or may not be feasible, but IPSec in transport mode is an excellent way to secure data between two hosts on a LAN.
Why don't you just throw another nic into the web and LDAP servers? Then set up a private (10.x.x.x) network off of that nic which is connected to any of the internal servers you might need to access. That way you don't have to worry about the encryption overhead or having your LDAP server exposed to the internet.
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