Grouper Developers Forum

[Kathryn Huxtable <>]

Interesting thoughts, Tom.

I'm not entirely sold on your issues, but I'm willing to consider them
show stoppers if you do.

How about this:

We change Ldappc so that it can handle multiple instances of Grouper and
Signet in some mystical fashion. Then a single instance of ldappc can
handle all the provisioning for an attribute.

This still doesn't handle Graham Seaman's problem of externally
provisioned groups, i.e. groups or memberships provisioned outside of
Grouper.

I think that we're all on the same page with respect to provisioning of
groups. Multiple provisioning agents will provision to their own ou
values. (At KU we had ou=groups,dc=ku,dc=edu and under that
ou=grouper,ou=groups,dc=ku,dc=edu. Or something like that. My memory of
KU is fading.)

The problem also isn't necessarily with Signet provisioning since it
already has a prefix which it prepends to the permission string, and it
is documented as ignoring permissions in the attribute that don't match
that permission string.

Personally, I think that a regexp or just a stem limiter would be
sufficient to handle this.

I'm curious what Michael has to say.

-K

On Wed, 2008-08-13 at 14:42 -0500, 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>
> >>
> > 
>