Question

I would like to make a LDAP cache with the following goals

1. Decrease connection attempt to the ldap server

2. Read local cache if entry is exist and it is valid in the cache

3. Fetch from ldap if there is no such request before or the entry in the cache is invalid

Current i am using unboundid LDAP SDK to query LDAP and it works.

After doing some research, i found a persistent search example that may works. Updated entry in the ldap server will pass the entry to searchEntryReturned so that cache updating is possible.

https://code.google.com/p/ldap-sample-code/source/browse/trunk/src/main/java/samplecode/PersistentSearchExample.java

http://www.unboundid.com/products/ldapsdk/docs/javadoc/com/unboundid/ldap/sdk/AsyncSearchResultListener.html

But i am not sure how to do this since it is async or is there a better way to implement to cache ? Example and ideas is greatly welcomed.

Ldap server is Apache DS and it supports persistent search.

The program is a JSF2 application.

Answer 1

I believe that Apache DS supports the use of the content synchronization controls as defined in RFC 4533. These controls may be used to implement a kind of replication or data synchronization between systems, and caching is a somewhat common use of that. The UnboundID LDAP SDK supports these controls (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html). I’d recommend looking at those controls and the information contained in RFC 4533 to determine whether that might be more appropriate.

Another approach might be to see if Apache DS supports an LDAP changelog (e.g., in the format described in draft-good-ldap-changelog). This allows you to retrieve information about entries that have changed so that they can be updated in your local copy. By periodically polling the changelog to look for new changes, you can consume information about changes at your own pace (including those which might have been made while your application was offline).

Although persistent search may work in your case, there are a few issues that might make it problematic. The first is that you don’t get any control over the rate at which updated entries are sent to your client, and if the server can apply changes faster than the client can consume them, then this can overwhelm the client (which has been observed in a number of real-world cases). The second is that a persistent search will let you know what entries were updated, but not what changes were made to them. In the case of a cache, this may not have a huge impact because you’ll just replace your copy of the entire entry, but it’s less desirable in other cases. Another big problem is that a persistent search will only return information about entries updated while the search was active. If your client is shut down or the connection becomes invalid for some reason, then there’s no easy way to get information about any changes while the client was in that state.

Client-side caching is generally a bad thing, for many reasons. It can serve stale data to applications, which has the potential to cause incorrect behavior or in some cases pose a security risk, and it’s absolutely a huge security risk if you’re using it for authentication. It could also pose a security risk if not all of the clients have the same level of access to the data contained in the cache. Further, implementing a cache for each client application isn’t a scalable solution, and if you were to try to share a cache across multiple applications, then you might as well just make it a full directory server instance. It’s much better to use a server that can simply handle the desired load without the need for any additional caching.