Best Practices For LDAP Application Developers Follow the advice in this chapter to write effective, maintainable, high performance directory client applications.
Authenticate Correctly Unless your application performs only read operations, you should authenticate to the directory server. Some directory administrators require authentication even to read directory data. Once you authenticate (bind), directory servers like OpenDJ make authorization decisions based on your identity. With servers like OpenDJ that support proxied authorization, once authenticated your application can also request an operation on behalf of another identity, for example the identity of the end user. Your application therefore should have an account used to authenticate such as cn=My Killer App,ou=Apps,dc=example,dc=com. The directory administrator can then authorize appropriate access for your application, and also monitor your application's requests to help you troubleshoot problems if they arise. Your application can use simple, password-based authentication. When you opt for password-based authentication, also use Start TLS for example to avoid sending the password as clear text over the network. If you prefer to manage certificates rather than passwords, directory servers like OpenDJ can do client authentication as well.
Reuse Connections LDAP is a stateful protocol. You authenticate (bind), you do stuff, you unbind. The server maintains a context that lets it make authorization decisions concerning your requests. You should therefore reuse connections when possible. You can make multiple requests without having to set up a new connection and authenticate for every request. You can issue a request and get results asynchronously, while you issue another request. You can even share connections in a pool, avoiding the overhead of setting up and tearing down connections if you use them often.
Health Check Connections In a network built for HTTP applications, your long-lived LDAP connections can get cut by network equipment configured to treat idle and even just old connections as stale resources to reclaim. When you maintain a particularly long-lived connection such as a connection for a persistent search, periodically perform a health check to make sure nothing on the network quietly decided to drop your connection without notification. A health check might involve reading an attribute on a well-known entry in the directory.
Request Exactly What You Need All At Once By the time your application makes it to production, you should know what attributes you want, so request them explicitly and request all the attributes you need in the same search. For example, if all you need is mail and cn, then specify both attributes in your SearchRequest.
Use Specific LDAP Filters The difference between a general filter (mail=*@example.com) and a good, specific filter like (mail=user@example.com) can be huge numbers of entries and enormous amounts of processing time, both for the directory server that has to return search results, and also for your application that has to sort through the results. Many use cases can be handled with short, specific filters. As a rule, prefer equality filters over substring filters. Furthermore, always use & with ! to restrict the potential result set before returning all entries that do not match part of the filter. For example, (&(location=Oslo)(!(mail=birthday.girl@example.com))).
Make Modifications Specific TODO
Trust Result Codes TODO
Limit Dealings With Groups TODO
Read the DSE TODO
Use Resource-intensive Features Sparingly TODO
Avoid Hard-coding Certain Information TODO
Reuse Schemas Where Possible TODO
Handle Referrals TODO
Treat a Directory as a Directory TODO
Troubleshooting: Check Result Codes TODO
Troubleshooting: Check Server Log Files TODO
Troubleshooting: Inspect Network Packets TODO