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: "Michael R. Gettes" <>, Grouper Dev <>, Signet <>
  • Subject: Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior
  • Date: Thu, 14 Aug 2008 09:17:16 -0500

My comments are included below.

On Aug 14, 2008, at 8:22 AM, Tom Barton wrote:

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.

I think decorations look nice... ;-)

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.

It depends on what the external groups look like.

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.

I *really* don't see a problem with decorating the UUIDs. This would be optional and would not affect existing Ldappc installations. It would solve a problem for those who need it.

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.

Chris has addressed the issues with regex. I have no strong opinions on the subject. I want to do what works.


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.


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.


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?




Archive powered by MHonArc 2.6.16.

Top of Page