Child pages
  • Grouper integration with an ESB - background
Skip to end of metadata
Go to start of metadata

I've starting work on integrating Grouper with an ESB. This has come out of a real requirement at Cardiff University. I'll post details as I progress through from conception to implementation. For now, here is the direction I'm taking:

As announced, I'm just starting out on connecting Grouper to an ESB, and I thought it would be useful to outline my direction. This is mainly driven by a real requirement at Cardiff University.

What we already do at Cardiff

We have an instance of an ESB+extras (basically Mule + Drools + some custom connectors for LDAP and DSML, called the DRRE) which we use to manage data flows and out of Grouper.

The DRRE is notified of changes which occur in our Identity Management system (itself a combination of the DRRE and Novell DirXML) and it generates group membership requirements using Drools rulesets. These are transformed into operations which are applied to Grouper using the Grouper API (which is instantiated within the Identity Management system). We have event hooks registered with the API which means that changes made within Grouper are notified to the DRRE. It transforms these events into a simple XML format and sends them on to another instance of the DRRE, which applies the group membership to user objects in the Identity Management eDirectory tree.

As we expand the use of Grouper, the limitations of our current methods are becoming obvious. I need to address these, and would like to do so in a way that makes is potentially useful to the Grouper community.

What needs to be done

At the moment what we have a Cardiff is very domain specific and has a dependency on Mule, which is use at both the client and server and of every connection, only covers a limited number of events and (as it uses hooks) is limited to working within the API, and so instance of the API in use needs to include the hooks. Therefore the following needs to be done:

  1. Remove the dependency on Mule (not required at Cardiff, but would make it much more useful)
  2. Convert to using notifications, processed by the Grouper Daemon
  3. Develop a generic way of packaging events and sending them to an ESB for processing
  4. If possible, develop a generic way of receiving events from an ESB and
    processing them in Grouper (this is way more challenging than 3, and some
    functionality would inevitably be duplicated with the WS)
  5. Simplify as much as possible, off loading complexity onto the ESB where

The initial implementation will be for Cardiff University, and target Mule as the ESB. There's no reason why other ESBs shouldn't be supported as well. Any use cases that people can offer will be very useful, but I can't promise that functionality will be included to specifically address them. In my experience ESBs can be configured to do a range of things, so one scenario may see grouper notifying the ESB of a subject being added as a member of a group, the ESB notifying the person by Email, tweeting that it has done so, and updating an LDAP directory. Most of the workflow would therefore be handled by the (properly configured!) ESB.

  • No labels