On 04/04/2012 03:32 PM, Hugh O. Brock wrote:
On Wed, Apr 04, 2012 at 03:27:32PM -0400, Jason Guiditta wrote:
> 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
You guys might want to check with someone in the IPA group to get a
sense of what standard practice is here, but I'm pretty sure caching
identity is a no-no.
--H
We're not talking about caching identity. We're talking about caching in
conductor what groups a user belongs to in ldap. If we don't do this,
things will get a lot more complex, since we have to handle both local
groups _and_ LDAP groups (since ldap is optional).
Scott