On Tue, Apr 03, 2012 at 02:08:53PM +0200, Jan Provaznik wrote:
-1 for this (+1 for doing this on background), I experienced many
situations when customer's LDAP server was responding too slow.
Typical real-life situation is: LDAP is used for SMTP auth, SMTP
server is overloaded -> LDAP responses are slow. IOW slow LDAP is
much more common then it would be expected.
I think I actually agree with Jan, but just to play devil's advocate...
I don't believe it's ever safe to cache LDAP data, because we have no
way of knowing when it changes. We could cache things for the duration
of a method call (like Rails does with SQL in controllers), but I think
anything beyond that is technically unsafe. And it's not like we're
concerned about possibly serving a blog post a couple of seconds after
it's deleted -- we're talking about caching security information with
having no way of knowing when what we've cached becomes out of date.
Continuing as devil's advocate for a moment, I would contend that if
someone's LDAP server is slow, it's not our fault, and is in fact
unavoidable, that our application will be slow during permission checks.
And building on the SMTP auth example -- this implies that the
mailserver is not caching LDAP information, because they deemed it
unacceptable for spam to go to a user once their account is turned off,
or for a new user to not receive mail for a few minutes. So surely, we
shouldn't allow user to spin up (or terminate!) cloud instances after
they were fired.
At a previous employer, the practice was to move employees who left the
company to the "Exited Users" Active Directory group, so even caching
group membership is unsafe.
Poking around a bit, I'm seeing other projects where their "cache" was
per-pageload -- along the lines of what I was saying with the Rails SQL
cache, which only lives as long as the controller action. The next
pageload will do the same queries.
I started this off mostly playing devil's advocate, and being a big fan
of caching. But in the course of doing so, I think I actually changed my
mind, and come to the opinion that we really shouldn't be caching user
authentication data. I think we need to re-query on every permission
check, even if this is going to slow things down considerably. In
practice this information changes relatively infrequently, but since we
have no way of knowing WHEN it changes, I think that caching it in our
database is unsafe and improper.
-- Matt