Grouper Users - Open Discussion List

[Martin Feller <>]

On 2/1/11 10:23 PM, Chris Hyzer wrote:
> Correct, and I think you might only need one membership view, but we can 
> discuss and if you need multiple that will work too...  depending on how 
> many groups/memberships and how often they change will affect how often you 
> can sync it.  If you need quick updates you might even be able to try every 
> minute and see how it goes :)  If you can deal with every 5 minutes, that 
> generate less load on the systems :)
> 
> If you are only syncing to Atlassian, then you might not need to worry too 
> much about privileges on groups since the Atlassian user will be reading 
> the data (I think).  If you want to maintain all the privileges, that is a 
> little more complicated with the loader, but might be doable, lets 
> discuss...  :)  Its easy if your privileges consist of a group, and that 
> group's members have that privilege.  But if you have multiple subjects 
> with a direct privilege, we would need a column of the view to make those 
> comma separated one col (maybe plsql could help if oracle or whatever other 
> language in mysql etc)...  we could also solve this problem with a small 
> croned java program to massage the data appropriately.
> 

We definitely need the privileges, because the data is supposed to be 
accessible to another tool
and not just by Atlassian tools, so we need authorization on Grouper level in 
place, I think.
I got updates in the meantime which indicate that the LDAP provisioning is a 
desired route.
And the group member names actually need to be changed during that 
provisioning process, using a user name mapping.
I guess we need to think it over here a bit.

Thanks for all the valuable input!

-Martin

> i.e. one view for memberships:
> 
> GROUP_NAME          SUBJECT_ID
> Folder1:groupA      subject1
> Folder1:groupA      subject2
> Fodler2:groupB      subject1      
> 
> Then a view for the group metadata (more cols possible, updaters, admins, 
> etc):
> GROUP_NAME      GROUP_DISPLAY_NAME       READERS
> Folder1:groupA  My folder:my group       folder3:myreaders,subject3
> Folder2:groupB  My folderB:my groupB     
> folder4:myreadersB,subject5,subject10
> 
> Thanks,
> Chris
> 
> 
> 
> -----Original Message-----
> From: Martin Feller 
> [mailto:]
>  
> Sent: Tuesday, February 01, 2011 8:55 PM
> To: Chris Hyzer
> Cc: 
> 
> Subject: Re: [grouper-users] ldappc for grouper v1.1
> 
> Chris,
> 
> Let's see if I understand this...
> You suggest creating one or more views (view as in sql view, virtual table) 
> that contains the the data of interest
> (stem names, group names, group memberships, group and stem privileges) 
> from the grouper v1.1 database, and use this
> view to periodically update the data in the grouper v1.6 instance?
> 
> I have to check how this fits into the rest of the picture here, but it 
> sounds like that may work.
> 
> Thanks!
> 
> Martin
> 
> On 2/1/11 5:32 PM, Chris Hyzer wrote:
>> Here's a solution using existing tools... :)
>>
>> Install Grouper 1.6 in a separate instance.  Setup one Grouper loader job 
>> that manages a group of groups based on a SQL view on 1.1 version (and 
>> whatever stem/groups you want if you want a subset of data, or all 
>> stems/groups).  This view needs to communicate the group name, and 
>> subjectID of member.  If you need help making that view I can help.  Then 
>> that will sync your Grouper with the 1.6 version.  You can run the cron 
>> loader job however often you want... maybe even every 5 minutes...  is 
>> that acceptable?
>>
>> Then you can use the latest ldappcng, or the Atlassian connector to WS, or 
>> whatever you want.  Plus that work investment will make it easier to 
>> upgrade when you eventually do since you will be getting used to the 
>> tools, using the interfaces, etc.
>>
>> Thoughts?  :)
>>
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Martin Feller
>> Sent: Tuesday, February 01, 2011 4:52 PM
>> To: Tom Zeller
>> Cc: 
>> 
>> Subject: Re: [grouper-users] ldappc for grouper v1.1
>>
>> On 2/1/11 3:37 PM, Tom Zeller wrote:
>>> Versions of ldappc prior to 1.5 have bugs which may be undesirable for 
>>> you.
>>>
>>> Is upgrading Grouper possible ?
>>
>> I once tried to drop in a newer version of grouper into GridGrouper, just 
>> to try it.
>> It didn't work (not even v1.2).
>> I can't imagine that GridGrouper will change to a newer version, because 
>> the cagrid
>> software stack (which contains GridGrouper) is changing at the moment.
>> So changing the version of grouper is, unfortunately, not an option for us 
>> right now.
>>
>>> Upgrading from 1.1 will require changes to your database.
>>
>> There is probably not something like a database conversion tool, which 
>> converts a grouper 1.1
>> database into a grouper 1.5 database or such, is there?
>>
>>>  For 1.6, Chris has an Atlassian connector :
>>>  https://spaces.internet2.edu/display/Grouper/Grouper+Atlassian+connector
>>>
>>
>> That sounds more elegant than the LDAP route, at least if the Atlassian 
>> tools
>> are the only ones consuming the grouper data. Yet again, version 1.1... :)
>>
>>> Documentation for "old" versions of ldappc are here :
>>>
>>>  https://wiki.internet2.edu/confluence/display/i2miCommon/Ldappc
>>
>> Thanks, I'll have a look.
>>
>>>
>>> It is probably possible to write an ldappcng plugin for Grouper version 
>>> 1.1.
>>
>> Yeah, let's see. I guess I need to try it out.
>> Seems like there is no easy route.
>>
>> Thanks for the input!
>>
>> -Martin
>>
>>>
>>> TomZ
>>>
>>> On Tue, Feb 1, 2011 at 3:27 PM, Martin Feller 
>>> <>
>>>  wrote:
>>>> Ok, I found this in the documentation archives for v1.1:
>>>>
>>>> "With the 1.0 release, Grouper includes an XML import and export tool 
>>>> that can be used for episodic or
>>>> periodic provisioning of group info to other contexts. The GrouperShell 
>>>> can likewise be used to load and
>>>> retrieve group information. But there is as yet no near-real-time 
>>>> "provisioning connector" that can update
>>>> LDAP directories or other run-time security infrastructure services. 
>>>> This is perhaps the leading need of the
>>>> Grouper Project at this time. But several early adopter universities 
>>>> have this need, and we expect to net
>>>> at least one provisioning connector or other run-time interface (eg, 
>>>> perhaps a web services interface) for
>>>> Grouper as a product of their efforts."
>>>>
>>>> That seems to tell me that the LDAPPC didn't exist in that version. Is 
>>>> that correct?
>>>> Does anybody see a way to get the data into LDAP with existing tools?
>>>>
>>>> Thanks!
>>>>
>>>> Martin
>>>>
>>>>
>>>> On 2/1/11 3:16 PM, Martin Feller wrote:
>>>>> Hi,
>>>>>
>>>>> We have grouper running under the hood of a GridGrouper service here. 
>>>>> The grouper version used by GridGrouper is 1.1.
>>>>> We try to provision the grouper data to LDAP so that it can be consumed 
>>>>> by crowd (Atlassian).
>>>>> Does the LDAP provisioning connector exist for that version of grouper, 
>>>>> or was it added later?
>>>>> If it exists, are there by chance still any doc pointers for that 
>>>>> version?
>>>>> Or can I use a later version of the LDAPPC (say 1.5+), or is there a 
>>>>> mismatch with the underlying grouper database schema?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Martin
>>>>
>>>>
>>
>