On 03/30/2012 03:50 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_User_Gr... > > > > Scott > > In order not to tie conductor to LDAP for all installations, it > should be a site-wide configuration whether groups come from LDAP or > not. We'll need the conductor UserGroup/membership model anyway for > joins in permission queries, so this configuration will simply > determine how the group membership is maintained -- via LDAP hooks or > via UI actions. Is there any reason why we do not want to support both cases at the same time? Probably it would be a better user experience to let the user have both and indicate the source of a given group in the UI. If we define 2 different scopes on UserGroup (user_defined, ldap_imported), it won't be much pain to handle both of them.

> There are a couple of options available for keeping the UserGroups in > sync with LDAP groups: > * Use delayed_job, cron, or something similar to re-sync on a > specified schedule > * Sync on use (with a pre-defined "minimum time between re-sync calls") I would suggest a third approach: there could be some kind of auto re-sync mechanism, and the user would also have to option to request an update if he doesn't want to wait for the autoupdate to be called.

> The main advantages of sync-on-use are that 1) we make the minimum > number of re-sync calls that still guarantees the data is fresh and > 2) we don't require any external scheduling infrastructure. The main > disadvantage is that the first permissions check after an idle period > greater than the refresh interval (or one check per interval period > if the server is under active use) will take longer than usual to > return, as it has to wait for the LDAP group membership queries, any > necessary writes for data changes, and the permission denormalization > hooks for any changes to cascade down the object inheritance > hierarchy. If this takes a long time with large datasets (many > instances, images, users, etc), this will impact performance in a > user-visible way. To eliminate the downside of updating on user input, we could use delayed_job for that, too: instead of re-syncing with the ldap server during the request, we could just create a delayed_job task for that, inform the user that the background job has been created through a flash notice, and wait for the next available worker to pick up the task and do the autoupdate asynchronously. Imre

On 03/30/2012 09:50 AM, 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_User_Groups > > >Scott > OK I've updated to take into account feedback from Imre, Jan, Jay, and Angus. In particular, we'll allow both LDAP and Local groups to exist concurrently (subject to config flags, so we can still lock this down to only one type). I've added consideration of dynamic user group lists managed via LDAP queries, but in the 'future plans' section, as it will probably not be included in the initial iteration. In addition, I've noted that, subject to availability of a scheduling infrastructure, I'd prefer the background re-sync to inline/blocking re-sync. Scott

On 04/04/2012 02:07 PM, Jason Guiditta wrote: >On 04/04/12 13:54 -0400, Scott Seago wrote: >>On 03/30/2012 09:50 AM, 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_User_Groups >>> >>> >>> >>>Scott >>> >>OK I've updated to take into account feedback from Imre, Jan, Jay, >>and Angus. >> >>In particular, we'll allow both LDAP and Local groups to exist >>concurrently (subject to config flags, so we can still lock this >>down to only one type). I've added consideration of dynamic user >>group lists managed via LDAP queries, but in the 'future plans' >>section, as it will probably not be included in the initial >>iteration. >> >>In addition, I've noted that, subject to availability of a >>scheduling infrastructure, I'd prefer the background re-sync to >>inline/blocking re-sync. >> >>Scott >> > >Scott, couple minor questions/thoughts here: > >* what happens if an ldap usergroup is deleted on a sync (and I > would assume all permissions for a given user that was in that group > on any objects they own as well), but nobody else owns those > objects? For example, Joes group is deleted, and he has some > deployables he created, and a few running instances. Nobod else has > access to those objects, so what happens to them (especially the > running instances)? > So the result would be the same as would happen if an admin had manually removed the permission records. Taking LDAP out of the mix (since the same issue would happen with non-LDAP groups) we could imagine two sorts of cases: 1) group exists and members are removed: As members are removed from a group, those former members lose access to resources they only had by virtue of group membership. What happens when an admin removes the last member of the group? The group still exists, its permission grants exist, but they don't actually grant any real users access anymore. 2) admin deletes a group: In this case, all of the permission records assigned to the group are removed. In both cases, we won't touch running instances -- why should we? That would be like destroying a car just because someone took away the driver's keys. In addition, recall that (unless someone revoked the permissions) the user who launched the instances will still have rights, as the user will be 'instance owner' and 'deployment owner' on the instances and deployments. Also, the admin will, as always, have access to the instances to reinstate permissions, etc.

>* This is probably out of scope, but I would hope we will include a > task(s) to make whatever controller changes are needed also provide > an api? > Yes, we should define the API here. We'll need API for creating/removing/altering groups, and (for local groups) adding/removing group members. General question here -- going forward, are "build out API" tasks going to be done across the board at some point? Also, do we assume that _every_ new feature we add from now on includes implementing the basic APIs for the main objects associated with that feature?

>Aside from this, I think you have captured all the bits we have >discussed, and looks like a pretty workable plan to me. > >-j

On 04/04/12 14:18 -0400, Scott Seago wrote: >On 04/04/2012 02:07 PM, Jason Guiditta wrote: >>On 04/04/12 13:54 -0400, Scott Seago wrote: >>>On 03/30/2012 09:50 AM, 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_User_Groups >>>> >>>> >>>> >>>>Scott >>>> >>>OK I've updated to take into account feedback from Imre, Jan, Jay, >>>and Angus. >>> >>>In particular, we'll allow both LDAP and Local groups to exist >>>concurrently (subject to config flags, so we can still lock this >>>down to only one type). I've added consideration of dynamic user >>>group lists managed via LDAP queries, but in the 'future plans' >>>section, as it will probably not be included in the initial >>>iteration. >>> >>>In addition, I've noted that, subject to availability of a >>>scheduling infrastructure, I'd prefer the background re-sync to >>>inline/blocking re-sync. >>> >>>Scott >>> >> >>Scott, couple minor questions/thoughts here: >> >>* what happens if an ldap usergroup is deleted on a sync (and I >> would assume all permissions for a given user that was in that >> group >> on any objects they own as well), but nobody else owns those >> objects? For example, Joes group is deleted, and he has some >> deployables he created, and a few running instances. Nobod else >> has >> access to those objects, so what happens to them (especially the >> running instances)? >> >So the result would be the same as would happen if an admin had >manually removed the permission records. Taking LDAP out of the mix >(since the same issue would happen with non-LDAP groups) we could >imagine two sorts of cases: > >1) group exists and members are removed: As members are removed from >a >group, those former members lose access to resources they only had >by >virtue of group membership. What happens when an admin removes the >last member of the group? The group still exists, its permission >grants exist, but they don't actually grant any real users access >anymore. >2) admin deletes a group: In this case, all of the permission >records >assigned to the group are removed. > >In both cases, we won't touch running instances -- why should we? >That >would be like destroying a car just because someone took away the >driver's keys. > >In addition, recall that (unless someone revoked the permissions) >the >user who launched the instances will still have rights, as the user >will be 'instance owner' and 'deployment owner' on the instances and >deployments. Also, the admin will, as always, have access to the >instances to reinstate permissions, etc. Ok, thanks for the explanation. >>* This is probably out of scope, but I would hope we will include a >> task(s) to make whatever controller changes are needed also >> provide >> an api? >> >Yes, we should define the API here. We'll need API for >creating/removing/altering groups, and (for local groups) >adding/removing group members. > >General question here -- going forward, are "build out API" tasks >going to be done across the board at some point? Also, do we assume >that _every_ new feature we add from now on includes implementing >the >basic APIs for the main objects associated with that feature? > I would like for us to assume that any new feature that will get UI (and perhaps even some that dont) should have api built at the same time. If that means we need to add separate tasks and get more people working on the feature together, I think that is ok. And yes, I believe the intent is to really start to focus on building out api for everything we already have, the providers/accounts is just the first example.

>>Aside from this, I think you have captured all the bits we have >>discussed, and looks like a pretty workable plan to me. >> >>-j >

On 03/30/2012 09:50 AM, 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_User_Groups > > >Scott > Another couple rounds of revisions after discussion with Simo in #ipa. The doc is updated -- a brief summary of the changes follows inline here: Essentially we're dropping the notion of keeping the LDAP group membership lists in sync with a cached copy in our database. Instead, we'll pull a list of a user's LDAP groups at login (along with membership in any local non-LDAP groups) and store these in a list of ActiveMembership objects, each of which will track (User, Group, Session). For each permission check we'll add the ActiveMembership association into the existing permission query joins to pull in permission grants to groups that the user belongs to.