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: "Michael R. Gettes" <>
  • To: Kathryn Huxtable <>
  • Cc: Tom Barton <>, Grouper Dev <>,
  • Subject: Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior
  • Date: Mon, 11 Aug 2008 17:21:37 -0400

On Aug 11, 2008, at 17:05, Kathryn Huxtable wrote:

By putting eduPermission objects from different ldappc instances in different parts of the tree, you are asking to have them *not* be under the person object, as is now the default, correct? You would have an additional option that would specify a root under which to put them?

Well, to be honest, I never used the eduPermission objects. I am not
yet comfy with the idea of putting stuff under a person object.
And, to date, are there any real requirements driving eduPerm??
Is it a moot point? Given all this, maybe comments on eduPermission
are worthless. But I still believe in what I have said about
groups and such. I was just treating them the same and maybe
I shouldn't have.

Michael, I'm not sure that ldappc ever correctly handled multiple chefs cooking isMemberOf. It always deleted everything that it didn't provision. We need some sort of prefix scheme for these.

My testing from last year showed ldappc was doing the right stuff.
But, since you are now head chef for ldappc, I will follow your lead.
If it's broken - then I think it should be fixed.

Tom, I disagree with you about using different attributes for different ldappc instances. This cuts to one of CoManage's heart chambers. (CoManage has a two-chambered heart.) The isMemberOf attribute is well understood to contain group membership.




On Aug 11, 2008, at 2:55 PM, 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.


On Aug 11, 2008, at 15:32, Tom Barton wrote:

Upon reflection, I'm led to think that using prefixes or regexes is a hackish way to deal with the multiple cooks in one kitchen problem. The only way to really keep them from ruining each others' recipes is to put them in separate kitchens.

For provisioning group info we already have an easy way for sites to keep their several Ldappc instances separated: keep each in its own OU. The issue is how to do similar for provisioning membership info, isMemberOf style. The simple answer is "don't". Instead, use only one instance of Ldappc to maintain membership info, and don't use that instance to also maintain any group info.

And don't worry about performance of a single Ldappc instance covering a huge groups DB, since fairly soon there will be "Ldappc on hooks", which will provide asynchronous near real time provisioning.

Kathryn already pointed out that provisioning of signet-derived eduPersonEntitlement values isn't really a problem, and no one seems too concerned about this problem in connection with eduPermission objects as yet (and that can be solved by use of an OU-per-instance approach).

Have I convinced you guys that this problem is not a problem?


Michael R. Gettes wrote:
see comments below
On Aug 11, 2008, at 8:59, Kathryn Huxtable wrote:
Or "behaviour" if you are outside of the US. ;-)

Several people have indicated a desire for some way to provision data to an LDAP directory in such a way as to not interfere with data provisioned from some other source to the same attributes or branches. I think this is a reasonable request, especially in the case of attributes. I'm less convinced about branches, but the request has been made.

I think whatever we do should be backwards compatible for sites that don't need this functionality. I think we can achieve this.

I am open to any and all suggestions as to how to do this. I have some ideas below, but I'm not sold on anything. Your suggestions are welcome and requested.

Provisioning Attributes

As far as Signet goes, there is a prefix specified when provisioning a string to an attribute. Is it sufficient to require that the prefixes be unique, or should there be an additional attribute containing some sort of regular expression or something that specifies the scope for which Ldappc will manage values? That is, if an attribute value doesn't match the regular expression, Ldappc ignores it. (Or if it doesn't begin with the prefix, Ldappc ignores it, assuming we don't need the regular expression.)

Whatever we do for Signet, we could also do for Grouper in terms of provisioning memberships. We could allow a prefix or a regular expression defining the scope for which Ldappc will manage the attribute. Anything that either doesn't start with the prefix or that doesn't match the regular expression would be ignored. If we use the prefix technique, we would need to add the prefix to the beginning of all group names or UUIDs or whatever that are being provisioned to the attribute.

I wonder if a regular expression is general enough to cover all the possibilities. Personally, I would prefer to use a prefix and require that they be unique, but this may not work with what people are trying to do. We could allow multiple regular expressions to include and multiple regular expressions to exclude, I suppose. I can see my way to an XML syntax for this. It wouldn't be that awful.
i believe regex is overkill. i believe using prefixes to denote
which attribute value spaces should be managed will be sufficient.
you could also take this to the extreme by requiring this feature
to be configured which means multiple ldappc maintainers could all
use the same directory and would likely NOT have to coordinate since
they will all be minding their own namespaces. From a comanage
perspective, this would be desirable - I think.
Provisioning Objects in General

I see two ways of scoping objects, e.g. eduPermission objects and groups.

One is to add an attribute that specifies the scoping value. If the value (or attribute) isn't present, this isn't one of our objects and should be ignored.

The other is to modify the DN value by modifying one of the attributes in the RDN of the object, or in the case of bushy groups, possibly even the top-level branching.

It's possible that the regular expression method specified above for attribute provisioning can be made to work for provisioning objects as well.

Provisioning eduPermission Objects

I'm not at all sure how to disambiguate these if they are being provisioned by separate Ldappc instances or even separate systems. Specify a set of functions and/or subsystems to provision and anything else gets ignored? That's probably the most reasonable thing to do. From a CoManage standpoint, I think they'd like some Shibboleth-style scoping for the subsystem (at least) to handle provisioning multiple sites to the same LDAP directory. Or a new attribute could be added, possibly via a new object class, that specifies the scoping.

My preference here is for function/subsystem scoping, possibly with an option to add a prefix or suffix for institutional scoping for CoManage purposes.
In their own branch per ldappc instance... see below for

Provisioning Groups

If people must provision groups from multiple sources into the same branch, there must be a way of ignoring those groups that aren't being handled by a particular instance of Ldappc. Without loss of generality, we can ignore the difference between populating flat and bushy groups, I think. Since bushy group structure is dictated by the group name, and since our scoping rule might have something to do with the name, the usual tree decomposition rules would apply.

If we use the technique of adding a scoping attribute, we'll need either a new object class or to co-opt an existing attribute.

If we modify the CN of the group, we can do it at the group level or at the bush level by specifying a prefix.

As I said above, any and all suggestions are welcome.
my attitude on groups is similar to permissions only for attributes
like isMemberOf. Specify the value space.
As for objects in a portion of the DIT - this is where I believe it
should be one branch per ldappc instance (or something along those
lines). I don't see the value in having multiple ldappc instances
administering large numbers of groups in the same branch. From a
permissions perspective on the groups (limiting what apps can see
what group objects) this will be a nightmare. I think someone would
need to really convince us of this need, but frankly, I just don't
see it.



Archive powered by MHonArc 2.6.16.

Top of Page