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

Scott Seago sseago at redhat.com
Wed Apr 4 13:57:40 UTC 2012


On 04/04/2012 09:42 AM, Jan Provaznik wrote:
> On 04/03/2012 05:10 PM, Scott Seago wrote:
>> On 04/03/2012 08:08 AM, Jan Provaznik wrote:
>>> On 03/30/2012 03:52 PM, Scott Seago wrote:
>>>> Rather than paste in the entire text, I'm just linking to the wiki
>>>> writeup. Please read the whole thing first and if you want to
>>>> comment on anything specific, quote it and comment on this thread.
>>>>
>>>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_Permission_Grant_list_to_UserGroup_Profile_UI 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Scott
>>>
>>>
>>>> In "LDAP Groups" mode we won't pull in all user groups from the LDAP
>>>> server, as there may well be many groups that aren't related to
>>>> Conductor use, so we'll have an "Import LDAP User Group" action,
>>>> analogous to "Create User Group" action for standalone. This will
>>>> bring up a list of LDAP groups exposed by the LDAP server, allowing
>>>> the admin to choose one (or more? -- not sure if we'll allow
>>>> multiple groups at once yet) to import. The UserGroup will be created
>>>> in conductor, with the memberships pulled into Conductor at the same
>>>> time. Any group members that are not yet imported into the Conductor
>>>> database as Conductor users will be pulled in at the same time.
>>>>
>>>
>>> "Import LDAP User Group" action implies that an admin has to manually
>>> add a new group in conductor anytime the group is added on LDAP server?
>>> It would be nice to have both user and group lists configurable just by
>>> setting ldap query (in config file).
>>>
>> This is correct. I don't think we want to automatically pull in all LDAP
>> groups, since most of them will probably be not relevant for Conductor
>> purposes. We _could_ add a global "automatically import _every_ group
>> from LDAP" flag at some future point -- it wouldn't really affect much
>> of the design here, but we don't want that to be mandatory, so we still
>> need the 'import' feature.
>>
>
> Well, centralized user and group management is major benefit of using 
> LDAP. By enforcing an admin to add groups both in LDAP and in Aeolus 
> this benefit is lost.
>
> I didn't mean we import all groups - LDAP query is a powerful tool 
> equivalent to SQL and allows you to filter only groups which meet some 
> restrictions (e.g. "give me all groups which have an attribute 
> 'webapp' set to '1'"). Alternatively only a LDAP subtree can be used 
> to specify group subset.
>
> So the advantage would be that an admin sets proper LDAP query in 
> Aeolus config only once, then all users/group management can be done 
> outside Aeolus by a preferred tool.
>
> All of above are just brainstorming ideas, I don't have strong opinion 
> about this.
>
So it sounds like we potentially have 3 different ways to create/manage 
groups:
1) local groups: standard CRUD within Rails, as described in the doc
2) explicitly-added LDAP groups: admin picks a specific group to add 
from LDAP, as described in the wiki doc
3) LDAP query-managed group list: Admin defines an LDAP query that 
returns a list of groups, all of which should be "imported" into 
Conductor and maintained automatically.

So 3) would be something new (not yet defined in my wiki doc). It would 
be implemented as follows:

a) admin enters a query that returns a list of groups -- should this be 
done via the UI or via a config file?
b) groups have a "type" field: local, imported, and query-backed. For 
local groups, add/delete group _and_ add/remove from members list are 
supported. For imported, add/remove are supported, but membership is 
maintained via LDAP sync. For query-backed, add/remove group isn't 
supported either, as the group itself is also maintained via LDAP sync.
b) the LDAP re-sync code should be augmented to not just re-sync 
explicitly-imported groups but also query-imported groups. Essentially 
re-syncing is a two-step process now.
   1) re-sync the list of query-backed groups
   2) re-sync membership for query-backed and imported groups

I'm leaving users out of this for the moment, since this feature is only 
for managing groups, but if we decide to implement query-backed groups 
we could do something similar with users at some point as well.

So from a feature planning point if view, we now have 3 
requirements-related questions:

1) Should we allow LDAP-backed and local groups to exist concurrently? 
If we do this we'll enable them via separate config vars, so the 
sysadmin can still restrict to LDAP-only or local-only -- but we'd have 
the option of doing both
2) do we need LDAP query-backed groups in addition to explicit 
"imported" groups? This would be a third category to enable via config file
3) If we do 2) -- do we want a UI to add/remove group queries, or would 
doing this via config file be sufficient? In the latter case, would we 
need to allow multiple queries, or would one be fine?


>> You bring up another point -- we could possibly generate a custom query
>> to generate the group list. Again this would probably need to be in
>> addition to the manual import, and possibly not for the first version
>> here (unless there's a compelling need for it)
>>>> For sync-on-use, the idea is we would store a "last sync time" every
>>>> time we re-sync group memberships. Any time we make a permissions
>>>> check, the checking code would call a method on Group to refresh if
>>>> necessary (i.e. refresh if last refresh was longer ago than
>>>> $refresh-interval, otherwise return and do nothing).
>>>> Group.refresh_from_ldap_if_necessary would block while checking last
>>>> sync time and (if necessary) while performing the update using an
>>>> ActiveRecord pessimistic lock on the "last refresh time" data element
>>>> in order to prevent more than one web UI front end process (or
>>>> thread) from attempting to re-sync at the same time.
>>>>
>>>
>>> -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.
>>>
>>> We have other background tasks anyway, so there is not much additional
>>> work to do this on background.
>>>
>>> Jan
>> OK, yeah performance was my main concern with the sync-on-use. Jay was
>> more firmly of the opinion that the polling solution was less desirable,
>> but if slow LDAP server response is going to be a common occurance, I'd
>> prefer the background polling as well.
>>
>> Scott
>>
>




More information about the aeolus-devel mailing list