Product Information

The Penn State Central Person Registry is a intelligent identity store for person information. From a data store perspective it can store the following information:

  • Biographic Information (with history).
    • Names, Addresses, Email Addresses, Telephone Numbers, Gender, Date of Birth
  • ID Card Information to include a photograph.
  • Person and Account Linkages.
  • Directory Confidentiality Preferences
  • Digital Credential Information (support exists for multiple credentials per person). The credentials are generated using an algorithm that pulls an available credential from an identity pool.
  • Identity Assurance Information to include the event history.
  • Internal and External Affiliation Support.
  • User Comments.
  • Registry Generated Identifier.

The registry is composed of the following components:

  • The registry itself, which is a relational database (any hibernate dialect database can be used).
  • A collection of Web Services that are SOAP-based.
  • A rules engine that is used for affiliation transitions utilizing JBoss's DROOLS. The rules engine separates the business logic from the application code.
  • A messaging component for notification of events and provisioning/de-provisioning requests (JMS and/or STOMP).
  • A pluggable matching facility.
  • Various UIs.
    • Identity Provisioning

Presentation

CPR Registry Evaluation Presentation

Code

The CPR code is Java-based.  It contains two components, the CPR Core (database, and common routines) and the CPR Services (SOAP-based).  The Open Source version of the Penn State Central Person Registry is Apache 2 licensed. The source code for the registry can be found in GitHub
In addition to the source code, Penn State has developed a QuickStart that includes all of the CPR compiled code, application and messaging servers, and sample data. The QuickStart is a fast way to kick the tires on the CPR without building the source code.

Road Map (within the next 2 months).

  • Support for RESTful APIs. Code already exists for "GETs", the implementation for the remaining APIs should take 2 weeks.
  • Support for non-person identities in the registry.

Resources

  • No labels