PSU Response To Registry Questionnaire

General architecture

Describe how ID match capability is provided by the registry solution. For example, is it (a) an integral part of the solution as provided or (b) must it be integrated with an external ID match engine or (c) can it be provided in some other way?

Our current solution for matching within the CPR has two parts, an external engine which generates match codes and an algorithm that is part of the registry.  So I would say our answer is a and b.  And its flexible enough that another solution can be dropped in.  With regards to the match codes that are generated by the appliance, they take into account variations in name, and address.  So a match code for Bill Smith, William Smith and Billy Smith would be the same thing.  When we do the matching process we attempt to do an exact match using either our Penn State Identifier Number (PSU ID Number), or Social Security Number or the userid.  If the exact match fails, a near match is done using the match codes.  The result of which is a ranking of the match between 1 and 550.  A match is anything that has a score of at least 330.  We have two match algorithms one for domestic and one for international.  In addition to the identity match, we found it important to attempt to cleanse the address data, so we purchased an external product that does address validation.

Matching Criteria - Standard
Matching Criteria - International 

Describe how groups management (for use with authZ controls and other purposes) is provided. For example, is it (a) handled internally by the solution or (b) integrated with an external group management engine such as Grouper or (c) provided in some other way?

Under the umbrella of our IAM project, we have a sub-project related to Access Management.  Groups management will be part of that project, not our registry one.  At this time, we have only gathered requirements from our stakeholders.  We do feel that Grouper will probably be part of our Access Management solution in the future.

Data model

Describe how the registry solution supports an extensible set of attributes about (a) persons, (b) applications or other external resources, and (c) other, arbitrary entities?

Our data model is flexible enough to support additional person attributes by the addition of new database tables and the establishment of the linkages between the person entities and their new attributes.

Our current design for the registry is focused on people.  We envision registries of registries to support things like location, organizational units and applications.

AuthZ support

Describe how the registry data model supports defining arbitrary user roles in support of authZ functions.

Roles are an integral part of any Access Management solution.  Our registry can be used to provide information in the construction of roles, however the roles themselves will not live in the registry, as they will reside in an access management solution like Grouper for example.

Features

Describe how the registry solution supports audit logging of sensitive transactions, including support for the recording of historical changes made to sensitive data. Describe how this log includes the requester and authorizer identities, and transaction timestamps.

Our registry has various levels of auditing, the first of which is database logging.  We log all transactions to a service log.  In addition, for each database table we maintain history of changes to records.  Whenever a record is changed, the existing record is marked inactive and a new record is cut.  For each database table we have the following fields that determine our history:

start_date - the timestamp the record was "started".
end_date - will be NULL for active records, otherwise it will be the date the record was made inactive.
last_update_by - contains the identity (service or person) which updated the record.
last_update_on - contains the timestamp of the date the record was last updated.
created_by - contains the identity (service or person) which updated the record.
created_on - contains the timestamp of the creation of the record.

Remember whenever there is a change a new record in the particular database is cut.  We opted to go this route as opposed to having either a single audit table or multiple audit tables.  The changes for records are contained within the tables themselves.

In addition to database logging, we also use log4j as part of all our Java code.

Refer to the data model at the CPR Design Wiki.

Describe how the registry solution supports the secure storage of security questions and answers for use in password recovery.

At this time, the data for password security questions and answers are stored in a separate database schema that is outside of our normal registry.  The data can only be accessed via the password reset application using a separate database userid and password.  Our database vendor Oracle does provide the facility to encrypt the answers, which we currently do not have in place.

Is there support for multiple name and address types as well as history?  If yes, please describe.

Yes, our registry does support multiple types of names, addresses, phones, and email addresses.  The types can be directly traced back to our IAM policy (which is in draft mode).  Each type is associated with each record stored in our names, addresses, phones and email address types.  So for example, for a Name record it can either be a LEGAL_NAME, PREFERRED_NAME or a DOCUMENTED_NAME.  For a documented name which is obtained from a legal document, we also record the document type (which can be password, driver's license, state identification card or a military identification card).  In addition the types are used as part of our authorization decisions.  We have designed our authorization scheme to allow RAs to only assign particular types of data, if need be.  This authorization is control using Grouper.

Identity Assurance

Are registration events captured as they occur?  Do these events automatically trigger assignment/deassignment of an IAP

Yes, refer to our data model (IAP_Data) for more information about the data that is captured during a registration event.  The data is accumulative, once the user has met the necessary requirements for a particular IAP, it is automatically assigned.  On the flip side, other events like account misuse will trigger a downgrade of the user's IAP.

Is there support for real time provisioning of Identities/services

Yes, the person registry supports the notification of provisioning requesting using JMS.  When a service and/or batch process is executed that requires a service/identity to be provisioned, a JMS JSON message is sent to the appropriate provisioner.  The results of the provisioning event are retrieved by a standalone daemon which is then used to update the registry.

Describe how data is processed (batch, web services)

Data within the person registry can be processed in either batch of Web Services.  The Web Services are SOAP-based.  The common core code is isolated in a .jar file that can be shared between the service and batch processes.

Is registry dependent on other open source or vendor products?  If yes, please provide details.

The registry is built using open source products; apache tomcat, apache CXF, Java, Hibernate, JMS, Drools and JAX-WS.  The only commercial product that is used by the registry is the matching appliance, which is isolated by the use of a service.  So any matching solution can be dropped in with minimal changes.

Where is the business logic stored?  Is there support for delegation to maintain these rules?

Core business logic for the person registry is stored in a rules engine that is Drools Expert.  To isolate changes from business logic from rule updates, the rule engines is encapsulated in a service that applications call to process rules.  That way, applications do not need to be redeployed for a rules change.  With regards to maintenance a future release of the person registry will utilize Drools Guvnor for rules maintenance.  In combination with the features it provides and Grouper, we will be able to delegate the maintenance of rules.

How does the registry notify external entities of data changes?  (for example name is changed)

External entities have to register their preferences for message receipt with the person registry.  Then based on service and/or batch execution if there is a change to a data element they are interested in, a JMS message is sent to them with the change information.  Currently, we are doing point-to-point JMS messaging, but plan on looking at push/pull in the future.

Is code located in public repository

No, not at this time.  A snapshot of the code is available at a shibboleth protected web site.

How are changes, marketing, etc communicated to public? (wiki, lists, web presence)

Our registry is currently not in production, we do however have numerous stakeholder and developer listservs.  In addition IAM at Penn State has a presence on Twitter, Yammer, Youtube and Facebook.

Is there proper OSS license?

We are using a license which has been approved by our CIO.

Is there a clear project lead?

Yes for our project, the leader is Renee Shuey (prs4@psu.edu).

Is there an existing project steering committee/governance?

Yes, there is an overall IAM governance council.