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

Scott Seago sseago at redhat.com
Wed Apr 4 20:04:04 UTC 2012


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




More information about the aeolus-devel mailing list