UC Identity Management Work Group Meeting - 3/8/2004 - Notes

Attendees

Summary of Outcomes

• The goal of this project is to allow members of UC campus communities (initially, UCSD, UCI, and UCLA) to access UC For Yourself (UCFY), Your Benefits Online (YBO), and CDL-licensed resources by using their local campus login systems.
• We will use Shibboleth (which, in turn, uses SAML) as the technology to implement this federated authentication.
• We will implement support for the following attributes:
• UCFY/YBO
• UCnetID
• Campus ID (for debugging)
  
• Transaction ID (for debugging)
• CDL-Licensed Resources
• eduPerson attributes, particularly Entitlement and Shibboleth's "Tracking" ID
• We will configure the origins to release attributes only to registered target applications.  Policies on the use of these attributes will be developed.
• We will document the participating campuses' identity management practices and ask for Vice Chancellor-level policy decisions on assumption of risk.

Review of the Schedule

Current State of Authentication, Portals, etc.

What are We Doing?

Technology Selection

• David Walker gave a brief summary of how Shibboleth works and what the InCommon and InQueue federations are.  InCommon is expected to become the federation of institutes of higher education in the United States.
  
• The group discussed whether we should use the InCommon WAYF (Where Are You From?) service for UC's internal purposes.  It was decided that we should take the simplest path of using the InCommon WAYF, but that we should monitor InCommon's ability to provide a robust WAYF service and be prepared to change this decision if there is a problem.
• Liberty Alliance and WS-Federation were discussed as alternatives, as well as Microsoft's strategies.  From the point of view of current deployment, particularly within higher education, Shibboleth is our best choice.  Liberty Alliance is very similar to Shibboleth, and the two groups are communicating, so we expect good synergies between Shibboleth and Liberty Alliance.  Microsoft's strategy is more to federate enterprise directories, something that was found to be less than successful during the PKI project.
• We're actually making standards decisions at three levels:

1. Trust agreements, attribute definitions, and attribute release policies, etc. have the longest lifetime.
2. The decision to use SAML as the syntax for our attributes is in line with multiple, competing transport decisions (e.g., Shibboleth and Liberty Alliance).  We expect that decision also to have a long lifetime, but not as long as #1.
3. The decision to use Shibboleth for transporting SAML assertions will likely have the shortest lifetime, but it should be at least a few years.  Over time, we may provide multiple methods for transporting assertions.
   

• UCI raised the issue of commercial packages, such as Netegrity and Oblix.  They tend to support the broadest range of "off the shelf" applications.  They should be able to share the same person repository as Shibboleth.  We also agreed to explore the possibility of getting these vendors to implement integrated Shibboleth origins.
• There is currently an issue for Shibboleth with respect to authencation within portal channels.  The Shibboleth architecture is working to resolve this for JSR 168, the new standard for portal/channel communication.
• We do not expect Shibboleth to present any difficulties for implementing single sign-on as part of this project, as the campus's existing SSO solutions would likely be used for Shibboleth's authencation.  Single sign-off does present a difficulty, and UCI feels that it is important to have a UCFY/YBO logout cause a logout from all of SNAP.  We will explore allowing a "logout" URL to be passed to UCFY/YBO from the campus's portal.  UCFY/YBO would redirect the user's browser to that URL after logout.
• Session timeouts are a complex issue.  Typically, sessions are maintained by the SSO, Shibboleth, and by applications (including portals and channels).  UCFY/YBO will log people out after a 20 minute period of inactivity, whereas SSO implementations may keep sessions alive for longer periods of time.  As we understand this issue better, we will consider appropriate solutions.  In the interim, we do not believe that UCFY/YBO's potential 20-minute extension of a campus's timeout policy to be an obstacle.

Attributes

UCFY/YBO

Policy

• Attributes will be released only to registered targets.  This will create an operational issue at some time when all campuses must register a new target, which is not an uncommon event for library resources.  Processes will need to be developed to address this, although that is outside the scope of this current project.
  
• Each attribute we define will have an associated policy statement governing its availability and subsequent use by the target applications.  We will need to create a process for defining new attributes and deprecating old attributes that are no longer in use.
  
• We need to create an agreement to trust each other's identity management processes for maitaining the person repository, registration, authentication, etc. for the purpose of making accurate assertions about the members of our respective communities. That agreement should establish minimum operational standards, identify responsible parties, etc.  Elazar Harel pointed out that, for this project, we need only to have agreements that UCFY/YBO and the CDL's vendors will trust the three campuses.  Elazar also suggested that we ask the Vice Chancellors of Administration to certify their campuses' identity management; everyone concurred.

Rollout