Grouper Developers Forum

[Kathryn Huxtable <>]

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>