On 04/04/12 15:18 -0400, Matt Wagner wrote:
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
Matt, these are excellent points. I was pretty much on board with
moving this to some tbd background process, but this makes me
seriously question that direction. Perhaps if a company cannot
maintain a performant ldap server, they should just choose the 'local
groups' option for conductor? Anecdotally, I use the rh ldap all the
time to auto-complete email addresses in mutt. I am at least one
state away from the closest office, and have never had any significant
wait on such calls.
-j