Notes from the 12/6/2007 UCTrust Work Group Meeting at UCSD

Attendees

Round Table Discussion of Identity Proofing Practice

• Registration of remote employees is a difficult issue.  When there is an identified group of remote employees in a single location, someone can be deputized there, but that doesn't help for individuals.  One campus is investigating the use of webcams for "in person" registration.
• There is an issue of people who do not normally use computers.  In general, departments provide computer access for those people.
• The hiring process must be in person.  It would be very useful to have a one-time password issued to new employees at that time.  [Later in the meeting, it was mentioned that AYSO's initial passwords are issued at that time.]
• Albert Wu will write up UCLA's approach to the problem of linking identification (hiring) processes and the registration process.  The Work Group will review this as a recommended practice.
• The password reset process is, essentially, a registration process.  It must be as "strong" as the initial registration process, or the person's level of assurance must be modified appropriately.
• Merced automatically creates an account when they appear in PPS.  Passwords are issued in person.  Students use online registration.
• Student employees are an operational issue for UCSC.  Most students are hired in large batches, and they have a separate HR office.

Round Table Discussion of Applications That Can Access Passwords

• Eric Goodman used the following diagram to raise some issues he's encountered in trying to control applications that have access to passwords.

• As we know, many applications are coded to ask the user of a user name and password, rather than redirecting to an authentication service.  UCTrust (and eAuthentication Level 2) requires controls over the applications that do this, making the campus Credential Provider the arbiter of whether a particular application will be allowed to do this.
• The problem is that some common authentication technologies (e.g., Kerberos and Active Directory) do not control access from authorized applications, so there is not way to enforce the required controls.
• Campuses that employ Kerberos have dealt with this by using some mechanisms, like a firewall, to control applications' access to the Kerberos server.  This does not generally work for Active Directory, though, as it is usually used for authentication by every PC in the enterprise.
• UCSC is considering synchronizing Active Directory user names and passwords with their SSO, but they may not be able to, because of this issue.  UCSD made an explicit decision not to synchronize.
• Other issues that were raised...
• Campuses are moving to offer only encrypted access to their POP and IMAP services.
• We really need some form of fraud detection, based on log analysis.

Status of UCTrust Applications

• AYSO will be released in production on January 10, 2008.  UCD, UCLA, and UCSD have already tested successfully.  UCI, UCM, and UCR would also like to be in the first round of implementors.  (AYSO's UCTrust-related user interface was discussed later in the meeting.  See below.)
• The HR learning management system's vendor is joining InCommon to enable UCTrust access.  UCSD has already done successful testing with a test instance of the system.
• The Connexxus travel portal will identify users via UCTrust when it is released early next year.  David Walker made a brief presentation on the likely architecture and required attributes.

UCTrust Metadata Management

• Ensuring the Validity and Correctness of UCTrust Security Information was reviewed to remind everyone what was agreed about UCTrust's metadata management process.
• Andrew Tristan, Tom Poage, and Arlene Allen agreed to work with David Walker as Initiators and Certifiers of the UCTrust metadata.  David Walker will convene a conference call among those people to finalize processes.

Concerns about the InCommon Agreement

• Dedra Chamberlin mentioned some issues UCB has noticed in the InCommon participant agreement.
• There is a requirement that members install required software.  In the discussion, it was observed that not installing required software would be tantamount to leaving the federation, anyway.
• There is a disclaimer of non-infringement of intellectual property.  It was mentioned that damaging IP infringements would not likely be between InCommon and one of its members, but rather between members.
• Campuses been signing the agreement with these terms.

InCommon's Bronze and Silver Assurance Levels

• InCommon's Bronze and Silver assurance levels are expected to be complete early next year.  They are designed to interfederate with the federal government's eAuthentication levels 1 and 2.  In most respects, they also parallel UCTrust's Campus and Basic assurance levels.  There are, however, a couple of areas where UCTrust would need stronger requirements to match Bronze and Silver:
• An external review (e.g., by Internal Audit) of a Credential Provider's identity management practices is required before certification.
• Credential providers are required to keep more extensive logs.
• It was agreed that we will leverage Bronze and Silver's requirements as we revise our UCTrust requirements.  At some point, we may be able to retire the UCTrust assurance requirements in favor of InCommon's, but that will be evaluated as both UCtrust and InCommon evolve.

Application Design Issues

• Bruce James presented AYSO screenshots of what a user sees after entering AYSO via Shibboleth in the current QA release of AYSO.  The following suggestions were made for the next QA release:
• There was concern about AYSO's first page after a UCTrust entry; it needs more explanation, and it needs to be part of a process flow with any subsequent pages the user may see.  In particular, there are three potential cases that each need appropriate text:  
1. The user has entered AYSO previously via UCTrust and opted to have AYSO continue to prompt for the AYSO password.  In this case, the user simply needs to be reminded that he/she opted for this and that they should enter their AYSO password.
2. The user has entered AYSO previously, but not via UCTrust.  In this case, the user is told that they need to enter their AYSO password on this first entry.  The user is also told that they will see another page giving them the option whether to continue to prompt for the AYSO password.
3. The user has never entered AYSO previously.  In this case, the user is asked to enter the password they were given when they were hired.  They will also be told that they will get the password prompt option page from #2, as well as a series of pages that register them for AYSO.
• The "password prompt option" page contains a statement that password sharing is only allowed for specific business processes.  We should change that the approved.
• The text on the (already existing) AYSO page that creates a user name will be made more explicit that it is an AYSO user name.
• It was observed that users have three choices for AYSO authentication:  1) the AYSO password only, 2) the campus password only, and 3) both AYSO and campus passwords.  #3, however, is only enforced by the UCTrust entry, not the existing https://atyourserviceonline.ucop.edu entry point.  Changing this, however, will create an operational problem for people who select #3 and then leave their campus.  We won't do anything about this right now, but we need to keep it in mind.
• The Riverside, Irvine, and Merced campuses would like to be in the first round, along with San Diego, Davis, and UCLA.
• [The AYSO group discussed these issues on 12/12/2007 and expects to produce the next QA release by 12/21/2007.]
• Logout processing was on the agenda, but there was insufficient time for discussion.

Activities for 2008

• The following were discussed as issues to be addressed over the coming year.
• Operational issues
• Log sharing
• Help desk coordination
• Outage notification
• We should use the AYSO rollout to set guidelines for future rollouts.
• Permission management
• Entitlements
• Groups
• Roles
• Help for SP development and deployment
• Arlene Allen and David Walker discussed a draft charge for a group the ITLC is sponsoring to rethink UC's management of identity information.  People interested in participating in that discussion were encouraged to contact Arlene or David.

Next Meeting

• The next meeting will be at UCSB in the February/March time frame.