Grouper Developers Forum

["Michael R. Gettes" <>]

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