All You Need to Know About LDAP

Short for LDAP according to abbreviationfinder, Lightweight Directory Access Protocol is an application-level protocol that allows access to an ordered and distributed directory service to search for various information in a network environment. LDAP is also considered a Database that can be queried. It is based on the X.500 standard. Usually, it stores authentication information (user and password) and is used to authenticate, although it is possible to store other information (user contact data, location of various network resources, permissions, certificates, among other data). LDAP is a unified access protocol to a set of information on a network.

Origin

Telecommunications companies introduced the concept of directory services to Information Technology and Computer Networks, thus their understanding of directory requirements was well developed after 70 years of producing and managing telephone directories. The culmination of this effort was the X.500 specification, a set of protocols produced by the International Telecommunication Union (ITU) in the 1980s.

X.500 directory services were traditionally accessed via DAP (Directory Access Protocol), which required the OSI (Open Systems Interconnection) protocol stack. LDAP was originally intended to be a lightweight, alternative protocol for accessing X.500 directory services over the simpler (and now more widespread) TCP / IP protocol stack. This directory access model was imitated from the DIXIE Directory Assistance Serviceprotocols.

Standalone LDAP directory servers were soon implemented, as well as directory servers that supported DAP and LDAP. The latter became popular in enterprises because it eliminated any need to deploy an OSI network. Now, the X.500 directory protocols including DAP can be used directly over TCP / IP.

The protocol was originally created by Tim Howes (University of Michigan), Steve Kille (Isode Limited), and Wengyik Yeong (Performance Systems International) around 1993. A more complete development has been done by the Internet Engineering Task Force.

In the early stages of LDAP engineering, it was known as the Lightweight Directory Browsing Protocol, or LDBP. It was later renamed as the scope of the protocol had been expanded to include not only directory browsing and search functions, but also directory update functions.

LDAP has influenced later Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and Service Location Protocol (SLP).

Characteristics of an LDAP directory

• It is very fast in reading logs.
• It allows to replicate the server in a very simple and economical way. Many * applications of all kinds have connection interfaces to LDAP and can be easily integrated.
• Use a hierarchical information storage system.
• It allows multiple independent directories.
• It works over TCP / IP and SSL (Secure Socket Layer).
• Most applications have LDAP support.
• Most LDAP servers are easy to install, maintain, and optimize.
• Given the characteristics of an LDAP, its most common uses are:
• Information directories.
• Centralized authentication / authorization systems.
• Email Systems.
• Public certificate servers and security keys.
• Single authentication or SSO for application customization.
• Centralized user profiles.
• Shared address books.

The Advantages of LDAP Directories

Now that we have “straightened out”, what are the advantages of LDAP directories? The current popularity of LDAP is the culmination of a number of factors. I’ll give you a few basic reasons, as long as you keep in mind that this is only part of the story.

Perhaps the greatest advantage of LDAP is that your company can access the LDAP directory from almost any computing platform, from any of the growing number of applications readily available for LDAP. It’s also easy to customize your internal company applications to add LDAP support.

The LDAP protocol is cross-platform and standards-based, so applications do not need to worry about the type of server the directory is hosted on. In fact, LDAP is finding much wider acceptance because of its status as an Internet standard. Vendors are more keen to code for LDAP integration into their products because they don’t have to worry about what’s on the other side. Your LDAP server can be any of a number of commercial or open source LDAP directory servers (or even a DBMS server with an LDAP interface), since interacting with any true LDAP server carries the same protocol, client connection packet, and query commands. By contrast,

Unlike relational databases, you don’t have to pay for each client software connection or license.

Most LDAP servers are simple to install, easily maintainable, and easily tuneable.

LDAP servers can replicate some of your data as well as all of it through sending or receiving methods, allowing you to send data to remote offices, increase your security, and more. Replication technology is built in and easy to configure. By contrast, many of the DBMS vendors charge extra for this feature, and it is considerably more difficult to manage.

LDAP allows you to safely delegate authorization-based reading and modification according to your needs using ACIs (collectively, an ACL, or Access Control List). For example, your group of facilities can give access to change the location of employees, their cubicle, or office number, but it is not allowed to modify entries in any other field. ACIs can control access depending on who is requesting the data, what data is being requested, where the data is stored, and other aspects of the record that is being modified. All of this done directly through the LDAP directory, so you don’t need to worry about doing security checks at the user application level.

LDAP is particularly useful for storing information that you want to read from many locations, but that is not frequently updated. For example, your company could store all of the following data in an LDAP directory:

• The company’s employee phone book and organizational chart
• External customer contact information
• Information on the service infrastructure, including NIS maps, email aliases, and more
• Configuration information for distributed software packages
• Public certificates and security keys

Using LDAP to store data

Most LDAP servers are heavily optimized for read intensive operations. Because of this, one can typically see a different order of magnitude when reading data from an LDAP directory versus getting the same data from an OLTP-optimized relational database. However, because of this optimization, most LDAP directories do not do well with storing data where changes are frequent. For example, an LDAP directory server is good for storing your company’s internal phone book, but don’t even think about using it as a database repository for a high-volume e-commerce site.

If the answer to each of the following questions is Yes, then storing your data in LDAP is a good idea.

• Would you like your data to be available through various platforms?
• Do you need access to this data from a number of computers or applications?
• The individual records that you are stored change a few times a day or less, as measured?
• Does it make sense to store this type of data in a flat database instead of a relational database? That is, can you store all the data, for a given item, effectively in a single record?

This final question often makes people pause, because it is very common to access a plain register to obtain data that is relational in nature. For example, a record for a company employee might include the login name of that employee’s manager. It is good to use LDAP to store this type of information. The cotton test: If you can imagine all your data stored on an electronic Rodolex, then you can easily store your data in an LDAP directory.