Grouper Developers Forum

[Tom Barton <>]

A month or two ago several of us discussed ways that ldappc could be 
made more efficient at provisioning groups and memberships, focusing on 
a scenario in which some program calling ldappc would have information 
about a narrow scope within which updated information was wished. For 
example, a UI that is used in the context of managing course information 
for a learning management system might be able to ask ldappc to update 
just the info related to a specific course.

While not a way to improve performance of mapping the entire groups 
registry into ldap, this approach could provide a way to speedily update 
specifically identified group information without consequence to other 
previously-provisioned group information. So it might be useful as an 
interim measure until incremental change notification is built into the 
grouper API.

The last word, to date, on this approach was supplied by Jeff VanEeuwen, 
one of the ldappc developers. That follows. So now Kathryn has one more 
of the prerequisites for her action item. :-)

Tom

--

Tom,

I've taken a look at the ldappc code and I believe this can be done. 
I'll sketch out the approach I'd take below.  Please note the following 
items.
1. My refreshed memory and a relatively quick review of the code may 
have caused me to miss some detail, but in general I think this approach 
practical.
2. There are items that need further clarification relative to a good 
implementation as the description below is relatively high level.
3. I reviewed the code I have locally on my PC as it doesn't appear that 
any code changes have occurred in CVS.
4. As always there maybe other approaches to this that are just as 
valid, or the suggested changes below might be made differently then 
described below (e.g., a different approach might be taken to modifying 
the configuration file xml structure).

ASSUMPTIONS:
1. An initial provisioning of both groups and memberships has occurred.
2. A new provisioning run is wanted with a modification of the 
group-queries, and that provisioning the selected groups and memberships 
is relative to a subset of the existing entries within the directory. 
In particular, only items in the subset of the existing entries within 
the directory are deleted if they are not selected during the second 
run.  Any entry outside of the selected subset remains unchanged.  Also 
note it is possible that new entries, not in the original set, maybe 
created in the directory as a result of this provisioning run.

3.  All other configuration information not identified in 2 above is the 
same for both provisioning runs.

GROUP PROVISIONING TASKS:
1.  A new configuration file element needs to be defined that allows the 
group provisioning process to identify the subset of existing directory 
stem and group entries to work against.  It appears that this new 
element ought to be a child of the <groups> element found in the 
<grouper> element.  This new element should hold a set of ldap queries 
relative to the group's root-dn for identifying the subset of existing 
stem and group elements to provision against.  Any entry not selected by 
the queries defined here would remain unchanged.

2.  Either modify or extend the 
ldappc.synchronize.GroupEntrySynchronizer to change how the populate() 
method functions.  (Note if this class is extended there are some other 
minor changes that will need to occur to utilize the new class)  This 
method currently initially populates the set of group and stem entries 
to be deleted based on selecting all of the existing entries under the 
root-dn.   The synchronization process then removes stem and group 
entries from the deletion list based on the selected groups being 
provisioned during the run. The populate() method should be modified to 
select only those stem and group entries identified by the ldap queries 
defined in the new configuration element in step 1.  It maybe sufficient 
to only identify group entries via these new ldap queries as only the 
stems entries above the group entries need to be considered.  Also when 
identifying stems to populate the initial stem deletion list, stems 
entries that contain group entries not selected by the ldap queries 
defined in step 1 are not to be included in the deletion list even if 
they are a parent entry to a selected group entry. By modifying the 
populate() method, any group or stem entry not initially selected will 
remain.

MEMBERSHIP PROVISIONING TASKS:
1.  A new configuration file element needs to be defined that allows the 
membership provisioning process to identify the subset of group names 
listed in the members-group-list's list-attribute found on the Subject's 
ldap entry.  This new element ought to be a child of the 
<member-groups-list> element found in the <memberships> element of the 
<grouper> element.  This new element should hold a collection of regular 
expressions to which the existing entries in the list-attribute would be 
compared. Those entries matching 1 or more of the regular expressions 
comprise the subset to provision against.  Any entry in the 
list-attribute not matching one of the regular expressions would remain.

2. Either extend or modify the existing 
ldappc.synchronize.AttributeModifier class to utilize a set of regular 
expressions when initializing itself with an attribute's current values. 
 In particular any current value not satisfying any of the regular 
expressions is retained, and those values satisfying one or more are 
eligible for deletion unless later identified as a desired value. 
Whether this class is modified or extended would depend on where and how 
it is currently being used.  I did not go into the details of this.

3. Modify the ldappc.synchronize.StringMembershipSynchronizer to use the 
new AttributeModifier class defined in step 2 and to pass the set of 
regular expressions from the new configuration element defined in step 1 
to the new AttributeModifier class.  Using the new AttributeModifier 
class along with the regular expressions when provisioning a subject's 
memberships will allow provisioning to occur relative to those entries 
identified by the regular expressions.

As always let me know if you have any questions.

Jeff

--- Begin Message ---

• From: Jeff Van Eeuwen <>
• To: Tom Barton <>
• Subject: Re: think I know the answer.....
• Date: Wed, 28 Nov 2007 14:47:58 -0600

Tom,

I think this is the e-mail you asking about.

Jeff

Jeff Van Eeuwen wrote:

Tom,

I've taken a look at the ldappc code and I believe this can be done. I'll sketch out the approach I'd take below. Please note the following items.
1. My refreshed memory and a relatively quick review of the code may have caused me to miss some detail, but in general I think this approach practical.
2. There are items that need further clarification relative to a good implementation as the description below is relatively high level.
3. I reviewed the code I have locally on my PC as it doesn't appear that any code changes have occurred in CVS.
4. As always there maybe other approaches to this that are just as valid, or the suggested changes below might be made differently then described below (e.g., a different approach might be taken to modifying the configuration file xml structure).

ASSUMPTIONS:
1. An initial provisioning of both groups and memberships has occurred.
2. A new provisioning run is wanted with a modification of the group-queries, and that provisioning the selected groups and memberships is relative to a subset of the existing entries within the directory. In particular, only items in the subset of the existing entries within the directory are deleted if they are not selected during the second run. Any entry outside of the selected subset remains unchanged. Also note it is possible that new entries, not in the original set, maybe created in the directory as a result of this provisioning run.

3. All other configuration information not identified in 2 above is the same for both provisioning runs.

GROUP PROVISIONING TASKS:
1. A new configuration file element needs to be defined that allows the group provisioning process to identify the subset of existing directory stem and group entries to work against. It appears that this new element ought to be a child of the <groups> element found in the <grouper> element. This new element should hold a set of ldap queries relative to the group's root-dn for identifying the subset of existing stem and group elements to provision against. Any entry not selected by the queries defined here would remain unchanged.

2. Either modify or extend the ldappc.synchronize.GroupEntrySynchronizer to change how the populate() method functions. (Note if this class is extended there are some other minor changes that will need to occur to utilize the new class) This method currently initially populates the set of group and stem entries to be deleted based on selecting all of the existing entries under the root-dn. The synchronization process then removes stem and group entries from the deletion list based on the selected groups being provisioned during the run. The populate() method should be modified to select only those stem and group entries identified by the ldap queries defined in the new configuration element in step 1. It maybe sufficient to only identify group entries via these new ldap queries as only the stems entries above the group entries need to be considered. Also when identifying stems to populate the initial stem deletion list, stems entries that contain group entries not selected by the ldap queries defined in step 1 are not to be included in the deletion list even if they are a parent entry to a selected group entry. By modifying the populate() method, any group or stem entry not initially selected will remain.

MEMBERSHIP PROVISIONING TASKS:
1. A new configuration file element needs to be defined that allows the membership provisioning process to identify the subset of group names listed in the members-group-list's list-attribute found on the Subject's ldap entry. This new element ought to be a child of the <member-groups-list> element found in the <memberships> element of the <grouper> element. This new element should hold a collection of regular expressions to which the existing entries in the list-attribute would be compared. Those entries matching 1 or more of the regular expressions comprise the subset to provision against. Any entry in the list-attribute not matching one of the regular expressions would remain.

2. Either extend or modify the existing ldappc.synchronize.AttributeModifier class to utilize a set of regular expressions when initializing itself with an attribute's current values. In particular any current value not satisfying any of the regular expressions is retained, and those values satisfying one or more are eligible for deletion unless later identified as a desired value. Whether this class is modified or extended would depend on where and how it is currently being used. I did not go into the details of this.

3. Modify the ldappc.synchronize.StringMembershipSynchronizer to use the new AttributeModifier class defined in step 2 and to pass the set of regular expressions from the new configuration element defined in step 1 to the new AttributeModifier class. Using the new AttributeModifier class along with the regular expressions when provisioning a subject's memberships will allow provisioning to occur relative to those entries identified by the regular expressions.


As always let me know if you have any questions.

Jeff


Tom Barton wrote:

You've restated it perfectly.

--- End Message ---