Determining and Prioritizing Application Needs

It is important to focus first on LDAP-enabled applications when pondering your directory needs because in most organizations one or possibly two important applications are the driving force behind the initial deployment of the directory service. If this is true in your organization, you can focus most of your energy on meeting the needs of these high-profile applications. If you succeed in deploying a directory service that makes these important applications look good, your coworkers, employees , and users will label the directory service a success as well.

Note that you should avoid creating a directory service that is so focused on the needs of a small number of applications that it must be heavily redesigned later to accommodate other applications that come online. As you work through the various stages of designing your directory, remember to consider the broader, long- term picture. As an example, consider the schema for your directory service, which, as you will learn in more detail in Chapter 8, Schema Design, determines what information you can place in your service. Choose general-purpose schemas over extremely specialized schemas whenever possible, so that you can accommodate more applications without changing the schema.

The directory- related needs of applications generally fall into one of these categories: data, performance, level of service, security, or priorities. These are described in the following sections.

Data

All directory-enabled applications access data stored in a directory service. For each application you plan to support, consider in general terms how it will use the directory and what data it requires to accomplish its mission.

Does the application need to store a lot of data? A directory service may have limited capacity for data or may simply slow down as the number of entries and attributes stored in the service increases . It is important to understand the data capacity needs of each application so that you can plan appropriately.

For example, a network printer location service may impose modest data scalability requirements; each printer entry will probably be small, and most organizations do not own millions of printers. In contrast, a calendar or scheduling application that creates an entry for every meeting and task that appears on users' calendars may need to store a dozen or more attributes with each entry ”creating literally millions of complex entries in the directory. Meeting the needs of a scheduling application may require partitioning entries among several servers to achieve the required level of performance.

How flexible is the application in terms of the schemas used in the directory? For example, a directory-enabled workflow system may require access to much information about people and their organizational roles and relationships. Such an application may also use the directory for its security needs, so the directory may also be required to store passwords, public key “based certificates, and access control information. Depending on how the workflow system is designed, it may be flexible or rigid about what schemas are used in the directory.

Does the application have any special data needs? For example, does it need to store unusual data types beyond the basics of character strings, phone numbers , and integers? Is the information used by the application so dynamic that it does not necessarily need to be written to persistent storage? Special data needs such as those implied by these questions may severely limit the choices of directory service software.

Performance

Most applications expect the directory service to meet certain standards for performance. Two aspects of directory performance are of special interest: latency and throughput. Latency refers to the elapsed time between when an application makes an LDAP request and when it receives a response. Typically, low latency is most important for applications that use the directory service as part of a larger task, or when an end user is waiting for a response. For example, telephone operators who handle directory assistance inquiries require fast response time from a directory because they cannot move on to another call until they receive a response and pass it on to the current caller.

Throughput refers to the total sustainable operation load that the directory can handle. It is possible for a directory service to have high latency (for example, each search takes 2 seconds to complete) and still have high throughput (for example, the server can process 1,500 searches every second). For applications that make heavy use of the directory, such as an e-mail delivery system, throughput is the most important performance metric. You will need to think about how much work each application expects to be able to accomplish in a given time period. Be sure to distinguish read throughput requirements from write throughput requirements.

Figure 6.2 shows an example of the throughput needs of a hypothetical e-mail delivery system. The bottom line is that the e-mail delivery application requires directory throughput of 133 searches per second in order to support the three message transfer agents (MTAs).

Figure 6.2. Throughput Needs of a Busy E-Mail Service

Getting a handle on how well your directory service must perform helps produce a good design and ultimately results in a production directory service that enables the applications to perform well. It is always good to avoid a situation in which your directory service becomes a bottleneck for an important application.

Level of Service

Level of service typically encompasses availability (percentage of time the service is up and running), robustness (that is, whether the directory data store is transactional and self-repairing), service monitoring, and disaster recovery procedures. If the application itself provides an experimental service that is not expected to be available at all times, it is acceptable to build the application on top of an experimental directory service. Much of the characterization of service level has to do with the expectations of the people who rely on a directory-enabled application. It is important to know what level of service each application expects so that you can design a service that meets this expectation.

Tip

Over time, your directory service will probably need to support a wide range of service levels, from experimental to production to mission-critical. Keep this in mind as you define needs, set requirements, and design the directory service. Sometimes it is difficult and expensive to raise the service level after a directory is deployed, so you need to make sure that the software and hardware you select can meet your future needs. For example, if you eventually need to support 24x7 access to your directory service, you need to choose LDAP server software and hardware that supports features such as online backup of the directory database.

Security

Think about the security requirements of your directory-enabled applications. Some application security requirements impose security requirements on your directory service as well. Consider these topics:

• Privacy requirements . How secret is the data that will be transferred between the application and the directory servers? Should encryption be used to protect the information? For information that needs protection, what strength of encryption is required?

• Authentication requirements . Are simple passwords sufficient? Should one-time passwords be used instead? Must public key “based certificates be used to authenticate applications and users? If so, must the certificates and keys be stored securely on smart cards?

• Access control requirements . Does the application need to be able to restrict access to directory information? What special needs does the application have?

• Auditing requirements . Must a log of all directory activity be maintained so that a security audit can be performed? How long must the activity log be kept?

These topics are covered in detail in Chapter 12, Privacy and Security Design.

Prioritizing Application Needs

The final step in examining any set of needs is to assign a set of priorities to each one. In principle this is a simple task, but if the applications that your directory service is expected to support have a wide range of conflicting needs, setting priorities can be a challenge. A good technique is to make several passes through all the needs.

In the first pass, just assign each application need to one of these three categories:

1. Must have for the application to function

2. Would help the application do its job better

3. Would be nice to have, but is not critical

For example, the capability to customize the directory may be absolutely required to support an inflexible application, so this requirement should be assigned to the first category. In contrast, high directory throughput may help a heavily directory-dependent application work well, but there is probably some room for negotiation on the performance requirements; therefore, this requirement should be assigned to the second category.

In the second pass, think about how important each application is and sort the needs within each category you assigned in the first pass. Because it is unlikely that you will be able to satisfy all the application requirements from the start, ordering the list of requirements is an important step that shows you where to focus your attention.

Finally, make one more pass to check your work. This time, just look at the needs in the bottom half of your ordered priorities list and make sure that none of them seem particularly important. If any do, move them up and reorder the list.