Grouper Users - Open Discussion List

[David Langenberg <>]

On Mon, Jul 22, 2013 at 1:11 PM, Scott Koranda <> wrote:

Hello,

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

To provision from Grouper to Google Apps we are considering
three options:

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

Agreed

 

- 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
   attractive path.

Agreed

 

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

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.

Dave

--
David Langenberg

Identity & Access Management

The University of Chicago