Grouper Developers Forum

[Kathryn Huxtable <>]

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?

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.

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.

-K

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.
>
> /mrg
>
> 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?
> >
> > Tom
> >
> > 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
> > > reasoning.
> > > > 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.
> > > /mrg
> > > > -K
> >
> >
> > <tbarton.vcf>