Background

The University of Pennsylvania is a private Ivy League research university in Philadelphia. The university has four undergraduate schools and12 graduate and professional schools. The population at Penn is comprised of 28,000 students, of which 13,000 are graduate students, and 26,000 faculty/staff (including the health school).

Identity Works LLC d/b/a Instrumental Identity was engaged by the University of Pennsylvania’s ISC department to initially help the team through the process of documenting requirements, determining current state, and developing use cases to initiate an RFP process and vendor selection for a new IGA solution. Instrumental Identity worked with Penn throughout the process, helping them navigate vendor selection while remaining solution agnostic. Penn selected SailPoint IdentityIQ as its next IGA solution. It would replace the university’s legacy “Penn Community” (aka PCOM) system, a homegrown IAM solution created and maintained by Penn for 20 years.

Challenges

In a typically higher-ed scenario, Penn Community was responsible for aggregating and disambiguating user data from various systems of record and matching multiple records to a single human identity. This system was also responsible for flagging account data as invalid, precluding it from matching until the problems were corrected in the source.

Penn Community also included a web-based user interface (EntryView) that allowed analysts to view conflicting or invalid records and then act on them with various action buttons. It optionally provided different views of the data, depending on the privileges the analyst possessed .

Out-of-box, SailPoint IdentityIQ does not have a “fuzzy matching” engine, nor does it provide any user interface for manually reviewing ambiguous matches or merging mismatched records. It also does not provide a way to flag records as “invalid.” IdentityIQ also treats data access in an “all or nothing” way, requiring additional customization to retain EntryView’s permission model. Without the ability to manage the complexities of Penn’s data, IdentityIQ would not be a reasonable part for Penn’s IAM program.

Solutions

Instrumental Identity had a  clear understanding of the business needs and requirements around a centralized matching process and a need to delegate conflicts that arise in the matching process. These are capabilities most vendor solutions don’t provide, but we have been able to solve not just with SailPoint, but with other products, such as Oracle Identity Manager, as well. 

Leveraging the plugin framework of SailPoint IdentityIQ, Instrumental Identity created database tables, a custom UI, and API calls with configurable matching rules, including the ability to leverage what Penn had already been doing for many years, which was fuzzy matching using Jaro-Winkler. The result was branded as PennMatch, a custom SailPoint plugin, which provided a conflict resolution process that leverages the following features:

• Automatic creation of conflict cases when invalid or conflicting data is detected. The user interface allows analysts and source system data owners to pass cases among themselves, add notes about resolutions, and take actions on cases. Actions include manually matching, selecting one of several proposed matches, and permanently ignoring a bad record. New actions can be easily added by Penn’s developers.
•  A more robust permissions model in both the out-of-box IIQ pages and our more advanced Identity Viewer UI was created using a proprietary UI Enhancer plugin developed by Instrumental Identity,. These permissions were written so that the same model applied to both Conflict Resolution and Identity Viewer interfaces. 
• The ability to put a matching conflict to sleep, which was ideal for the use case where an applicant may have some PII discrepancies, but resolving that issue was only important if they were admitted.
• A robust testing workflow, which allowed staff doing UAT to make changes to source data in a simulated fashion without having to rely on data stewards to make changes to their data i.e. hire an employee, change a DOB, change the name of a student, etc.

Impact

The resolution time to correct and match identities was drastically reduced. Data stewards were able to resolve and identify issues coming from their sources, and in quite a few instances, we were able to help them identify problems within their own data, so they could put more controls and validation checks in place. The adoption from the data stewards far exceeded expectations and having insights into their users helped them field customer-facing questions more easily, which increased visibility into their data and where problems occurred and allowed them to correct changes on their own or provide feedback.

The manner in which Instrumental identity implemented the solution enabled application developers to easily configure data validation rules, add additional attributes to be supported for matching rules, easily onboard new sources, and maintain a per environment source code structure. All these tasks were harder to support and manage using the legacy solution.

From a security perspective, the solution had clear auditing trails on when data changed on conflicts, what the previous values were, and who viewed conflict records. The ability to know who was looking at a particular case or if it had been viewed at all was extremely helpful to the team(s) supporting the process as they could avoid duplicate efforts. There were also security controls put in place such that affiliated organizations like the health center could not see other records within the system, only their own.

Prior to the conflict resolution process being conducted within IdentityIQ, analysts would need to look in multiple databases to get additional data elements about the user, such as account claiming attempts and details, address, and contact information they didn’t have in their homegrown IAM system. This added time and nuance to determining if a new user should be matched with someone else or if there was a duplicate scenario. With the way it was implemented in IdentityIQ, even if we weren’t storing data within the application, we had ways to read in the data dynamically for viewing purposes all in one place with the incoming data from the source.

Lessons learned

• Change takes time.
  • With being a new process and having a new user interface, one of the biggest challenges was getting beyond the acceptance of “change.” The operational staff that dealt with conflicts daily took quite a bit of time to adjust. While this is normal for any new product or UI, it led to an almost endless cycle of changes throughout the project.
    • Lesson –  Let the process settle in and monitor it before engaging in continuous improvement. 
• Don’t try to solve everything.
  • As SailPoint IdentityIQ was settling into production and new users were onboarded, we sometimes didn’t match users properly. This was not new with the vendor product and occurred previously in the homegrown system too, but because of data issues where a first name was sometimes the middle name in another source or nicknames were used, there would be duplicate records.
    • Lesson – Know when to spend time developing solutions and identifying the potential risk and outcomes of significant changes to matching outweighs the effort it takes to resolve manually.
• Test, test, test.
  • Testing in a lower environment can be challenging as source systems are refreshed in lower environments and often on different cycles or sometimes not at all. The risks of a user being matched incorrectly or increasing duplicate record counts can cause a lot of heartache in production.
    • Lesson – Develop a strong set of regression test cases and leverage production data to simulate testing, especially in the gaps you are trying to close. Fortunately, the project was able to leverage workflows that simulate testing without needing to involve data stewards in manipulating use cases.
• Plan for things to go wrong.
  • It never fails that a change goes into production, and something doesn’t go according to plan or gets missed in testing. Lesson – Leverage source control and tag certain features as their own release. Being able to roll back a change quickly for a particular feature-set while not impacting improvements or other bug fixes that were deployed is critical.

About Instrumental Identity

About University of Pennsylvania

—Back to the InCommon Catalyst Case Studies