Grouper Developers Forum

[Tom Barton <>]

Michael R. Gettes wrote:
> Tom - ok, I have read this a few times now, with a pause of a couple of 
> hours
> in between, pondering as I go.  I don't buy (or fully appreciate) your
> argument that managing by use of group identifiers is a bad idea.

My point was that we shouldn't *decorate* group identifiers in LDAP to 
manage multiple provisioners. We can certainly *use* group identifiers 
to manage the problem.

> So, in short, help me understand why assigning each ldappc instance
> it's own stem(s) to manage is a bad idea?  

Assigning each ldappc instance its own stems is a perfectly fine idea, 
and is the first alternative I wrote about. It's just that this aproach 
doesn't work if your group space is flat or if you're provisioning group 
UUIDs or group extensions rather than group names into isMemberOf. It'll 
work for multiple COmanages but not for LSE.

Likewise, regexes will not help LSE.

> My sense is the bookkeeper
> DB is over-engineering the prefix solution.  I am not appreciating why
> we need a complex solution to this problem?  We can always dream
> up reasons to make things more complex later - why do we have to
> do it now?  Shouldn't practical experience dictate whether or not we
> need more complex solutions?

If we want to continue supporting the provisioning of group UUIDs into a 
membership attribute, then either precisely one provisioner must own the 
entire value space, or some bookkeeper DB is needed.

In concrete terms, either LSE's current approach is SOL or we do 
something about bookkeeping (and maybe SOL is the right answer - sorry 
Graham!).

> And, as I have already noted, I do believe ldappc should be managing
> group objects in addition to isMemberOf in its own portion of the DIT but
> for use as group objects - not as a bookkeeping function.  I agree with
> the idea - but, maybe not your reasoning for it.

We agree - I mentioned it only to illustrate the bookkeeper approach.

> Sorry if I am being thick-headed in not appreciating your argument.
>
> And, KH, I see you still like the idea of regex and I believe that is
> overkill as well - why do we need it?  When I consider the many
> hundreds of thousands of operations we are considering for reasonable
> sized enterprise deployments - regex processing starts to mount up
> when you profile the code.  Of course, I should be basing my concern
> on facts and they are obviously absent, I apologize.  But, from my
> own experiences, regex processing *can* be expensive when done
> way too often - and I think this would be one of those cases.
>
> /mrg
>
> On Aug 13, 2008, at 3:42 PM, Tom Barton wrote:
>
> > 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>
> >
> > <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