Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] RE: LDAP Loader with Composite Group

Subject: Grouper Developers Forum

List archive

[grouper-dev] RE: LDAP Loader with Composite Group


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Gagné Sébastien <>, "" <>
  • Subject: [grouper-dev] RE: LDAP Loader with Composite Group
  • Date: Tue, 26 Jun 2012 14:57:45 +0000
  • Accept-language: en-US

It would be nice if you didnt have multiple places to add/remove members.  You have 3 place right?  System of record, Grouper, and LDAP?

Yes, I think you could use membership attributes for this, though it would make syncing slower since those are more involved to process...  the Java API can do everything, so yes, it can manage membership attributes.

thanks,
Chris


From: Gagné Sébastien []
Sent: Tuesday, June 26, 2012 9:35 AM
To: Chris Hyzer;
Subject: RE: LDAP Loader with Composite Group

Here is a quick data sources diagram, I hope it help clear some questions.

 

The biggest problem now lies with ad-hoc members.

-          If I use the SQL Loader with a single group, all ad hoc modifications are lost with the next sync. Regular syncs are required because group inscriptions will change.

-          If I use a composite-include setup (MAT101 = MAT101_systemOfRecord UNION MAT101_includes)

o   There will be problems with the LDAP Loader

o   User might be confused with the use of the 3 groups (this task is delegated to the departments)

-          If I use a 2 groups approach where (MAT101 = ad hoc members and MAT101_systemOfRecord is a member of MAT101), it might work but

o   We’ll have to create 2 groups in AD (40 000 groups vs 20 000)

o   We could hide the systemOfRecord group from view in Grouper but some might see it in AD (not a big deal)

 

Another solution I thought of is to create a module that will use the Grouper Java API to create the Groups in the registry based on an SQL resultset. The benefits of this is that I will be able to transform the data before the group creation and I might be able to use only one group. My idea was that, instead of creating a separate systemOfRecord group, I would add an attribute systemOfRecord on every membership I create based on the academic’s database.

 

Would that approach work? Is it possible to get and set a membership attributes using the Java API?

 

Thanks

 

 

De : Chris Hyzer [mailto:]
Envoyé : 21 juin 2012 15:34
À : Gagné Sébastien;
Objet : RE: LDAP Loader with Composite Group

 

Any chance you can draw and send a picture/diagram of what you would like the setup to look like?  J

 

Thanks,

Chris

 

From: Gagné Sébastien
Sent: Thursday, June 21, 2012 3:31 PM
To: Chris Hyzer;
Subject: RE: LDAP Loader with Composite Group

 

It depends on which one you’re talking about ;-)

 

We would have 2 Loaders : one SQL Loader to get the system of record group and one LDAP Loader to bring back the changes made to the groups in AD (these include the overall groups and other “standard” groups without system of records)

 

Maybe the LDAP Loader should be configured to ignore these overall composite groups, but I thought it was worth mentioning this error.

 

 

De : Chris Hyzer []
Envoyé : 21 juin 2012 14:55
À : Gagné Sébastien;
Objet : RE: LDAP Loader with Composite Group

 

The loader needs to be configured to load the system of record group, not the overall, right?

 

Thanks,

Chris

 

 

From: Gagné Sébastien
Sent: Thursday, June 21, 2012 2:19 PM
To: Chris Hyzer;
Subject: RE: LDAP Loader with Composite Group

 

This happened with the Overall group.

 

I have : Composite = Part1 UNION Part2

 

The PSP sent the Composite to AD with members = member of part 1 UNION member of part2

 

The problem is when the LDAP Loader runs for AD, it tries to add the members of Part1 and Part2 back into the Composite.

 

We might not use this method, but I was testing some alternative and checking what is possible or not.

 

De : Chris Hyzer []
Envoyé : 21 juin 2012 14:11
À : Gagné Sébastien;
Objet : RE: LDAP Loader with Composite Group

 

Was the loader group on the overall group or the system of record group?

Btw, we are talking about UNION composite since the PSP will provision better than the overall group having as members the system of record (loader) group and the includes group.  If that wasn’t the case this has more overhead than just having members.

 

Anyways, if the loader is loading the system of record group then it should be fine since it is just a normal group.

 

Thanks,

Chris

 

From: On Behalf Of Gagné Sébastien
Sent: Thursday, June 21, 2012 1:46 PM
To:
Subject: [grouper-dev] LDAP Loader with Composite Group

 

I’m testing the LDAP with Composite Groups and found something that might be a problem

 

I made a Union Composite Group called udem:CompositeInclude2; It has 4 indirect/effective members as a result of the Union of two groups.

 

The PSP was able to provision the group with the effective memberships, meaning that the AD group has the 4 subject as member, not the 2 composite group. This is what I expected and wanted.

 

The problem come when I turn the LDAP Loader On, I get 4 hibernate exceptions (1 for each member) : http://tinypaste.com/a6c4a9fb

 

It seems the Loader doesn’t properly manage composite groups, maybe it tries to Add a member when it’s not allowed to on this type of object. Is that kind of use case supported with grouper ? What should happen if a member is removed from AD ? Should the component of the composite be modified the reflect the change (i.e. remove the member from the group) ? Delete might be doable, but how would you manage a “add member” for a Union composite ?

 

Deleting the Composite in Grouper resulted in the loader creating a normal group based on the members in the Active Directory.

 

 

Sébastien Gagné,     | Analyste en informatique

514-343-6111 x33844  | Université de Montréal,

                     | Pavillon Roger-Gaudry, local X-100-11

 




Archive powered by MHonArc 2.6.16.

Top of Page