Grouper Developers Forum

["Michael R. Gettes" <>]

nuts... I meant to say below that maybe MY comments
on eduPermission are worthless!

/mrg

On Aug 11, 2008, at 17:21, Michael R. Gettes wrote:

> 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.
>
> +1
>
> /mrg
>
> > -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>