Notes from the 4/17/2007 UCTrust Work Group Meeting at UCLA

Attendees

Campus IdP Rollout Status and Significant Activities

• The schedule estimates in the 1/31/2007 version of the UCTrust Identity Management Roadmap were reviewed.  The revised estimates are now posted at:

• There hasn't been much interest from our libraries in UCTrust and Shibboleth outside of UCSD.  David Walkre will talk with the CDL about this.
• Eric Goodman asked what campuses are doing about SSO services for a mix of high and low assurance applications.
• UCB is planning to use a second login/password pair for higher-risk applications.
• UCSD considers personal computer logins to be separate from the campus SSO.
• Hardware tokens are in the $10-$25 range (or less), and there is the opportunity to combine them with building access and other ID cards.
• This will be put on our next meeting's agenda.  We'll want to focus on use cases.
• There was a short discussion of what system-wide organizational roles we might need to define.
• To date, we haven't had good use cases, but PAN may provide one.

Status of UCTrust Applications

• UC Grid
• Work continues to assure that UC Grid and UCTrust are well integrated.
• AYSO
• The AYSO team at UCOP and the identity management people at UCSD are working on a performance issue they have discovered and expect to have it resolved soon.
• The 3/27/2007 version of the UCTrust policies will soon be posted.  [This was been posted on 4/19/2007.]
• Once these issues are resolved, the Shibboleth version of AYSO will be released for use at other campuses.
  
• Effort Reporting System (ERS)
• Shibboleth is being integrated into ERS for UCSD's instance of the application.  It will be available for other campuses that use ERS.
• ERS will use employee ID as its identifer.  A new UCTrust attribute will be defined for this.
• Human Resources Learning Management System (HRLMS) 
• The HRLMS implementation is being led by Human Resources at UCOP.  The preferred method for identifying users will be UCTrust, and the vendor is currently implementing a Shibboleth SP for their software (SumTotal).
• UC employees that will be synchonized regularly into HRLMS by a back-end system that is yet to be designed and implemented.  The user identifier (which will need to be sent via Shibboleth) will likely be UCnetID, although employee ID is a possibility.
• Other authentication methods can be implemented for those campuses that have not yet implemented UCTrust, but it will probably be at an additional cost.  Those campuses will need to implement the identifier selected by the synchonization process.
• Kuali Financial System
• UC's Kuali group is implementing a "proof of concept" system that will include the Davis, Santa Barbara, and Irvine campuses.  Irvine will use Shibboleth to identify its users in the proof of concept instance, but Davis and Santa Barbara will not, since they have not yet implemented Shibboleth for their campuses.
• UC Travel Portal
• There is a potential project to create a system-wide travel portal with links to vendor sites.  It is not yet known whether the portal or the linked vendors will require access management, but UCTrust will be the preferred method if they do.

The 3/27/2007 Revision to the UCTrust Policies

• David Walker apologized for not having yet posted the 3/27/2007 revision to the UCtrust policies.  [They were later posted on 4/19/2007.]
• The four campuses that certified to the earlier version of the document have been asked to send a one-page memo, acknowledging the 3/27/2007 revision and certifying that they will abide by its terms.
  

uDir and SSNs

• Albert Wu raised the issue that, while we encrypt the transmission of the files exchanged nightly for the uDir system, we do not encrypt the files themselves, so they are not encrypted while "at rest" on servers.  (The uDir system, among other things, assigns UCnetIDs.  The exchanged files contain names and SSNs.)
• It was agreed that we would modify the transfer of these files to use PGP before and after the transfers to ensure that the files are encrypted before and after the transfers themselves.
• Bruce James mentioned that a member of his group had suggested creating a secure web service that would map between SSNs and "randomized" SSN (RSNs).  Such a service could be used to replace SSNs that are currently stored in application-specific databases.  The following issues were raised in the discussion.
• One of the problems with any obfuscation of SSNs is that there are only a billion possible values.  By limiting the RSNs to 9 digits, everyone knows which RSNs can potentially be mapped to SSNs.  There was encouragement to make RSNs longer than 9 digits.
• For identity management, there is no need to map RSNs to SSNs.
• It's not clear that there is a need for two different application systems to share the same SSN <-> RSN mapping.  We could achieve greater security by generating different RSNs for different systems.
• Bruce will distribute the SSN mapping proposal when it is available, both to this group and the IT Architecture Group.  [Bruce sent the proposal to the our group on 4/25/2007.]

Pre-Provisioning of Applications like ERS and HRLMS

• We are starting to see applications that require their users to be created prior to those users' first logins.  ERS, for example, might need to send electronic mail to a Principle Investigator (PI) before that PI has any other need to login to ERS.  That provisioning of users is currently accomplished in an ad hoc manner by each application, which is particularly difficult for applications like HRLMS that need to merge data from multiple campuses.
• David Walker asked if we should consider creating a merged "meta" repository of the identity information maintained at each campus.
• The consensus was that we should ask the ITLC about such a strategy before proceeding.

Review of UCTrust Policies

• Section 9.1 "Specific Requirements for Credential Providers"
• 9.1.1.4:  We will mention 128-bit SSL and TLS as appropriate encryption technologies to protect the transmission of passwords.  We will also add a new item for applications that have access to passwords, even though the transmission is encrypted.
• 9.1.1.6:  We will review the latest NIST registration requirements to ensure that we are aligned with eAuthentication assurance level 2.
• 9.1.1.8:  We will align this item with IS-3.
• New Requirements
• The synchronization processes for the enterprise directory must keep its information current within three days of the repositories of record.
• The help desk must be available during normal business hours.
• The technical / operational contact information must be 7x24.
• That is, it must at least be possible to leave a message.
• A "current system status" page, accessible to all UCTrust participants, is highly desired.
• "Audit" logs should be retained for at least three months.
• This will require more research.  We need to identify what Shibboleth currently logs and decide what of that is useful.  
• We also need to establish standards for logging of changes in information in the enterprise directory.
  
• Section 9.2  "Specific Requirements for Resource Providers"
• New Requirements
  
• The help desk must be available during normal business hours.
• The technical / operational contact information must be 7x24.
• That is, it must at least be possible to leave a message.
• A "current system status" page, accessible to all UCTrust participants, is highly desired.
• "Audit" logs should be retained for at least three months.
• This will require more research.  We need to identify what Shibboleth currently logs and decide what of that is useful.
• A revised draft reflecting the past two meetings' discussion of UCTrust University of California Identity Management Federation Service Description and Policies will be distributed for further discussion at our next meeting.