ando@sys-net.it wrote:

At this point, it sounds like that your contribution could be __entirely__ reworked into simply adding caching capabilities into the current {SASL} password scheme (implemented in servers/slapd/sasl.c), preserving the logics you're using right now. You'd probably need to define your own "cachedUserPassword" attribute to temporarily store the cached credentials, unless something like this:

userPassword: {SASL}user userPassword: {<hash>}<hashed password>

allows the {SASL} module to fetch the next value of the userPassowrd and treat it as the cached value. The rest would be adding some TTL mech, configurable via back-config, and that should be it.

Yet another option would be to allow per-entry caching, by defining a new {CACHED-SASL} scheme. This way, one could fine-grain decide whose credentials can be cached and whose can't, letting the two cases share most of the code. I'd allow {SASL} to be cached as well, in case the administrator just wants to allow all {SASL} auths to be cached.

For this purpose, it might be necessary to change the API of password scheme handling, so that it gets passed a pointer to the entire entry, read-only locked, so that attributes like the "cachedPwd" and the "cachedPwdTimestamp" can be fetched and used.

With respect to updating them, we might need to add some means to schedule internal modifications to be performed as soon as the entry lock is released. Thoughts?

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------