Grouper Developers Forum

["Cramton, James" <>]

Since Brown is running its own ldap provisioning software out of MACE
Grouper, I've been trying to keep an eye on the ldappc threads, but not
always succeeding. So my apologies go out to anyone who thinks I haven't
been paying full attention. Because I haven't been ;-)  

But I feel I should chime in here to outline how Brown approached
selectively provisioning ldap using our own ldap provisioning software
that is probably not too different from the current implementation of
ldappc.  We define a set of stems that we may provision. We can also
identify specific groups that we may provision. These controls are in
config files. However, you may note that I said "may provision." We also
assign Group Types and Attributes in MACE Grouper to exert the final say
over whether or not a group is provisioned.  So if stem foo is flagged
in the config file to be provisioned into ldap, the only groups that are
provisioned to LDAP are those in stem foo that have the Group Type
"LDAPVisible" set. Each time the provisioning script runs, we assign an
attribute within the LDAPVisible Group Type called "lastLDAPUpdate" that
looks like a date/time string.  This gives us the key ability to allow
an end user to click a checkbox in MG to cause a just-created group to
be provisioned into ldap.  

A use case for this would involve a long and complicated group
definition that takes an hour to create, and days to approve. This group
should not show up in LDAP until its definition and membership are
completely set up and reviewed. Once approved, however, an end user can
click the LDAPvisible checkbox in MG, and the repeating batch script
that provisions LDAP will pick it up the next time it runs. Also, the
script (our ldappc equivalent) will not pick up any "helper groups" that
help define a provisioned group--for example, we typically do group math
in MACE Grouper by creating an "All" group, made up of an "Includes"
group <complement> an "Excludes" group.  Only the "All" group should go
to LDAP, so only it has the LDAPVisible groupType defined.

We use a similar methodology to indicate groups that are provisioned
from a feed, although these flags are not intended to be used
interactively.

See these url below for screenshots of what this looks like in MG:

         https://wiki.brown.edu/confluence/x/QYUwAQ





James Cramton
Lead Programmer/Analyst
Brown University

mobile: 401 345 9795




-----Original Message-----
From: Kathryn Huxtable 
[mailto:]
 
Sent: Wednesday, August 20, 2008 1:26 PM
To: Kathryn Huxtable
Cc: 

Subject: Re: [grouper-dev] Grouper design call, Wednesday, 20 August
2008, 1200EDT (1600Z)

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>
>