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
To round out the solution, we should also process pwdModify exops as
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.
Symas Corporation - The LDAP Guys