Executive Summary

<Jessica to write after meeting>UNC Charlotte attended BaseCAMP in 2019 and had big goals going into the CSP, but they learned how to dramatically pull their 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 Managing Access

Trusted Access Platform Components:  Grouper

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

The Environment: big 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 currently, because prod yet, due to a production freeze at launch, . We didn't want to push anything new to prod production during COVID, and launch required cooperation with AD admins who were reluctant to change anything due to COVID. Additionally, containerization was changed a lotthere were significant new containerization changes that were risky at a time when we needed very low risk. The end of June is new plan, no now our planned production date, but there is no big push to do it now that summer changed, good to have it flushed out in test 

Shibboleth changes also required that didn't want to do with COVID

do have a mini version of midPoint running in test, pulling from Banner, populating a source db from Grouper to pull from, is in production

for summer. The delays have allowed for additional testing in our test environment, which has been beneficial. 

We couldn't really start on grouper Grouper until there was a defined subject source

not provisioning back to AD in production

lot of issues going on in AD until early May, really reluctant to have anything going on

subject db being built is . Building the subject database is a huge milestone that was not anticipated before the project, it . It was something we needed , because we wanted to move off of Banner as the sole central data source, having and with multiple sources , it is best if it's normalized ahead of time.

Additionally, we are still use 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 Documentation is us down. The documentation was very fluid , since it was all new for everyone, and people were solving things problems in the Slack channel, . Insight and participation in CSP provided benefit benefits in that arena

Shibboleth seems more stable in how it's rolled out, its more rigid in how it's deployed

. 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>

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, prerequisites, and provide resources on how to do it yourself or outsource, before training, not into grouper implementation until later. 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 you 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, implementations are . Each implementation is specific to campus variables and politics, which doesn't necessarily translate to commonalities in what we are donedoing. 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 , struggling and struggled to do the bare minimum, . When we looked at the CSP components and on the website, we thought that it would be more defined how they fit together, COmanage is still having a bit of an identity crisis, lagging behind othersinitially thought it was a year long, were surprised it was shorter than they thoughtbut there is still more work ongoing there.