Interoperability, as has already been mentioned, is very much in LDAP's favour with some types of server software, although much of the software that integrate with LDAP require a specific schema so it's not necessarily as simple as just installing and configuring an LDAP service and off you go - you might need to add new elements in the schema for each app you want to interact with, and each application might have different limitations with regard to authentication (for example plain text password fields, password fields as MD5 hashes or SHA hashes with a salt, etc).
A good LDAP service requires a fair bit of configuration knowledge too, more so than creating a simple schema in something like like MySQL. SQL DB's are still a fairly interoperable option, LDAP support is not as uniquely dominant as it once was. Many applications (like Apache) and operating systems (like Linux's PAM) can authenticate against SQL DB's just as easily as LDAP servers as it's all handled by drivers that abstract the interface.
Where LDAP really shines is scalability. If you specifically want a place to hold user accounts for authentication and want to scale to multiple replicated servers and handle tends of thousands of authentication requests a second, LDAP is an excellent option. It's not that modern RDBMS's aren't good enough to do this, it's just that LDAP is (typically) even better because of the way it cascades replication through different tiers. You can do that with a few RDBMS replication systems, but in practice not all (particularly when it comes to doing it reliably with dozens of servers and really huge authentication databases, where queries tend to be mostly read operations so where one way replication is an acceptable model).
Really though, looking at an LDAP server is something to consider if you have a specific need to do so, like aspecific application you want to be able to interoperate with, or if you are building a highly scalable authentication system (e.g. for an ISP or for a super-scalable web application - where you plan on having more than a couple servers dedicated just to authentication, and where they may be spread across the country or even across the globe).
The point someone has already made about having an LDAP front end on an RDBMS is very good one. A few companies - including Oracle (who have a vested interest, obviously) - have products that do specifically that. If you don't want the overhead of managing an LDAP service, or if you just want to manage all your users in a DB you can create views/joins with, but think you might need an LDAP service later, than it's a perfectly valid option. OpenLDAP supports a shell back end which can take data from any source, including an RDBMS (e.g. I've used it with MySQL).
In summary, LDAP's great, but it's situation specific to interoperability and extreme scalability. If you have limited resources to manage and support one, it might not be worth the hassle of supporting, but if you are planning services like UNIX hosted POP/IMAP/SMTP or other third party software integration then it's certainly worth doing (and may even be your only option).
Oh and lastly be wary of what LDAP server you use if you do decide to implement one! They are not all created equal and the differences between them (in terms of performance and ease of management & configuration) can be quite stark.
OpenLDAP is a pretty safe bet, scales well and is fairly easy to use. Some applications work best / come with specific configuration files for a specific LDAP server (e.g. a lot of software on Solaris assumes you are using Sun ONE directory server) which you might not otherwise want to use (because it doesn't perform as well, or is a pig to configure, etc).
No comments:
Post a Comment