Grouper Developers Forum

[Kathryn Huxtable <>]

Well, if you're not using ldappc then it doesn't much matter if we disallow extension.

And of course, none of this discussion applies to provisioning into LDAP groups. It only applies to provisioning into a membership attribute of a subject.

I don't use of extension or display extension can be justified under any sort of best practices in the membership attribute. In a bushy group, I don't think it's a problem.

Thanks for your comments,

-K, who has a lot of "in hindsight" thoughts about what I did at KU, myself.

On Aug 20, 2008, at 3:07 PM, Tom Zeller wrote:

First, we're not currently using ldappc (perhaps you can stop reading here), but I'd like to.

I'd like to retract my membership prefix objection and replace it with a very slight objection to colons.

I agree, an objection to colons is odd. We, also oddly, provision memberships using displayExtension, which suffers the same namespace collision issues as extension. I used displayExtension in provisioned memberships rather than name or uuid because folks here were accustomed to "All Students" and I didn't want to change it to "All:Students" or "memphis:All Students" or "edu.memphis:managed:All Students" etc. (In hindsight, I should have used group types to distinguish between groups whose memberships are managed by automatic versus manual processes instead of stems. We used OUs in ldap to logically differentiate groups and I originally thought stem correlated to an OU.)

Most of our groups are centrally managed, but some are managed by humans external to grouper. We keep our namespace unique by asking those human managers to prefix their groups, e.g. "Biology Students", using whitespace rather than a colon. Of course, whitespace doesn't scale ;)

We handle "scoping" by our group provisioner managing only the groups which it is authoritative for, and ignoring the rest (never replace, we bundle adds and deletes in one ldap operation).

So really, there is no objection after all, and probably it would be a good idea for Memphis to use names rather than displayExtensions in group memberships (and colons), but that might require significant re-working of consuming applications.

TomZ

On Wed, Aug 20, 2008 at 12:26 PM, Kathryn Huxtable <> wrote:

We had some productive discussion on the call today, and I thought I'd quickly summarize it and make a new proposal.

Tom B has previously stated his opposition to adding prefixes to groups in LDAP memberships because it changes the way the group is referenced in LDAP from how it is referenced in Grouper. Tom Z also had objections, but had not yet been able to elaborate them.

People had no objections to a regexp defining the scope of groups that would be managed by an Ldappc instance.

Gary suggested that Chris look into the possibility of adding a prefix to Grouper's configuration so that, if present, a prefix would be prepended to all UUIDs generated in Grouper. Chris thought this would be possible.

Gary also suggested adding a hook to the group selection mechanism to allow users with complex selections to add complex selection arguments. I will investigate this.

Gary also asked if anyone is actually provisioning extensions into LDAP memberships, since they're not guaranteed to be unique. We should probably eliminate this as an option and stick with name and UUID. I will ask about this on the list in a separate email.

There were a few other minor suggestions that don't affect the substance of anyone's argument.

So here's my proposal:

1) Add a scoping regex to the membership provisioning configuration in Ldappc. Any group in the attribute that doesn't match the regex will be ignored. If the regex is not specified then all groups will be processed.

2) Restrict provisioning options in Ldappc memberships to name and UUID.

3) Go ahead and add a prefix argument, but recommend against its use, preferring instead to...

4) Have Grouper add a UUID prefix argument to its configuration and use that to disambiguate UUIDs.

This would, I think, satisfy all use cases, and provide a best practices approach for new installations.

Any arguments? Suggestions?

-K

On Aug 20, 2008, at 10:57 AM, Kathryn Huxtable wrote:

Simplest suggestion to satisfy the issue:

Have two optional attributes for memberships:

1) a prefix that would be prepended to whatever was being populated into the isMemberOf attribute. If not specified, then nothing is prepended.

2) a regex that would specify the scoping for ldappc. Anything that doesn't match the regex is ignored. If not specified, then nothing is ignored.

This way, we don't alter the existing behavior for any installation that doesn't add these attributes.

This would be fairly easy to implement and would satisfy almost all of the use cases, except for questionable use cases.

-K

On Aug 20, 2008, at 7:12 AM, Tom Barton wrote:

Nice graphic, Gary. And just to remind folks, my last statement on that thread was

"It seems that a fairly easy thing to do that is helpful in some common circumstances is to enhance ldappc so that it recognizes a set of stems that it owns. If folks agree that's worthwhile, then the next step is for Kathryn to propose a way of so configuring it."

Have a great call, and please do dig into item #3 even though I'm absent.

Tom

GW Brown, Information Systems and Computing wrote:

I have attached an image which is my attempt to illustrate the context for issues around provisioning. It is likely to be very imperfect but I hope it will aid discussion.

<tbarton.vcf>