Where is Grouper?
Grouper is an I2-sponsored project for managing groups. Check out the Grouper home page. Those interested may also want to join the Grouper mailing lists. The Grouper project is already aware of JA-SIG interest and is welcome (and encouraged!) to participate in the care and feeding of this WIKI section.
What is it?
(My initial take.) Grouper is an open source central group management facility. Grouper maintains a registry of groups and group memberships. The registry is loaded from sources of group information by loaders, presumably in periodic batch processes. Deep memberships (in Grouper, effective memberships) are computed at load time rather than at run time. Client applications can retrieve groups and memberships from Grouper with provisioning connectors. Authorization to perform group functions is handled internally by Grouper, rather than by a separate authorization system.
What are the functional differences?
Grouper is currently (6/20/05) in phase 1 of implementation, so there will be some time elapsed before the Grouper plan comes to a rich state of completion. Mostly notably missing at this point are
- Support for more than 2 (HSQL and Oracle) RDMB platforms
- Support for intersections, unions, etc.
- A lack of longer-term use to discover performance issues and ongoing maintenance efficiencies that might be gained
- There is also no grouper UI yet, but I think most of us are used to handling group management via command line at this point
See Comparing the uPortal Groups Service and Grouper for a further comparison.
Grouper-GAP Collaboration
A minimalist appoach
We could write a provisioning connector, i.e., a group store, that adapts the Grouper registry to the GAP groups design, thus making GAP a client of Grouper. This would probably be similar to PAGS with JIT LDAP support.
A deeper approach
As Grouper matures, consider using it instead of the GAP groups design. This would require at least the following changes:
- uPortal groups switch to a slightly different group name format. Instead of <group service>.<group id> we would follow Grouper heirarchy and naming conventions. This could be handled directly or via an interface for those in the process of conversion. Legacy channels are also reliant on the uP group naming conventions, so they would need an update if the portal code didn't act as a filter. To do so would require a uP -> Grouper mapping. I wonder if this would be a problem across other kinds of applications that use groups (eg. Confluence and JIRA) so that a grouper-provided mapping facility might be useful?
- How to handle expected, uPortal specific groups (i.e. portal administrators)? If Grouper was the centralized groups service for a campus, then it means that either uPortal would need to have the groups on which it relies extracted from code and specified in some parameterized way, or uPortal would need to create groups via the Grouper API upon installation.
- A loader to move uPortal groups from the uP data store into grouper would be very useful