Notes from the 7/12/2007 UCTrust Work Group Meeting at UCI

Attendees

Roundtable on Recent Events

• UCSB
• There have been budget cuts that will delay their UCTrust implemention, at least until Q4, 2008.
• UCM
• There is a new extension program at UCM, and it has been integrated into the central identity management system.
• UCSD
• UCSD's instance of the Effort Reporting System (ERS) is now in production, using Shibboleth to identify its users.
• AYSO is still having performance problems for the first user every day.  IR&C has created a QA instance of AYSO now, so testing should be easier.
• UCSD has been participating in InCommon's discussions of library applications.  A major issue is how to avoid forcing people to log into the public access machines provided by the library.
• LBNL
• LBNL's identity management team has been meeting for the past year and has now produced a set of 18 recommendations that are being reviewed by management.  They expect funding in October.
• UCI
• While trying to find time to implement their next generation directory, UCI has been involved in a number of projects, including:
• lifelong electronic mail addresses for alumni
• emergency notification
• Paul Main is leaving UCI to enter law school.
• UCI is looking at strategies to migrate from their current ph/qi-based enterprise directory to a relational database.  Reasons include:
• More available expertise
• Supported software
• Marketplace of report generators, etc.
• Provides an opportunity to document and readdress business logic
• UCB
• UCB retired their version 1 LDAP directory this week.  The new system is based on Sun's identity management suite running on a Linux cluster.
• UCB is moving to replace their current SSO with CAS 3.1 and Shibboleth.
• UCR
• UCR is looking at a hardware token that supports two-factor authentication (of sorts).  Authentication requires possession of the token and a 4-digit PIN.
• UCR is working to integrate alumni and extension into their identity management system.
• The Shibboleth expert who left UCR has been replaced.
• UCLA
• UCLA has been working to integrate with various applications, including:
• the new system-wide training management system
• AYSO
• resolving help desk issues
• UCLA's Moodle course management group
• AYSO
• Testing has been challenging, since only one test is possible per day.
• This should improve now, as a separate QA instance of AYSO has been created, and the AYSO group has instrumented the code for debugging.
• Training Management System
• The project is progressing.  David Walker agreed to distribute information about per-campus scheduling and SumTotal documentation of the authentication options.
• There was general agreement with User Provisioning and Authentication for the SumTotal Learning Management System at the University of California (DRAFT –7/3/2007) for the provisioning and authentication strategy.  Specifics about the identifier to be used for non-employees, however, were discussed under Application Integration and User IDs below.
• Travel Portal
• The University has issued an RFP for a system-wide travel portal; responses are currently being evaluated.
• UCTrust was not mentioned in the RFP, but David Walker is trying to get it included in the implementation.
• The roamap was updated and is now available.  LBNL has now estimated their implementation timeframe, and UCSB's has been delayed, due to budget constraints.

Revisions to the UCTrust Document

• The 6/12/2007 draft that was distributed with the agenda was discussed.
• There was agreement that we should proceed with the proposal to create the UCTrust Campus level of assurance, as described in the document.
• There was discussion of one or more attributes that could be used to identify identity assertions as "test."  Two scenarios were discussed:
• While debugging a service, it is not unlikely to be necessary to send assertions either from a test version of an Credential Provider (CP) or to a test version of a Resource Provider (RP).  This can cause conflict with UCTrust policy. We need a way to flag these test assertions for what they are.
• It is common to use fake user IDs to perform tests against production Resource Providers to verify that the RP is working properly.  To be a valid test, however, these fake user IDs must look like they represent valid users.  We need to flag these assertions appropriately.
• It was decided that the two scenarios are different enough that they each deserve their own attributes.  David Walker will propose what they should be.
• We had planned to discuss alignment with NIST 800-63 after the lunch break.  Unfortunately, I forgot to return to that topic.  We'll pick it up next time.

Quick Demonstrations During Lunch

• David Walker demonstrated a small UCTrust information repository, based on the Protege ontology editor that UCI uses for their NASA system.  In the future, this information will be exported to a web site for use by the UCTrust community.
• Gabe Lawrence demonstrated an OpenID server that they have integrated with their campus identity management system.  Its purpose is mainly to provide access to off-campus services that use OpenID, but it is also a good alternative for on-campus services that do not require Shibboleth functionality or UCTrust-level assurance.

Metadata Describing Resource Providers

• It was decided that distributing requested attribute release policies in XML syntax is not particularly helpful for CPs. What is needed is the required level of assurance and the list of attributes.  This could be included in the UCTrust information repository.
• What would be useful is a method for announcing new RPs.  We'll use the UCIDMgmt-L@ucop.edu listserv for now. As the number of services increases, we may want to consider something more automated.

Application Integration and User IDs

• We currently have multiple identifiers that can be used by applications, including:
• eduPersonTargetedID
• eduPersonPrincipleName
• UCnetID
• Selection of which identifier is appropriate for a given application depends on a number of issues, including:
• Is provisioning required before the user's first session?
• Are duplicate identifiers allowed for the same person?
• Is it possible to perform a strong identity match (using SSN and date of birth) to eliminate duplicate identifiers?
• Does the application support scoped identifers that are long and may contain special characters?
• Must the identifier be persistent over time?
• We can satisfy nearly all requirements, except for applications that do not support scoped identifiers with the creation of a new UCTrust attribute of the form <unique and persistent campus identifier>@<campus InCommon name>.  These identifiers would be unique and persistent within each campus, but not across campuses.  As an example, if a UUID were used for the <unique and persistent campus identifier> at UCOP, then "550e8400-e29b-41d4-a716-446655440000@ucop.edu" might identify Bruce James.
• It was the consensus that applications really should support scoped identifiers and that we would encourage that support whenever possible.
• The problem comes with applications, like the new system-wide training management system, that do not support long identifiers and cannot be modified in the short term.  The agreement was to create a short version of the new attribute described above that could be persistent for at least a few years.
• The training management system supports 25-character identifiers, but we decided that 12 characters would be a better limit.
• Of the twelve characters, 10 will be available for assignment by the campus, and two would be used for a "scope."
• We will support this attribute for no more than five years, giving a clear signal to applications that they must support long, scoped identifiers in the medium term.  If at any time during those five years we have no more applications that require the short identifier, we will deprecate the short identifier at that time.
• David Walker will distribute a proposal for these identifiers.

Next Meeting