Outcome of Registry Evaluation

The Registry Workstream conducted detailed reviews of the Kuali Identity Manager, Central Person Registry (CPR) and Open Registry (jasig) projects.

The group concluded that both Open Registry and CPR are well-developed projects that meet key CIFER criteria, this is, they are:

• Open Source
• Designed to work in loosely-coupled, standards-based environment
• Targeted to meet the needs of higher education

The group debated at length the relative pros and cons of picking a single Registry solution as the CIFER registry. In the end, the group decided not to choose one. It was acknowledged that significant investment in CPR and Open Registry have already been made at Penn State and Rutgers respectively, and that both solutions will continue to live in the marketplace. Some felt that endorsing both solutions would shift the focus to developing common interfaces over time, which would benefit the CIFER project in the long run. It was also acknowledged that each product had different features and there are legitimate reasons why any given campus might choose one product over the other. Some expressed concern that CIFER should not spread its resources (limited as they are) over two products with near identical functionality, rather than focusing investment in one Registry product alone. The conversation then came back to the point that even if CIFER chose only one Registry (OR or CPR), the other would still exist and might be the best solution for some campuses, and would receive additional investment whether through CIFER or not.

Towards the end of the evaluation meetings, our thought leader RL "Bob" Morgan noted that the highest priority was to get both projects in a state where other campuses could "click and download" them, which is noted below as a priority next step.

Below is a table which outlines at a high level what the group concluded about each solution. Campuses seriously considering new registry solutions will most likely benefit from a of review the materials collected, in writing and the presentations, on each of the Registry solutions on the main Registry Evaluation page.

Central Person Registry (CPR)

• Mature, well-developed product. Now in production.
• Very well documented
• Imposes unique id at the time an individual is enrolled in any system of record (SOR).
• Has a good identity matching process (identity matching and address normalization software are not open source).
• Has a process that normalizes addresses.
• Business model based on a very tight coupling between Registry and SORs, where Registry generates IDs to be used by SORs. This works well in an environment which supports tight technical and functional owner integration between SORs and IDMS. Can be challenging to adapt to an environment where SORs are managed outside IAM teams and in technology that does not support real-time integration with IDMS for unique ID generation.
• All data for an individual is stored in a single set of tables (database) with effective dates and end dates indicating which record is current, historic or future. This might make the check for the current data less intuitive.
• Not yet released as an open source project (this is in progress)

Open Registry

• jasig incubator project. Now in production at Rutgers.
• Keeps a set of tables with the data received from the SOR for each individual.
• Current data and historic data are kept separately.
• Rutgers has a UI now that does a lot of what we would want to do (even though it is not part of the open source code base)
• Does not assume it is the source of IDs - can accommodate environment where IDMS consumes and reconciles identities created in SORs
• Identity match is rudimentary
• While it is an incubation project of jasig, Rutgers is the only campus that has been contributing for some time and migrating to a community support/development model will take some time and effort.
• It appears that some of the UI that Rutgers is using is not open source and is developed against OpenRegistry directly, and not against the API.
• API will need to be expanded as it currently does not implement all of the functionality that the Rutgers UI can do.