Subject: Grouper Users - Open Discussion List
- From: David Langenberg <>
- To: Scott Koranda <>
- Cc: grouper-users <>
- Subject: Re: [grouper-users] provisioning to Google Apps
- Date: Mon, 22 Jul 2013 14:55:15 -0600
On Mon, Jul 22, 2013 at 1:11 PM, Scott Koranda <> wrote:
I am working with Boston College to develop infrastructure to
enable them to provision course groups from their LDAP
directory to Google Apps. Rather than writing a once-off tool
to go directly from the directory server to Goolge Apps the
plan is to introduce Grouper to leverage the Grouper change
log as well as the ability to add enhanced management
capabilities for the course groups.
We expect to use the Grouper Loader to load the course group
memberships from the LDAP directory system of record to
To provision from Grouper to Google Apps we are considering
- building a custom PSP connector: Tom Zeller has reported on
the list that he has thought in some detail about the design
and started to write some code but it is not finished (and
shelved I presume).
Given that the Grouper team has recently signaled that the
PSP will not be evolved due to the lack of takeup for SPML
we think this is the least attractive path.
- building a custom Grouper change log consumer: the change
log consumer code would extend ChangeLogConsumerBase and
then leverage the Google Directory API Java client library.
If anybody has written such a change log consumer and can
share it we would be grateful to hear about it.
Given the current project scope we think this is the most
- building a custom Grouper change log consumer to provision
changes to a message bus/queue, and then write a custom
queue client against the Google Directory API to provision
into Google: this approach is much like the above one but
introduces the message bus/queue as a mediator rather than
provisioning into Google directly. The primary attraction of
this approach is that it provides extra flexibility to
introduce more clients later so that more that just Google
could be provisioned. The down side is introducing another
layer and making the infrastructure more complex.
Brown and the University of Washington appear to have taken
this approach. Are either able to share code?
There's already some ESB support https://spaces.internet2.edu/display/Grouper/Grouper+ESB+Connector. I'd recommend against this approach unless you plan to re-use the bus elsewhere in the architecture. Otherwise, you're just adding another component that can/will fail and additional overhead which will slow things down.
Are there other approaches we should consider?
Any thoughts about the relative ranking of the three
Other than the Google Apps throttling, are there other issues
people have run into and that we should consider?
The other thing I've noticed when pushing tons of changes into Google is the connections can be unstable, almost as if they just down servers at random. Furthermore, you really can't trust what google has to say about a provisioning status for about 24 hours. Most of the time it's accurate, but they definitely seem to be working on an eventually-consistent model. If you happen to crash & re-connect to a node that hasn't gotten all your updates your app will quickly get confused. What we eventually wound up doing is maintaining state on our end as to whether G returned a success code or not for the user. If we got success, we would just trust it & not re-verify that account for 24 hours. Now, they have deprecated the provisioning API and I have yet to try their new Directory API, so I hope that one behaves better.
Identity & Access Management
The University of Chicago
- [grouper-users] provisioning to Google Apps, Scott Koranda, 07/22/2013
Archive powered by MHonArc 2.6.16.