Executive Summary

The main goal of CSP was to understand the mindset of open source and what’s involved, and this goal was met. The team completed a proof of concept for Grouper for access management, and decided it needed a lot more resources and planning in order to be able to complete the project and roll it out into production. A thorough understanding of what was involved in implementing another Trusted Access Platform component to production was obtained, which will inform the eventual replacement of their legacy IAM system. Overall, we learned what we were hoping to learn from the program.

Solution Summary

Track: Managing Access

Trusted Access Platform Components: Grouper

Project Team: Pascal Cantin (York), Chris Russel (York), Chris Hyzer (UPenn), Chad Redmond (UNC), Bill Thompson (Lafayette College), Chris Hubing (Internet2), Erin Murtha (Internet2), Lacey Vickery (UNC-Charlotte)

The Environment: very small team, already have Shibboleth and eduroam

Benefits to Organization: 

• Reducing required time to complete access management request
• Affecting IT staff to activities that provides more value to the organization.

The Project

Problem Statement:

Our legacy IAM solution (Passport York) has reached some of limits in terms of group provisioning (e.g. automatic provisioning access to AD and Azure AD resources) that we are more and more relying on running ad-hoc scripts and manual interventions to try to keep up.

Impact Statement:

Reduced productivity resulting by the increase of manual work required by the various IT departments of the university to fulfill access management needs.

Scale: Medium to large

Scope:

• Deploying Grouper and Docker into production
• Importing necessary attributes and memberships from SIS and PY
• Provisioning groups and access into AD and Azure AD
• Developing framework for future reuse

Risks:

• Developer availability not confirmed yet that could scale back the scope of this project.
• No Docker infrastructure supported by IT

The Solution

Grouper: An open-source access management solution that can provide automatic group provisioning, based on attribute, role or membership of a person.

The Result

Initial Plan:

• Grouper PoC installation and configuration: Jan/Feb 2020
• Validate Grouper PoC with various IT groups: Feb/Mar 2020
• Deploy Solution production: Mar/Apr 2020
• Decommission existing scripts: Apr 2020

Actual Implementation:

The proof of concept (PoC) for Grouper was completed and the team gained an understanding of how one can utilize a third party to help with the implementation, but there are currently no plans to move to production. A developer was supposed to be assigned to the project, but competing priorities prevented this from happening.

Grouper has some limitations with connectors, one of our core use cases was provisioning to O365 which we weren’t able to get working. Since it was a less common use case, it was more challenging to find people who had done it before. The team also encountered an issue with mail-enabled groups that was not able to be resolved.

During the round of CSP, Docker was being deployed across the products and there was not a standard method of deployment across TAP components. Coming up to speed on Docker took up a fair amount of time.

Conclusions & Lessons Learned

Orginal Success Metrics:

• Decommissioning scripts that are currently used as a passable stop-gap
• The solution can be reused to allow automatic group provisioning to as many as possible directory services and applications at the university: (e.g.: AD, Azure AD, LDAP and Passport York) 
• Replacing suboptimal process of group provisioning inside PY
• Reducing the amount of manual activities by IT for access management

Key Takeways:

• Learning how the community works
• Access management knowledge including Midpoint, Shibboleth, and Grouper
• Access to the SMEs
• Current system was prone to decentralization, move to centralization
• There is not much in the open source world for Privileged Access Management (PAM)

There was an RFP/RFI occurring simultaneously to investigate other options in addition to the Trusted Access Platform, and the main goal of CSP was to understand the mindset of open source and what’s involved. It was clear that one needs to staff internally to support open source. The proof of concept was enough to meet this goal, and there were competing resources due to the impact of the COVID pandemic including remote work and some internal security priorities. Therefore the decision was made not to go into production at this time.

The CSP experience was positive and we became aware of just how big the community is, and how much time a lot of the experts put into the projects to ensure that the features they want are built. The more involvement one puts into the requirements and specifications for a feature, the more likely the feature you want will get built. While there is no monetary cost for open source software, one does have to give time and effort to co-create and shape the software. At TechEx it was good to see how things work behind the curtain, but there was some information overload and challenging to get a grasp on everything going on in the community in just one TechEx.

Pascal was new to York when the project started, and more resources and expertise are needed on the team. With a small team, the CISO is currently very hands-on and helps build servers. We are looking for local help in the Toronto area.

Lessons Learned:

• Plan for and get started on Docker earlier, it took longer than expected to get that going
• Scope can change as you learn new things
• Keep the scope small, it is more than you think it will be
• CSP is really helpful in getting the ball rolling, then it’s up to universities to keep it going
• Putting it into production means supportability, and team needs to be in place to support it
• Identity governance in higher education is very challenging
• When looking to replace a new system, plan for how to decommission the old, the transition from old to new takes additional time and planning