Grouper Users - Open Discussion List

[Chris Hyzer <>]

If it were make or break to get privileges into the loader easier, I bet we 
could add an enhancement which is a column to the SQL and SQL-table jobs to 
accommodate that without too much problem... i.e.

GROUP_NAME          SUBJECT_ID     LIST
Folder1:groupA      subject1       member
Folder1:groupA      subject2       read
Fodler2:groupB      subject1       write

Not to confuse things, but the metadata query of group names could have 
designate which lists to manage so if any blank out we remove members...

Thanks,
Chris


-----Original Message-----
From: Martin Feller 
[mailto:]
 
Sent: Wednesday, February 02, 2011 2:20 PM
To: Chris Hyzer
Cc: 

Subject: Re: [grouper-users] ldappc for grouper v1.1

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