RFC Feature Planning: Add Permission Grant list to User Profile and UserGroup details

Jason Guiditta jguiditt at redhat.com
Wed Apr 4 19:27:32 UTC 2012


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



More information about the aeolus-devel mailing list