based on URN namespaces to make sure group names don't collide
main objective is large scale admin and delegation of a common store
many people have authority over many other people's information
all those different agencies can source a knowledge system based on a common service that many agencies can plug into
Grouper Plumbing
Grouper can list subjects which is an abstraction (how to integrate a thing with God knows what?)
Subject API with packaged JNDI and JDBC
Grouper ships with it's own presentation of subjects
Main point of integration, point it at your LDAP directory or SOA implementation etc.
Other points of integration can assign privileges
There is a loader that can load people's LDAP entries, a dynamic group based on attributes
Get information reflected from outside of Grouper for maintenance tasks
Web Services interface, 4 varieties, light and heavy, SOAP and RESTful (2x2 matrix)
WS for query and management
You must use subject interfaces, WS interfaces are popular for putting things into Grouper like hierarchies of class membership or department structures
LDAP provisioning connector, selects a variety of group information and tailors the way the information is handled
Current LDAP provisioning connector is being replaced with a faster solution for large implementations like 1 million + groups
New connector will have asynchronous notifications, subscribe to the Loader, coming in 1.5 in November
New connector starts out with the Shibboleth attribute resolver
Delivery mechanism based on SPML
Will enable Shib to look up information directly from Grouper (potentially)
From the app perspective, you want to gather information from the enterprise data store or you can put a Grouper client in your cron and make it available to your app in a legacy way.
User interface for admin.
Command line interface exposes 100% of the api
XML import and export plumbing, don't do this but it's possible and sometimes even handy
Current interface is not the one for general use but a new one is coming but for the most part you want users to set up the access from within the application that is consuming the Grouper services
Far more coming in the attribute space in the new version
Success Stories
National Cancer Institute, 80 Cancer research centres is federated and uses PKI, Grouper is the access management component.
Central group registry and most sites have their own, but it provides a way for you to link your app to their grid while maintaining access
U of Chicago uses it to solve ordinary use cases, over time you amass a new asset of who can access what, provides an alternative to creating application level access control
Brown and Duke both have large, mature deployments
Brown first ones to address a course management problem WRT the fact that the SIS doesn't provide a complete picture of TAs etc. Grouper fills that gap.
Dutch organization is providing access control to a variety of services for multiple government agencies
French team is using Grouper and uPortal to solve issues around there portal for many French schools. Create dynamic groups based upon LDAP attributes because doing so on the fly was too much load on LDAP. Async into Grouper from LDAP when attributes show up then pull the info from Grouper into uPortal.
University in the Czech Republic built a Grouper based extension to their Sun Identity Manager which they would like to contribute back.
Contributors
University of Washington
University of Pennsylvania
University of Chicago
Barriers to adoption
When people just say "I can just use LDAP"
Some operations in LDAP are too large or hurt something else.
Grouper born out of running out of gas in LDAP
Grouper allows delegation of administration
Grouper solves the referential integrity issues, because there are more than one way to model groups in LDAP
You could just use Grouper to manage your LDAP (cooked in Grouper, pushed to LDAP)