Grouper Developers Forum

[Tom Barton <>]

I think I've convinced myself that altering group identifiers as they 
appear in LDAP as a means to manage multiple LDAP provisioners, though 
effective for that purpose, is a bad idea, and I'll try to convince us 
of that too. There are still several means that do not alter group 
identifiers that might be worth exploring. I'll muse of this further below.

Why is it bad to alter group identifiers? One, their appearance in an 
application context (that gets them from LDAP) differs from their 
appearance in the group management context, making it harder to know 
what you're doing when you manage a group, or what group you should be 
relying on for access control, depending on your perspective. Two, group 
identifiers, whether they are modified or not, are recorded within 
application configs, databases, etc, in all of the places where they 
need to be in order to be of use. That's a legacy that's extremely 
difficult to change. Hence, any change to how you provision groups into 
LDAP can be quite disruptive to services, if it would result in a change 
to the LDAP appearance of the name of a group that's already in use.

So let's consider alternative approaches to the problem of keeping 
multiple provisioners from interfering with each other. And let's focus 
on the case of more than one provisioner managing the values of a common 
attribute - isMemberOf. Bear in mind that there are 3 kinds of group 
identifiers that might appear there: 'name', 'extension', and 'id'. The 
first is like a file's full pathname (stem1:stem2:...:extension). The 
second is just the last or local part of the group's name, and the third 
is a UUID (eg, b1d16056-6035-4cda-9ba7-961a14f9793b).

First, the name itself could be used, being hierarchical, but only if 
that's the type of identifier being provisioned, and if the site is 
implementing a bushy rather than a flat bunch of groups, and if their 
provisioning strategy aligns with the rationale for their naming 
hierarchy. Too many ifs. But which provisioner owns which isMemberOf 
values would be perfectly clear if each one "owned" a specified set of 
naming stems.

A set of regexes can also provide a clear definition of which set of 
values is owned by which provisioner. There remain some big ifs about 
how well that approach aligns with naming practices, flat or 
hierarchical, and a real possibility that if you screw up those regexes 
you'll omit to provision some groups and multiply provision others. And 
it doesn't work at all with UUIDs.

Another way is to, by one means or another, associate each group with 
the provisioner it is owned by, and, from one provisioning cycle to the 
next, keep track of the entire list of groups that each provisioner has 
put into LDAP. You need the entire list so that, in the next cycle, the 
provisioner knows which ones to delete from LDAP: those in the list that 
are no longer in the groups DB.

A simple way of doing this is to change ldappc so that each provisioner 
provisions group objects in addition to isMemberOf values, and to do so 
in its own OU. The groups in its OU are the provisioner's list, and 
ldappc could be modified to only delete isMemberOf values that 
correspond to groups it deletes from its own OU. But this practice might 
not be reasonable for some sites, and I only describe it to illustrate 
the point.

If the provisioner's list cannot be in LDAP, it most be somewhere else, 
 a provisioner specific DB or more tightly integrated within the groups 
DB...

I'll leave us there for now, to see if I've managed to bring us all 
along to this point. If so, those three dots above need to be further 
explored, if we think this is the right way to approach the problem.

Tom

Kathryn Huxtable wrote:
> And I agree with Michael on this. I don't necessarily think that a 
> "hacky" approach is all that problematic if it's a simple prefix string. 
> And not supplying a prefix would lead to the current behavior. -K
>
> On Aug 11, 2008, at 4:36 PM, Michael R. Gettes wrote:
>
> > Yes, multiple COmanage instances all pointing at the same
> > directory.  This is a useful scenario as I see it.
> >
> > /mrg
> >
> > On Aug 11, 2008, at 17:34, Tom Barton wrote:
> >
> > > Michael R. Gettes wrote:
> > > > Your reflection (view) is reasonable if you only consider
> > > > things like group or permission objects going into a directory
> > > > but if you think about my person entry having attributes also
> > > > showing membership or privilege then I think your position
> > > > fails - there is only one person object representing you
> > > > so how will you manage multiple chefs cooking YOU?!?!?!
> > > > LDAPPC in the past properly handled groups in my entry
> > > > with the handling of IsMemberOf but it failed on the
> > > > eduPersonEntitlement.  If this problem is fixed, then
> > > > I agree - as I noted in my response - the group and
> > > > permission objects should be in their own portion of
> > > > the tree - largely for reasons of access control at the
> > > > directory level.
> > >
> > > My advice is to not configure multiple ldappc instances to all handle 
> > > the same membership attribute (ie, using ldappc's "-memberships" 
> > > parameter). Can you think of a scenario in which it is required to do 
> > > so, ie, in which having a single ldappc instance provision all 
> > > -memberships does not meet needs?
> > >
> > > Tom
> > > <tbarton.vcf>

begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technologies
email;internet:
title:Sr. Director for Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard