Security Threats

Understanding and Deploying LDAP Directory Services > 1. Directory Services Overview > What a Directory Is Not

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078209007012160234000092010

What a Directory Is Not

In our experience, people sometimes have one of two extreme reactions upon learning about the wonders of directories. One reaction is negative: "What good is this directory really going to do? Why can't I just use X to fill that same need? I don't see how this directory is going to be as reliable and perform as well as you say, and I am hesitant to make my application depend on it!" This reaction can usually be overcome by additional education, helping the skeptic see a directory in action, and better explaining all the great things a directory can do for the person.

The other reaction is equally misguided, but can be harder to overcome: "This directory is great! I bet there's nothing it can't do. I can now use the directory instead of my file system, Web server, FTP server, and a host of other things. Finally, a handy, all-in-one tool that chops, slices, dices, makes homemade desserts, but best of all, it cleans itself!" The enthusiasm of this reaction is to be admired, but there is danger here, too. There is an old saying that states that if the only tool you have is a hammer , every problem begins to look like a nail. Needless to say, not all problems are nails , and trying to treat them as such tends to lead to poor carpentry.

A directory is no different ”like any other technology, it is best suited to solving one set of problems. A directory can be usefully applied to many other problems as well, though with somewhat less satisfaction. A directory can be abused by trying to make it solve problems that it was not intended to solve.

In this section we examine this area more closely, explaining some of the many applications for which directories are not well suited. We will explain why directories are different from the following network services that may look similar on the surface:

  • Databases

  • File systems

  • Web servers

  • FTP servers

  • DNS servers

We will explain how your directory can complement all these services and why each one fills a valuable niche in your computing infrastructure. We will conclude this section with a summary of when to use a directory to store information and when to use something else.

Database Comparison

In the previous section we described what a directory is, and we spent quite a bit of time comparing directories to databases. We will not repeat that comparison here, but we will highlight a few important points. First, recall that directories are typically read-focused rather than write-focused. So if your application is writing large volumes of data, say for recording logs or merchandise transactions, you should choose a database over a directory.

Second, directories support a relatively simple transaction model. Directory transactions involve only a single operation and a single directory entry. Databases, on the other hand, are designed to handle large and diverse transactions, spanning multiple data items and many operations. If your application requires this kind of heavy-duty transaction support, again a database is a better answer than a directory. On the other hand, if you have an application that does not have these requirements but instead wants to read and occasionally write information to a network-accessible database in simple transactions, a directory server may well be a good, cost-effective , much simpler choice than using something like an Oracle database.

File System Comparison

A directory makes a poor file system. Files have characteristics that are different from directory information. Files are often very large, containing many megabytes or even gigabytes of information, whereas directories are optimized for storing and retrieving relatively small pieces of information.

Although there is often no restriction on the size of a directory entry or attribute, the question is one of design center. Some files are written far more often than they are read, such as log files and files used to hold a database. Directories, as you'll recall, are optimized for read over write. Some files, of course, are read far more often than they are written. Application binaries are a good example of files in this category, but the size of these files is often larger than should be stored in a directory.

Applications often access files in chunks , especially if the file is large. File systems support calls ”such as seek() , and read() and write() ”can be used to write only a portion of a larger file for this very purpose. Directories do not provide support for this kind of random access. Instead, a directory entry is split up into attributes. You can retrieve attributes separately, but you usually have to retrieve all of any attribute you ask for. There is no way to retrieve only part of a value, starting at some byte offset. File systems, on the other hand, are not good at storing attribute-based information. They do not typically support any kind of searching capability like directories do.

Web Comparison

Since the World Wide Web burst onto the computing scene a few years ago, Web servers have become ubiquitous. Chances are good that your organization, depending on its size, runs anywhere from one to several hundred. Web servers have certain similarities to file systems. They are made to serve clients accessing documents or files that can vary greatly in size. Although Web server documents usually share the typical read-many-write-few characteristic of directory information, directories are not well suited to the task of delivering to clients multimegabyte JPEG images or Java applications.

Web servers also often serve as a springboard to a development platform for Web applications. These platforms range from simple CGI (common gateway interface) to more-complex platforms, such as the one found in the Netscape Application Server. Directories typically do not provide this kind of flexibility in application development, even when they do provide directory application development platform services, such as those provided by the Netscape Directory Server.

Directories are optimized for providing sophisticated searching capabilities of the data they hold. Web servers can be used to develop similar search applications, but such applications are not standards based. Web servers are tuned to providing GUI-style interfaces on applications; they are not tuned to providing generic application access to directory data. If you have a specific database of information you want to make available to users, a Web server might be a good choice. If you have information you want to make available to a wide variety of applications, a directory server is a better choice.

FTP Comparison

An argument similar to the previous one for Web servers applies to File Transfer Protocol (FTP) servers. One could argue that the days of FTP servers are numbered now that Web servers have arrived, but they are hardly threatened by the arrival of directory services. Again, the main differentiating factor is the size of the data and the type of client that needs access to it. Another important point is that FTP is a very simple protocol, tuned to do one thing and do it well. If all you want to do is create a means to transfer files from one place to another, the extra directory infrastructure needed to perform replication, searching, updating, and so on is overkill.

On the other hand, if your application involves more than simple retrieval and storage of information, a directory is a more appropriate choice. Unlike directories, FTP provides no capability for search, no attribute-based information model, and no incremental update capability.

DNS Comparison

DNS, the Internet's Domain Name System, translates host names, such as home.netscape.com, into IP addresses. Host names are good for users wanting to remember how to connect to their favorite Internet service. IP addresses are required by the networking infrastructure underlying the Internet that is responsible for actually making the user 's connection happen. The DNS and a typical directory like LDAP have certain similarities, such as providing access to a hierarchical distributed database. But there are some important differences that set the two apart.

DNS is highly optimized for its main purpose; most directories are meant to be more general purpose. The DNS has a specialized, fixed set of schemas; directories allow schemas to be extended. DNS does not allow updates of its information; directories do. DNS can be accessed over the UDP connectionless transport; directories are usually connection-based.

Note

Some recent work on dynamic DNS by the Internet Engineering Task Force (IETF) is aimed at providing update capabilities. Proposed IETF work on connectionless LDAP is aimed at providing LDAP access over UDP. These efforts and others may bring DNS and LDAP closer together. But for now, the best argument for not trying to replace the DNS with LDAP is that the DNS seems to be working just fine. If it's not broken, don't fix it!



The Complementary Directory

There are certain similarities between directories and many of the services just listed. Directories tend to complement most of these services. We will now take a moment to explore this notion of a complementary directory, what it means, and how it can create synergy among all the services in your enterprise.

A good example of the complementary directory is how it relates to a Web server. Here the directory has a number of important supporting roles to play.

First, the directory can serve as an authentication database. When clients authenticate to the Web server, their credentials are checked against the directory. When the Web server needs to make an access control decision, the directory can again be consulted to determine group membership and other information pertinent to the decision. The value of the directory in this role is especially apparent when you consider an environment that is running many Web servers, all of which need access to the same authentication database. By sharing a directory, the Web servers reduce the user management problem to a manageable level. Other services can benefit from this type of use as well.

Second, the directory can serve as a network-accessible storage device for information about configuration, access control, user preferences and profiles, and other things. The value of the directory in this role is twofold:

  • If any of this information is to be shared across servers, the directory can act as a central repository, eliminating redundant administration much as it does for user and group information. Imagine the convenience of being able to change a shared configuration item on a hundred Web servers with a single change to the directory, as opposed to visiting each Web server and making the change redundantly or maintaining a separate, ad hoc system to manage configuration.

  • The directory can provide a standard, network-accessible way to administer all this information. This opens up a whole new set of possibilities for standardized management tools and common administration frameworks.

As a third example of its complementary nature, the directory can be used to help organize and access information contained in the Web server itself. Today, Web search engines exist to catalog and organize Web-based content. But as anyone who has spent much time using these services can attest, you often spend more time wading through irrelevant matches to your query than reading the actual information desired. The problem is simply that Web content lacks structure and, therefore, is hard to organize and search in an automated way. With the advent of XML (Extensible Markup Language), this lack of structure is beginning to change. This is where directories come in.

Directories are great at organizing and providing subsequent access to information. Imagine today's Web search engines driven by directories: Using the directory query language and typed information structure to more accurately specify the information you are looking for, the directory could return a much more focused set of results. Keep in mind that in this scenario the content itself is still stored in a Web server and that free-text searches would still be conducted as they are today. The directory's value is to provide some structure on top of this arrangement and also provide a precise, yet flexible, query mechanism.

Another good example of a directory complementing existing services is found in examining file systems and FTP servers. In this case a directory can be used not to hold the contents of files, but rather to hold meta-information about those files, their locations, who owns them, and other things that might be useful in locating them. Most importantly, the directory can hold the information that a file system or FTP client needs to access files contained in that service. An FTP server could also use a directory server for authentication purposes.

This idea of using directories to organize and search for information that you really want to access is a common theme. Directories often don't hold the content for which you are searching, but they can hold the location of that information along with other attributes that can help you find what you are looking for.

The dividing line between what should be held in a directory and what should be held elsewhere is not always clear. In fact, sometimes it can be quite difficult to tell. General guidelines are that the more information there is, the less likely it should be put in a directory. The more frequently the information changes, the less likely it should be maintained in a directory. The less structured a piece of information is, the less benefit you will likely derive from placing it in a directory. However, the more often a piece of information is shared, the more benefit you will likely derive from placing it in a directory.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

applications
          unsuited for directories 2nd 3rd 4th 5th 6th 7th 8th
comparing
          directories and databases
          directories and DNS (Domain Name System) 2nd
          directories and file systems 2nd
          directories and FTP (File Transfer Protocol)
          directories and WWW (World Wide Web) 2nd
complementary directories 2nd
          and FTP (File Transfer Protocol)
          and Web servers 2nd 3rd
databases
         directories
                    comparing
directories
          applications not suited for 2nd 3rd 4th 5th 6th 7th 8th
          complementary 2nd
          complementary directories and FTP (File Transfer Protocol)
          complementary directories and Web servers 2nd 3rd
         databases
                    comparing 2nd
         DNS (Domain Name System)
                    comparing 2nd
         file systems
                    comparing 2nd
         FTP (File Transfer Protocol)
                    comparing
         WWW (World Wide Web)
                    comparing
DNS
          (Domain Name System)
         directories
                    comparing 2nd
         IETF
                    (Internet Engineering Task Force)
Domain Name System, see DNS
file systems
         directories
                    comparing 2nd
File Transfer Protocol, see FTP
FTP
          (File Transfer Protocol)
          and directories (complementary)
         directories
                    comparing
IETF
          (Internet Engineering Task Force)
Internet Engineering Task Force, see IETF
languages
         markup
                    XML (Extensible Markup Language)
markup languages:XML
          (Extensible Markup Language)
protocols
         FTP
                    (File Transfer Protocol)
                    comparing with directories
servers
          and complementary directories 2nd 3rd
services
          and complementary directories 2nd
Web servers
          and directories (complementary) 2nd 3rd
World Wide Web, see WWW
WWW
          (World Wide Web)
         directories
                    comparing 2nd
XML
          (Extensible Markup Language)

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net