Making the Right Product Choice

Understanding and Deploying LDAP Directory Services > 20. Developing New Applications > Advice for LDAP Application Developers

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012002231181002103066187015

Advice for LDAP Application Developers

As with most kinds of applications, the process of developing an LDAP directory-enabled application is filled with many choices. By planning ahead a bit and thinking about how your application will interact with the directory service and other applications, you can save yourself a lot of grief . In this section, we present some advice to help you develop good LDAP applications. (Additional information on data- related design considerations can be found in Chapter 17, "Maintaining Data." )

Striving to Fit In

A common mistake for new LDAP application developers is to treat the directory as a private application-specific store. Although in some rare cases this might be a valid practice, the focus of most LDAP directories is on sharing information among applications, end users, and administrators. Also, keep in mind that the design of the directory may be altered in the future to meet the needs of other applications or to accommodate organizational changes.

You should design and write your application so that it assumes as little as possible about the directory design and can coexist with other applications ”including ones that have not yet been written. To accomplish this, follow these guidelines when designing and implementing your application:

  • Use standard schema elements whenever practical to promote interoperability and coexistence with other applications that do the same. Using standard schemas also helps ease directory service software upgrades.

  • When extending schemas, follow the procedures outlined in Chapter 7, "Schema Design." The best approach is to create auxiliary classes to hold attributes you need to add to existing objects such as persons, and to use an application- or organization-specific prefix when naming new attributes and object classes.

  • Avoid including mandatory attributes in the object classes you define. If another application includes that mandatory attribute as an optional one in a different object class, it will encounter an error when it tries to include its own object class in entries without including a value for the attribute that you made mandatory.

  • Assume as little as possible about the directory namespace, topology, replication, and security design. Also consider the kind of directory design changes that might affect your application; provide configuration settings or built-in intelligence to avoid problems resulting from these changes.

The challenge in developing an application that fits well with other applications and can survive directory design changes is knowing when it is okay to make assumptions. For example, it is probably unacceptable to assume much about how the people and group entries are arranged in the directory information tree (DIT). On the other hand, it is probably okay for your application to dictate the DIT structure within a portion of the directory namespace that it uses to store its own application-specific configuration information.

Tip

Make your application as configurable as possible with respect to how it uses the directory service. Do not hardwire knowledge of the DIT structure, access control rules, or other key parts of the directory design into your application. If you do not expect certain things to change, it is okay to make them somewhat difficult to reconfigure. However, it is important to ensure that there is some way to change the configuration without rewriting the application. Otherwise, you would need to modify the application and distribute new copies everywhere if a critical directory-related assumption you made ceased to hold true. Examples of techniques you can use to build a flexible application include using configuration files or templates for directory-related settings and writing your application so that it reads schema information from the directory service itself.



Communicating Your Application's Directory Needs

As part of your application design process, document how the application interacts with the directory service. Share this information with the people responsible for the design and deployment of the directory service. In many cases, deployment of a new application requires the directory design to be modified or software upgrades to be performed, both of which may be perfectly acceptable to directory administrators if known in advance.

It is important for everyone to be aware of any necessary changes as soon as possible so that the required planning and deployment tasks can be handled before your application is deployed. These are some of the things you should communicate to those responsible for running the directory:

  • Schema extensions required for your application.

  • Security and access control changes needed to support your application.

  • Privacy issues surrounding new data your application may introduce into the directory.

  • Additional directory management tasks required for your application. For example, it might make sense to extend certain existing administrative interfaces to support a new attribute used by your application.

  • Data source integration requirements for the application. For example, additional synchronization procedures may need to be set up to obtain certain entries and attribute values needed by your application.

  • Special LDAP protocol features you rely on. For example, you may be planning to use an LDAPv3 protocol extension that is new enough to require an upgrade of the directory server software. Sometimes your application needs such a feature to work at all; if possible, try to create a mode in which the application works, albeit less functionally, in the absence of the extension.

  • An estimate of the additional load the application will impose on the service. This is typically measured in terms of the number of LDAP operations performed in a given time period. Don't forget to estimate peak loads and consider each operation separately. For example, search operations are typically much less expensive for LDAP servers to perform than modify or add operations.

  • Server configuration changes required by your application, such as indexing of additional attributes.

Designing for Good Performance and Scalability

Actual performance and scalability requirements vary from application to application and site to site. It is true, however, that the use of computing services and networks is rapidly increasing in most organizations. To be safe, you should design your application to perform well and accommodate a much larger number of directory entries than are currently stored in your directory service. By considering performance and scalability of the directory-related aspects of your application up front, you may avoid a costly redesign later.

When designing and writing your application, avoid architectural choices that limit performance, require you to open a large number of connections to the directory service, or make it difficult to use performance-enhancing techniques such as caching. If your application uses LDAP heavily, you may want to implement a shared pool of connections to the directory service (see Figure 20.12).

Figure 20.12 LDAP connection pool architecture.

There are several advantages to having a shared pool of connections:

  • The pool provides a central place for caching of search, bind, and compare operations and for sharing results among threads within your application.

  • You can easily arrange to share one connection among several application threads, thereby reducing the number of simultaneous connections your application needs to make to the directory service.

  • The code to support robust features (such as automatic failover to an alternate server) can be implemented in one place in the connection pool.

Although you may not need something as complex as a shared connection pool, it is worth considering what kind of architecture will help your application use the directory service efficiently and perform well.

Tip

One danger in using any abstraction layer, including something like the LDAP connection pool just described, is that you typically sacrifice some fidelity and lose the ability to take full advantage of all the LDAP features provided by the LDAP SDK. For example, suppose you implement a connection pool that does not allow you to use arbitrary LDAPv3 controls; if you later find that your application would work better if it used an LDAPv3 extension that requires you to send a control to the server, you would need to redesign your abstraction layer. Plan ahead, and use abstraction layers only when there is a clear advantage in doing so.



All LDAP applications perform better if they avoid issuing extraneous operations and if they use simple operations as much as possible. By minimizing your application's impact on CPU, disk, memory, and other directory server resources, you improve the performance of all applications. When searching and reading entries, ask for only the attributes you need; do not retrieve all attributes from every entry. When modifying an entry, compare the new values with the ones already present in the entry and avoid sending unnecessary modify requests to the directory server. Use simple search filters whenever possible; for example, use an exact filter first, and then try a substring filter only if no entries are returned.

Avoid building into your application assumptions about the total number of entries or the shape of the directory tree (e.g., flat or deep). If you expect a lot of entries to sometimes be returned from a search operation, take advantage of the LDAPv3 virtual list view extension to build a scalable user interface and allow you to process the entries in manageable chunks . Think carefully before you create an application that relies on being able to find all the entries in the directory at once. If your application includes a user interface for selecting directory entries, make sure it supports a search-based interface instead of (or in addition to) a list-based interface. Using these techniques will help your application handle thousands of entries and scale up gracefully as the directory service itself scales up.

Developing a Prototype and Conducting a Pilot

One of the best ways to prove your design and try out alternatives is to develop a working prototype. The prototype does not have to be complete or have the prettiest interface. A prototype can be created using scripting tools or other rapid application development (RAD) techniques, even if you plan to use different development tools for building the final application. In order to learn from it, your prototype should work and interact with other systems (including the directory service) in the same way you expect the final version of your application to do so.

As soon as a working application exists, conduct a pilot test to solicit feedback and learn about any problems that should be fixed before you put the application into production service. The pilot should be done in an environment as similar as possible to the actual environment the application will be used in. Test your application's features, measure its performance, and solicit feedback from beta testers. Capture log files and other performance information and use them to conduct scaling tests to estimate the load your application will eventually place on the production directory service. Use the results of the pilot to improve your application, including how it interacts with the directory service. If you make substantial changes to your application after it is deployed, you may want to conduct another pilot.

Leveraging Existing Code

In many cases the applications you create will be similar to others for which the source code is readily available. Most SDKs come with sample code, and vendors such as Netscape and Microsoft make additional sample code available informally in newsgroups, in developer newsletters, and on developer CD-ROMs. The Internet at large is a great resource for locating complete directory-enabled applications; applications with freely available source code include LDAP-enabled mail transport agents (MTAs), several HTTP-to-LDAP gateways, and LDAP-enabled email clients .

Within your own organization you may want to create a Web site to publish LDAP-related source code so that it can be reused by anyone creating a new LDAP application. Code modules explicitly designed to be reusable should be distributed in binary form as shared libraries or Java class files. Over time, try to build up a large collection of code to serve as the starting point for new applications. You should, of course, ensure that any code promoted for reuse is of good quality and demonstrates appropriate use of the directory service.

Avoiding Common Mistakes

As when writing applications for any service that provides a lot of flexibility and functionality, the process of writing LDAP applications has some pitfalls. Many newcomers to LDAP application development make the same mistakes as those who came before them. Here are some common mistakes you should avoid:

  • Allowing abusive searches to get through to the directory service.   A search that consumes a lot of resources on a directory server is an abusive search . These include unindexed searches, searches that return a huge number of entries, and searches that read more information than needed for the task at hand. If your application provides an interface that end users interact with to create LDAP search filters, implement simple checks to avoid abusing the server. The kind of searches that are abusive might vary from one directory server implementation to another. For example, with Netscape Directory Server it is important to avoid substring filters that use fewer than three characters (e.g., cn=*hi* ), and you should ensure that at least one "ANDed" component of all search filters references an indexed attribute type. You can detect unindexed searches processed by Netscape Directory Server 4.0 by examining the server access log for lines that include notes=U . It may also be helpful to examine the access log for searches whose elapsed time ( etime ) is longer than a few seconds.

  • Not taking advantage of client-side size and time limits.   To prevent searches from taking too long and monopolizing the directory service, use reasonable size and time limits in your application. Using these limits also protects your application and your users from being frustrated by slow, unresponsive service.

  • Treating multiple values stored in one attribute as an ordered list.   In LDAP, the attribute values associated with each attribute type are a set of unordered values. Although many directory servers return the values for a given attribute type in the same order they're stored in, it is dangerous for an application to rely on this behavior. If you need a way to distinguish between two or more values for the same attribute, include something in the values themselves (such as a sequence number or other identifying text) to allow your application to tell the values apart.

  • Storing extremely large entries in the directory service.   Most directory server and SDK implementations are designed with relatively small entries in mind. There is no hard and fast rule for how big is too big, but entries bigger than 100K bytes in size are unusually large.

  • Improper handling of zero-length passwords   . If your application uses LDAP simple bind operations to test passwords to see if they are valid, make sure you check for zero-length or NULL passwords before passing them on to the directory server. LDAP servers return success responses for simple bind operations that contain a zero-length password and a syntactically valid DN, but the server does not grant to the connection the privileges associated with the bind DN. In other words, LDAP simple bind operations with zero-length passwords always appear to the application to succeed when, in fact, no checking of credentials or granting of privilege was done.

  • Improperly supporting LDAP referrals.   The most common mistake developers who use the LDAP C API make with respect to referral support is forgetting to install a rebind function. The rebind function is a callback function that is automatically called by the SDK library to obtain credentials to use when connecting to another server. Without a rebind function in place, all referred connections are anonymous. This causes errors or confusion when modifying the directory or when accessing attributes protected by access control. Another common referral-related mistake is not providing a way to disable automatic chasing of referrals. The ability to disable referrals is useful when troubleshooting directory problems or to improve performance in the face of unreachable servers.

  • Reading an entry right after it was modified and expecting to see recent changes.   It is common for there to be a short delay before changes made on a writable directory server are visible on a read-only replica (see Chapter 10, "Replication Design," for a discussion of the loosely consistent replication strategy employed by most directory services). If your application is connected to a read-only directory replica, searches sometimes return stale data. Try to design your application so that it doesn't need to immediately read information it just changed and, if appropriate, warn users to expect a short delay before directory changes are visible. If it is essential for your application to immediately see the changes it makes, configure it to locate a writable directory server that it can use to process reads as well as writes (of course, this diminishes the value of replication somewhat). Using a client-side cache to hide replication propagation delay is also an option, but if the contents of the cache are flushed (when a user quits and reloads your application, for example), old directory data may reappear and confuse the user.



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

Index terms contained in this section

abstraction layers
          application development
abusive searches
         allowing
                    application development mistakes
access controls
         applications
                    development needs
applications
         developing
                    common mistakes 2nd 3rd 4th 5th 6th 7th 8th
                    communicating needs 2nd 3rd
                    leveraging existing code 2nd
                    performance and scalability 2nd 3rd 4th 5th 6th 7th
                    pilots 2nd 3rd
                    versatility 2nd 3rd 4th 5th 6th
attributes
         mandatory
                    avoiding (application development)
communicating
         needs
                    application development 2nd 3rd
configurability
          application development
developing
         applications
                    common mistakes 2nd 3rd 4th 5th 6th 7th 8th
                    communicating needs 2nd 3rd
                    leveraging existing code 2nd
                    performance and scalability 2nd 3rd 4th 5th 6th 7th
                    pilots 2nd 3rd
                    versatility 2nd 3rd 4th 5th 6th
directories
         applications
                    developing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th
extending
         schema
                    application development
extensions
         schema
                    application development needs
extraneous operations
         avoiding
                    application development
leveraging
         applications
                    existing code 2nd
mandatory attributes
         avoiding
                    application development
mistakes
          application development
                    allowing abusive searches
                    improper zero-length password handling
                    missing client-side size and time limits
                    multiple value attribute storage as ordered lists
                    storing large entries
         applications
                    improper LDAP referral support
                    patience with entry updates
needs
         application development
                    communicating 2nd 3rd
password
         zero-length
                    improper handling
performance
          application development 2nd
                    abstraction layers
                    avoiding extraneous operations
                    numbers of entries
                    shared pool of connections 2nd
piloting
          applications 2nd 3rd
pool of connections
         shared
                    application development 2nd
privacy
          application development needs
prototypes
          application development 2nd 3rd
referrals
         improper support
                    application development
scalability
          application development 2nd
                    abstraction layers
                    avoiding extraneous operations
                    numbers of entries
                    shared pool of connections 2nd
schema
         application development
                    extending
                    versatility
         extensions
                    application development needs
searches
         abusive
                    application development mistakes
security
         applications
                    development needs
         privacy
                    application development needs
shared pool of connections
          application development 2nd
storage
         directory service
                    large entries
versatility
          developing applications
                    avoiding madatory attributes
                    configurability
                    extending schema
                    making assumption
                    using standard schema
zero-length passwords
          improper handling

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