Best Practices for Writing LDAP Aware Apps? 33
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?"
All equivalent? (Score:5, Informative)
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
SSH tunnel, local replica (Score:5, Informative)
This way, your replication process can be over the slow SSH tunnel, but your transactions can be fast as they are local.
Re:SSH tunnel, local replica (Score:2, Informative)
However, you still need an SSL-Conenction to the master database in case you need to do any updates (updates or only done at the master ldap server and then get replicated to the slaves from there)
Re:SSH tunnel, local replica (Score:2, Informative)
Re:SSH tunnel, local replica (Score:2)
Fortunately, anything anyone is planning to do over LDAP (and particularly OpenLDAP) is extremely unlikely to be performance-critical.
Re:SSH tunnel, local replica (Score:3, Interesting)
That is simply not true.
I can give you tons of examples of OpenLDAP as *the* mission critical service. It takes care of all the virtual users on all services. IMAP, POP, PAM, HTTP auth, they all access the LDAP system for user authentication.
OpenLDAP is one of the fastest and most reliable LDAP servers ( or services, period ) out there. I have replicas that sit there and do nothing because the masters *never* go down.
In on our campus OpenLDAP was much more reliable than Netscape/iPlanet/SunOne server. We know this because we ran iPlanet for 2 years before making the upgrade.
Re:SSH tunnel, local replica (Score:2)
It's not that it's *unreliable*. It's "performance critical" that I was addressing, not "mission critical".
Re:SSH tunnel, local replica (Score:2)
Ok, sorry about that.
But I still disagree with this statement. LDAP servers are often optimized for read performance and for storing small "records" or entries.
Because of this they perform better than SQL databases at what they do.
Honestly, I don't know of a faster network datastore one could find.
OpenSSH is not needed (Score:3, Informative)
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.
Crossover connections? (Score:5, Interesting)
This obviously doesn't scale to large numbers of servers, but it's something to think about for a small implementation.
Re:Crossover connections? (Score:1)
It's like an endless race on defense and intrusion, but the math is in fact simple - make sure the cost of break-in is much more than the cost of the information. Well, how to make sure? that's the hard part.
Re:Crossover connections? (Score:3, Insightful)
Good dose of paranoia = good...
Mental illness paranoia = not so good...
Daniel
Re:Crossover connections? (Score:2, Insightful)
Unless you could secure the entire crowssover cable someone could still tap in the middle. My suggestion is to use encryption when the line is not physically contained.
End quote
In the case I was talking about, the machines are less than a metre apart and in a locked room. If somebody can get in there, there are worse things they can do than tap a cable.
Caching (Score:5, Insightful)
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.
Re:Caching (Score:2, Informative)
OpenLDAP caching (Score:3, Informative)
Re:OpenLDAP caching (Score:1)
pointer
Lowest common denominator & KISS. (Score:5, Informative)
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.
Re:Lowest common denominator & KISS. (Score:3, Informative)
The thing is, OpenSSH just isn't needed here. That's like running HTTP traffic over OpenSSH for security. Why not run HTTPS instead.
LDAP has LDAPS, ie LDAP over SSL and just about all LDAP servers support this. OpenLDAP does this nicely.
In fact since it's TLS ( next generation SSL ), you don't need a second port for encrypted protocol versus unecrypted. TLS clients can connect to the same port and encryption is negotiated.
Re:Lowest common denominator & KISS. (Score:1)
"it offers very high performance, massive scalability, replication, partitioning, cross platform support and more."
Am I reading their prices [novell.com] right? $2 per user?? I might just reinstall Redhat on a spare box to test this out. Too bad they don't have a FreeBSD version.
Re:Lowest common denominator & KISS. (Score:2)
It's better than that: 1) The first 250,000 licenses are free http://www.novell.com/products/edirectory/promo.h
2) Many current Novell products (like iChain, & some products from other vendors) come with eDirectory licenses
3) Any significant purchase over the 250K mark is going to qualify for some type of volume purchase and thus cost less than $2/user.
KDE (Score:2)
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.
I've done this... (Score:2)
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
Re:I've done this... (Score:2)
Also note: if you limit your LDAP replica to listening only on the loopback address, then it may not be able to receive updates from the master (unless your LDAP server has a separate replication daemon, i.e., slurpd).
Re:I've done this... (Score:2)
Why, thank you. :)
However, this really works best only if the aaplication only needs read access! Otherwise, the application's writes need to be referred to the writable master copy, which in this configuration, is unencrypted.
If an app tries to write to the replica, it should recieve a referral. I believe the referral can be an LDAP URI, which means that it can actually specify the encrypted protocol eg. ldaps://master.domain.... .
I don't use referrals though, I write directly to the master from my apps that need write access, in my case. For a large setup, and for redundancy, using referrals are best. The application connects using LDAPS to the master, and regular encrypted LDAP to the local replica.
if you limit your LDAP replica to listening only on the loopback address, then it may not be able to receive updates from the master (unless your LDAP server has a separate replication daemon, i.e., slurpd).
True. In my case, OpenLDAP, does use a separate replication service.
This btw is something I do any chance I can get away with it. If a service does not *have* to listen on the network, I specify localhost as the listening address.
I third option is to compile OpenLDAP with libwrap support and use hosts.allow and friends to specify who connects and who doesn't.
SSL vs. stunnel (Score:2)
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.
SSL aware apps? (Score:2)
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?
Re:SSL aware apps? (Score:3, Informative)
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/ [rtfm.com].
For more information, buy his book!
IPSec (Score:1)
Private net (Score:1)
caching... (Score:2, Informative)
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