On a related note, any solution using pcache for disconnected operation should also be able to cache bind operations. This is a digest of a conversation I had with Howard about that:
Currently pcache always forwards binds to the db beneath it. These will fail in disconnected cases. One solution is to give the pcache identity read privs to the userpassword, but for security and design reasons that won't fly in most installations. Another solution is to add bind caching to pcache, and that is what is described below.
Bind caching functionality can be integrated with pcache, provided that we can meet some conditions:
1. Guarantee that the object being bound against is already in pcache when it passes the bind through.
2. Have an attribute in the cached object where pcache can store a hashed version (e.g. SSHA) of the password it got from the user and verified against the underlying database. Remember that we must verify it against the underlying db before we can write it to cache.
Most applications performing LDAP authentication will first search for the object to which they're intending to bind. This will cause condition (1) to be satisfied, but this is not good enough because it is not guaranteed that all applications will first search for the object to which they're binding- some applications build the bind DN 'blindly' using string substitution rules or even hard-coded bind DNs. This is wrong, but it's the way things are. Therefore, pcache itself should search for the object being being bound to and populate the cache with the search result. The details of how the object is added to the cache remain to be determined.
Satisfying (1) provides the opportunity to construct an proxyattrset that includes a (possibly dummy) attribute in which the hashed validated password can be stored, thus satisfying condition (2). The userPassword attribute can probably be used most of the time for this, since it will either be returned form the server either empty or with a value of '*'. The "do bind caching directive" might refer to a proxyattrset constructed for this purpose.
Bind caching will interact with TTR, but the details are as yet undetermined.
To round out the solution, we should also process pwdModify exops as follows:
For pwdModify exops, pcache would could operate as a 'write-through' cache, first making sure the object in the cache is current. If the write-through to the underlying database succeeds, then the object in the cache is also updated. Otherwise the exop fails and any cached copy is left unaltered.
-Matt
Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com