Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Best Practices for Writing LDAP Aware Apps? 33

Posted by Cliff from the seking-proper-coding-suggestions dept.
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?"
This discussion has been archived. No new comments can be posted.

Best Practices for Writing LDAP Aware Apps? More

Best Practices for Writing LDAP Aware Apps?

Comments Filter:

  • All equivalent? (Score:5, Informative)

    by KDan ( 90353 ) on Monday February 17, 2003 @07:44AM (#5318365) Homepage
    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).

    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 :-) 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 :-)

    Daniel

  • SSH tunnel, local replica (Score:5, Informative)

    by Vendekkai ( 121853 ) on Monday February 17, 2003 @07:47AM (#5318369)
    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.
    • That's how we do it here.

      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)
    • Correct me if I'm wrong, but isn't storing ALL your data on the web server a bit insecure. Ideally you should have the LDAP server behind a firewall and have the web app authenticate itself to pull the data. Obviously this isn't going to give complete security, since if the web server gets cracked it can be used to attack the LDAP server, but it'll make a cracker jump through a few more hoops. Otherwise, if the web server gets cracked the attacker can suck all of the data in the directory straight off the web server.
    • This way, your replication process can be over the slow SSH tunnel, but your transactions can be fast as they are local.

      Fortunately, anything anyone is planning to do over LDAP (and particularly OpenLDAP) is extremely unlikely to be performance-critical.
      • Fortunately, anything anyone is planning to do over LDAP (and particularly OpenLDAP) is extremely unlikely to be performance-critical.

        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.

        • *the* mission critical service

          It's not that it's *unreliable*. It's "performance critical" that I was addressing, not "mission critical".
          • It's not that it's *unreliable*. It's "performance critical" that I was addressing, not "mission critical".

            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.

    • his way, your replication process can be over the slow SSH tunnel, but your transactions can be fast as they are local.

      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)

    by Colitis ( 8283 ) <jj...walker@@@outlook...co...nz> on Monday February 17, 2003 @07:47AM (#5318371)
    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.
    • 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.

      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)

        by KDan ( 90353 )
        Well, If they manage to break into the computer systems rooms and install taps on the wires unnoticed, then you can't trust your machines either, so encrypting is useless (they could replace your programs on the hard drives with trojaned copies that send a copy to them!!! omg!).

        Good dose of paranoia = good...

        Mental illness paranoia = not so good...

        :-P

        Daniel
      • Quote:
        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)

    by abulafia ( 7826 ) on Monday February 17, 2003 @10:16AM (#5318870)
    Other folks are giving good answers on the encryption side of things. I'll address this one:



    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)

      by jhubbard ( 4916 )
      You might check out what the samba developers are doing with the 3.0 series. Supposedly, they were looking at caching some of the username and password data so they weren't hitting the ldap server as much.

  • OpenLDAP caching (Score:3, Informative)

    by Andrew Lockhart ( 4470 ) on Monday February 17, 2003 @10:58AM (#5319133) Homepage
    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.

  • Lowest common denominator & KISS. (Score:5, Informative)

    by FreeLinux ( 555387 ) on Monday February 17, 2003 @11:08AM (#5319192)
    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.
    • 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.

      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.

    • I've been meaning to integerate LDAP with our mail server so I'm curious as to how OpenLDAP compares with the commercial alternatives. You mentioned Novell eDirectory..

      "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.

      • "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."

        It's better than that: 1) The first 250,000 licenses are free http://www.novell.com/products/edirectory/promo.ht ml [novell.com]
        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.
  • 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.
    1. Run a replica on your webserver.
    2. Configure your applications to access the local replica using '127.0.0.1' unencrypted. That's the fasted you're going to get without using LDAPI ( LDAP over IPC, eg unix sockets ). At any rate, that's pretty damn fast.
    3. Configure your webserver LDAP replica to only listen on the 'le0' interface, or your localhost interface. For security, also it's usually a good idea to run a firewall.
    4. Configure your replica to replicate with the master server using TLS.

    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

    • This is an EXCELLENT suggestion. I have done this many times. 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.
      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).
      • This is an EXCELLENT suggestion.

        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.

  • 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.
  • 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?

  • IPSec (Score:1)

    by Matty_ ( 74368 )
    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.

  • caching... (Score:2, Informative)

    by Acheron ( 2182 )
    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

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close