You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

Executive Summary

UNC Charlotte attended BaseCAMP in 2019 and had big goals going into the CSP, but we learned how to dramatically pull our scope back and pick a small project that provided big value to our organization. By building a subject source for Grouper to build on, we gained more flexibility than they had in Banner, and had a source that could also be used for future midPoint projects. We completed what they set out to except for the move to production which was interrupted by COVID, but planned for this summer. While it was very useful to learn from others and to help them later on, each implementation is specific to campus variables and politics, which doesn't necessarily translate to commonalities in what we are doing.

Solution Summary

Track: Managing Access

Trusted Access Platform Components: Grouper

Project Team: James Wilson (UNC Charlotte), Lacey Vickery (UNC Charlotte), Wyatt Pegram (UNC Charlotte), Matt Deal (UNC Charlotte), Rachel Loudon (UNC Charlotte), Ned Morgan (UNC Charlotte), David McIntosh (UNC Charlotte), Paul Caskey (Internet2), Chris Hyzer (UPenn), Chris Hubing (Internet2)

The Environment: Big school with a small team, running containers in VMs on premises, similar to the rest of the cohort which helped, Banner school

Benefits to Organization: 

  • Applications which can utilize SAML/SSO for authorization
  • Proper level of access control applied immediately at the time of use

The Project

Problem Statement:

As our campus community continues to grow, it becomes increasingly important to have a structured process for access management. UNC Charlotte is seeking to implement an enterprise-ready solution to campus partners using community-supported stable technologies.

Impact Statement:

By providing such a service, campus partners will have a clearly defined process for identifying and delivering targeted access control to a variety of applications.

Scale and Scope:

The scale of this project has been reduced to provide adequate time and resources to achieve. The scope of this project will be to populate the existing Active Directory environment with a sampling of access-specific groups managed by Grouper which will be released by our existing Shibboleth IdP to provide authorization data to applications for consumption.

The Solution

Solutions include Grouper from InCommon and OpenAM from ForgeRock.

Grouper has been chosen as part of an overall strategy to leverage all four components from the InCommon Trusted Access Platform to deliver a unified and community-driven approach to IAM.

The Result

Initial Plan:

  • November 27: Complete CSP Project Plan / Roadmap
  • December 15: Complete Test Environment / Sandbox
  • January 3: Finalize documentation/SOP template for Grouper
  • February 1: Complete Prod Environments
  • March 1:  MVP/Access Control in Production

Actual Implementation:

We are not fully in production yet, due to a production freeze at launch. We didn't want to push anything new to production during COVID, and launch required cooperation with AD admins who were reluctant to change anything due to COVID. Additionally, there were significant new containerization changes that were risky at a time when we needed very low risk. The end of June is now our planned production date, but there is no big push to do it for summer. The delays have allowed for additional testing in our test environment, which has been beneficial. 

We couldn't really start on Grouper until there was a defined subject source. Building the subject database is a huge milestone that was not anticipated before the project. It was something we needed because we wanted to move off of Banner as the sole central data source, and with multiple sources it is best if it's normalized ahead of time.

Additionally, we are still using Forgerock as our IDM, but are working on moving to midPoint. This was part of what we wanted, but not part of the scope of the CSP project since we wanted to keep it manageable. However,  we do have a mini version of midPoint running in test that pulls from Banner, populating a source database that Grouper can later pull from.

The Docker aspect was challenging, and it would simplify people's lives if it was more fleshed out. It seemed like the  Grouper team was also figuring out their containerization strategy at the same time, so we got to contribute to that and they accepted changes, but it did slow us down. The documentation was very fluid since it was all new for everyone, and people were solving problems in the Slack channel. Insight and participation in CSP provided benefits in that arena. While containerization was touched on at the F2F meeting, we eventually learned it would be a big stumbling block for us.

Conclusions & Lessons Learned

Original Success Metrics:

  • Stable software product on a resilient architecture accessible to the appropriate staff members.
  • Thorough documentation available on the use of the software product along with usage guidelines and administrative best practices.
  • Availability of access control information for release through existing Shibboleth IdP.

Conclusions & Lessons Learned

While not in scope for our project, it was good to be able ask questions on Shibboleth containerization since that was another project on our list. 

It would be nice to more explicitly address prerequisites, perhaps send a document out to folks on where you should be to have the easiest implementation, and provide resources on how to do it yourself or outsource. If this was done before training, then we could’ve had time to address these and be able to work on the product after training. Also encourage folks to schedule training more in line for when they are ready to use the product, so they can go home and use it instead of forgetting during the gap in time.

Our advice to others is to scale back the scope dramatically for the project, because there are so many other things that come up like resource issues and political issues. We had really big plans and  gained the understanding that they will take a while to do. 

The cohort had very few schools, and there wasn't enough in common that we often used each other as sounding boards. Each implementation is specific to campus variables and politics, which doesn't necessarily translate to commonalities in what we are doing. However, it was very useful to have learned from what others did to be able help out others as we got further down the road.

We appreciated the level setting expectations, because we did have a grand plan to do everything and struggled to do the bare minimum. When we looked at the CSP components on the website, we thought that it would be more defined how they fit together, but there is still more work ongoing there. 



  • No labels