Executive summary

The University of Michigan wanted to explore the use of Grouper to possibly replace its manually driven email group management infrastructure with an enterprise-level system designed for access control and for rules-based groups.

TIER feature supported

Grouper 2.3.0 UI, API

Collaborators

University of Michigan:

• Information Technology Services Identity and Access Management team
• Information Technology Services Containerization Services
• Department of Business and Finance

Subject Matter Experts:

• Shilen Patel (Duke University)
• Chris Hyzer (University of Pennsylvania)
• Bill Thompson (Lafayette College)
• Erik Coleman (University of Illinois)

Internet2:

• Chris Hubing

Community resources

TIER CSP Grouper Cohort

TIER Grouper Deployment Guide

The environment

We ambitiously set out the following objectives for our Grouper project:

Technical:

• Install Grouper infrastructure within our development, quality assurance, and production application environments.
• Containerize the Grouper application.
• Explore using the Grouper application to provide a real group management system which would be a new service that would eliminate many scripts and manual steps.
• Optimize the processing of the Grouper product so that it performs as close to real-time as possible, similar to our current identity management system.
• Conduct a pilot to using Grouper to create and manage groups used for emergency alerts and notifications.

Educational:

• Learn how to best organize groups for an institution the size of the University of Michigan.
• Investigate data mining and exploration techniques to create Grouper loader configurations.
• Define general and specific scenarios in which Grouper can complement and supplement a commercial roles and access management s

The problem

The University of Michigan is a very large institution with 650,000 active accounts including students, employees, alumni, and sponsored affiliates. With a population of this size and diversity, the university requires a way to define and manage meaningful populations based on institutional data, for service provisioning, access management, and group email management.

Michigan currently relies on locally and vendor developed enterprise applications to handle provisioning and access management between the campus identity infrastructure and cloud providers (e.g. Google, box.com, Canvas, etc). This includes a custom group management system that departments and individual users rely on for email as well as local and enterprise access control.

Ideally, Michigan could replace these homegrown solutions with tools that are in broad use and have peer and/or vendor support.  

The solution

While trying to identify potential use cases, we found that there was considerable interest in using institutional data to define the groups used for access management. Numerous units have created their own solutions and are excited at possibility of using a centrally supported service.

Michigan experimented with a variety of technologies and configurations. Some were more successful than others. We attempted to deploy Grouper in containers using both OpenShift and AWS tools. This effort was complicated by a lack of an organization-wide containerization strategy and the need to develop expertise in the specific tools.

In addition to experimenting with deployment strategies, we decided to implement Grouper with a group of users that had complex selection logic. This represented a typical use case at Michigan. One of the challenges we faced was how to make the data coming from institutional data source useful for creating groups. The employee and student data comes PeopleSoft relational databases. In order to transform that data into LDAP, an attribute is created that contains multiple parts. For example, an employee can have several distinct appointments and there are data elements that are associated with each of these positions. In order to keep that relationship in the LDAP data, a single HR attribute is created for each job row in the PeopleSoft database. That attribute contains all the data elements associated with that job including things that could be used to create reference groups like department, job code, regular or temporary status etc. The challenge was to build something that could extract individual elements from the packed HR data in a format that Grouper could use.

The result

Implementing the desired solution required expertise in technologies with which our team has little experience and we lacked the time and resources to familiarize ourselves with the requisite components. Like many institutions in higher education, we are under pressure to deploy campus services using cloud-based providers. In this case, we set the bar too high and found it impossible to deploy a new piece of infrastructure using unfamiliar methodologies (all while under-resourced). Organizations as large and complex as Michigan require comprehensive strategies. Although we learned some valuable lessons, we are still developing our organization and team container strategy.

Large institutions collect significant amounts of data about their constituent populations, and it can be difficult to focus what is most relevant while faced with all of the possibilities. There is no “perfect” folder structure for an institution of our size. We went through several trial structures before deciding to focus on a typical use case

Lessons learned

Executive sponsorship and endorsement are essential in obtaining the appropriate resources to see a project to completion. Executive investment increases the likelihood that a project will be resourced appropriately and that the work will be prioritized. Projects like this are too big to complete on the margin.

Focusing on a specific use case really helps when dealing with new technology, a complex problem, and a tight timeline. Executive and customer interest in desirable use cases can provide momentum and motivation to the project team.

Grouper is a commonly used solution in higher education, but the differences in our chosen toolset hindered collaboration with the CSP cohort. The technologies we chose to employ were mainly based on organizational preference (Oracle databases, and OpenShift / Kubernetes based containerization). It would have been easier to implement containerized Grouper with a cogent organizational container strategy in place. Our organization didn’t have sufficient resources to assist us, and our choice of containerization technology made us outliers in the CSP cohort. Our peers were willing to help, but it would have been easier had we used common tools.

Conclusions

We were not able to do a production-scale implementation of Grouper with the program timeline. What we learned is that Grouper is an application that we would like to add to the IAM portfolio at Michigan. A full-scale production implementation will require a committed project team and executive support to complete.

About The University of Michigan

The birthplace of the Lightweight Directory Access Protocol (LDAP) and the OpenLDAP server software, “the University of Michigan is a public research university with a primary campus and academic medical center (Michigan Medicine) located in Ann Arbor, Michigan, and two satellite campuses in Flint and Dearborn. The 19 schools and colleges on the Ann Arbor campus offer 250 degree programs and comprise 44,000 students; 7,000 faculty members; and 14,000 staff. According to the latest national data, the U-M spends more on research–$1.39 billion in FY2016–than any other U.S. public university. U-M’s graduate programs include 99 appearing on the top ten list of the U.S. News & World Report (4th nationally).”