Skip to Content.
Sympa Menu

grouper-dev - cooking up attribute values

Subject: Grouper Developers Forum

List archive

cooking up attribute values


Chronological Thread 
  • From: Tom Barton <>
  • To: Grouper Dev <>
  • Cc:
  • Subject: cooking up attribute values
  • Date: Mon, 11 Aug 2008 14:34:50 -0500

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


begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technologies
email;internet:
title:Sr. Director for Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard




Archive powered by MHonArc 2.6.16.

Top of Page