Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>,
  • Subject: Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior
  • Date: Wed, 13 Aug 2008 18:13:25 -0500
  • Organization:

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

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.


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>
> >>
> >

Archive powered by MHonArc 2.6.16.

Top of Page