Grouper Developers Forum

["Michael R. Gettes" <>]

My belief is yes, but, it is not clear to me there is
enough information in group/priv mgmt systems to date
to solve this problem.  Several years ago (when I was
at Georgetown) after much discussion with Charlie Leonhardt
I came up with a language to specify data sources of
information and to map those sources into an output string
which could be used exactly as you consider below.  This
would allow for the automated cooking of attribute value
spaces (or group names and permissions or whatever else
you wanna dream up).  But, to do this, as I noted, you need
to have info about the original data element which I don't
see being stored by grouper/signet or other group/perm
system.  Now, if you wanna glob this onto the subjectAPI
to get info from the IdM system - then this becomes solvable
interesting to me!  Although, it is still not clear to me
all data from SOR will be reflected into an IdM - hence the
language I came up with which could draw data from many
different sources.  Does this help????

(i'll stop rambling now)

For the record, I am very pleased to see we are finally at
this level of thinking and discussion.  I have waited a few
years to get these kinds of consideration.

/mrg

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

> With the "ldappc provision scoping" problem polished off (:-), I  
> think that there is a different capability that has been requested  
> of Ldappc that might still be a real need. That's the ability to  
> "cook up" the value of some LDAP attribute based either on group  
> memberships or on permissions. For example, one can imagine wanting  
> to cook up a special eduPersonEntitlement value for all members of a  
> given group or all holders of a given permission. The cooked value  
> might be a fixed string, or there might be a whole hierarchy of  
> groups (or a subsystem's permissions, perhaps) to which some cooking  
> rule should be applied (transform the group's name or permission's  
> function as follows:..).
>
> Is this type of capability needed?
>
> 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>