University of Wisconsin - Madison, Grouper Project Page (Manifest)

A couple new community contributions have been added detailing a few of our use cases with Manifest/Grouper. You can view them here:

UW-Madison VPN Usage Approval via Manifest (Grouper)

UW-Madison Group Membership Delivery to Shibboleth

We will be working soon to update the Group Naming Standards document.

Manifest Version 3.0 has been deployed for almost two years now. We recently restarted development to fix bugs discovered over the last two years and improve on processes. Usage is quite a bit higher than when it was last reported at IAM Online in 2013:

memberships:           18,175,651
groups:                24,180
members:               576,919
folders:               429

Note that 19,937 of the groups are automatically created data-driven groups off institutional data such as student enrollment status and employment data. At this time, we do not have any data driven groups created for class rosters though that has been a highly requested feature.

Here are some examples of how Manifest has been used on campus:

• Controlling Office 365 license assignments based on campus populations
• Defining populations that should appear in a data view delivered to campus partners.
• Controlling access to various websites and applications via Shibboleth delivery of the "isMemberOf" attribute.
• Identity invitation system for UW affiliates and collaborators. (Note that other than memberships and controlling which groups can and cannot create identities, this tool relies very little on the underlying Grouper infrastructure)
• Defining populations for who is eligible for various services.
• Defining populations for different AWS account numbers and restricting who can access the AWS management console for that account number. The final delivery to AWS is done via shibboleth using the group information.

Coming soon to this page: architectural diagrams of how Grouper fits in to Manifest as a whole.

October, 2014

R3.0 was moved to production on October 7. This release was a major overhaul of the underlying code base (.NET) that greatly increases the speed of web service calls and the movement of large data chunks through the system. And a lot of attention was given to the user experience so that a novice could more readily figure out what to do first, and user navigation was improved. Some new features in the UI include:

-send group membership to Campus Active Directory
-make your group private
-visible start and end membership dates
-opt in and opt out of group membership
-granular permissions of members within a group
-mark your group as protecting sensitive data

There are over 100 items in our product backlog. So there is still much to do!

December, 2013

Manifest R2.0.1 will be moved to production on January 7. It is a minor release that includes some features requested by our Office 365 migration team.

The project team is working on a major release, R3.0, planned for spring 2014. This will deliver a dramatic improvement in feature set as well as user experience. The new Grouper UI has helped a lot by confirming or inspiring our own.

Moving business rules and logic from back-office queries and feeds into Manifest where they are exposed to decision makers will make service entitlements more effective and efficient over time. Service owners will be able to see more precisely who is receiving their service. It will be another year of tedious conversion work before all campus enterprise services are made available in Manifest.

May, 2013

Manifest Release 2.0 to be announced within 3 weeks. This release brings campus enterprise services into Manifest, where group owners will be able to request membership in Service groups. At first only a small number of campus services will be available via Manifest. Over the summer we'll add to the list of services. And we'll work on how to send group membership to service providers at their point of sale. Also in R2.0 will be data driven groups, those very large populations, such as all students or all employees. Users of Manifest will be able to work with those groups within the User Interface.

March, 2013

Manifest Release 1.1 was announced on March 5. It enables a group owner to invite by email someone to join the group who does not have a campus credential. The invitee can obtain a NetID by accepting the invitation to join the group while entering some basic information within the NetID activation page. Groups need to be approved to do this by the NetID service steward. (Noted in December 2013-This feature has become quite popular.)

The focus of design and development now is toward R2.0 which is being driven by two use cases. They are SROP and Cooperating Teachers. SROP (Summer research Opportunity Program) brings to campus students from other colleges and universities for a few weeks of specialized coursework. These students receive campus services such as library privileges and housing access. Cooperating Teachers help the School of Education provide practical teaching experience to our students. Cooperating teachers work at high schools in the vicinity and are offered some campus services such as access to the Student Union.
Workflow (jpeg).

January, 2013

Grouper is one of the components that have been wired together to build 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. Lots of people are waiting for this release.

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. We use jira and wiki tools a great deal to organize and illuminate work among team members. There is lots of work to do and R2.0 will not be the end. Much more functionality is hoped for. One of the anticipated features of Manifest beyond R2.0 is provisioning data driven groups that are sourced in Person Hub into directories. A hot one is the new Office365 / AD initiative. Manifest is expected to feed group information into these new applications.

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.