University of Wisconsin - Madison Grouper Project Page

January, 2013

Grouper is one of the components that have been wired together to form what has been named "Manifest". Our Manifest service Release 1 (R1.0) was announced quietly last month. R1.0 enables staff and faculty to create a group, add members by NetId or email invitation, and then use the group to protect local web applications. Shib EntityId is entered and stored in Manifest so the system admins can configure shib on their web server to screen for the isMemberof attribute. The use case that drove the design and build of this functionality came from our Center for High Throughput Computing. They and about 20 others now are using Manifest. A custom user interface was built which exposes Grouper, over a dozen APIs, a new special populations database, Person Hub, and Shib attribute resolver, to campus users.
R1.1 will include the option to invite someone to a group who must obtain a NetID and provide the mechanism to do that within Manifest. In the case of CHTC, they will be able to invite a colleague outside of the University who will be able to authenticate via a new NetID and enjoy the benefits of group membership. This is expected February 28.

R2.0 technical design and work breakdown has come a long way since December. R2.0 will introduce campus services, such as library access, and entitlements for groups. Through the use of an underlying workflow, Group administrators will be able to petition that service(s) be provided. Onboarding of campus Services to Manifest is expected to carry on for a long time.

The project team, although small, has grown to become a high functioning group. There is lots of work to do and R2.0 will not be the end. Much more functionality is hoped for. We use jira and wiki tools a great deal to organize and illuminate work among team members.

August, 2012

It has been a busy year. We adopted a service name; it is Manifest. A system composed of Grouper, Person Hub, Special Populations, Shibboleth, and a User Interface have been designed and built. A simple use case has guided the project team and this use case is scheduled to join as a beta customer next week. Two more use cases will help the team move ahead with additional functionality. Work ahead includes designing and building a campus services registry, bulk load of person data into the system for when the invitation system will be too cumbersome, workflow for service providers and group mangers to enable groups to obtain services, and more.

December, 2011

Many design meetings were conducted. Within them we 1) articulated a Registration Flow for adding new people not already in our Person Hub, 2) developed some use cases, 3) identified some APIs between the components of our Group and Affiliation Management Services (GAMS), 4) adopted a set of modeled on documents from the University of Washington and the University of Chicago, and 5) drafted specifications for a new Special Populations repository for those who are not already known to the University. Next steps include defining a more comprehensive system design, mocking up some User Interfaces for the registration process, and playing with Grouper in a DEV environment.

November, 2011

The Groups and Affiliations Management Service project team is conducting architecture sessions. What are the components of the service and how do they relate to one another? Grouper has been selected as the center of the service.

September, 2011

A fifty-five page requirements document has just been completed. Now we are performing a check off exercise to see if Grouper will meet most of what campus leaders have set forth as their business needs. Stay tuned for results.