Notes from the 8/10/2006 UCTrust Meeting at UC Berkeley

Attendees

Implementation Status

User Interface Issues [PPT, ODP]

• While it is not possible in all cases, campuses should implement login processes that invoke the WAYF to declare the originating campus before the user browses to a Resource Provider that uses Shibboleth (for either UCTrust or InCommon).
• In order to mitigate the situation where a user browses directly to a UCTrust Resource Provider like AYSO, Resource Providers should provide help information, warning the user that they may be redirected to the WAYF. This should include contact information for the Resource Provider's help desk.  The UCTrust Federation Administration will provide a page with links to help for each of the UC campuses that can be incorporated into the Resource Provider's help infromation.
• There were a couple of suggestions for the WAYF that will be passed on to the Internet2 Shibboleth team:  1) the ability for a Resource Provider to pass branding information for display by the WAYF, and 2) the ability for a Resource Provider to determine if the WAYF already knows where the user is from, allowing the Resource Provider to provide extra help before linking to the WAYF.
• Resource Provider startup pages should be co-branded between the Resource Provider and UCTrust and/or InCommon, as appropriate.  A UCTrust logo () is available for this purpose at http://www.ucop.edu/irc/itlc/uctrust/trustlogos.html.
• Credential Provider login pages should be co-branded among the Credential Provider, UCTrust, InCommon, and (when applicable/possible) the Resource Provider.
• The current version of Shibboleth implements single sign-on, but not single sign-off.  Future versions of Shibboleth will enable single sign-off, and a portal-based architecture will also mitigate this problem.  In the mean time, though, AYSO will allow the specification of a "logout URL" that can be passed to AYSO when it is first invoked.  If present, the user's browser will be redirected to "logout URL" when the user clicks on AYSO's logout button.  The campus can then perform any processing it deems needed when the "logout URL" is invoked.  It was agreed that the initial implementation of this will support only UCSD, since it will be at least a few weeks before other campuses will be ready.

Policy

Roles, Affiliations, Signet Continued:  A Roadmap [PPT, ODP]

• To date, our systemwide identity management efforts have focused on identification, registration, credentialing, authentication, and simple attributes to achieve UCTrust Basic assurance.

"Managing Roles and Privileges with Grouper and Signet Middleware,"
Lynn McRae and Tom Barton, Spring, 2006 Internet Member Meeting.

• The big picture, however, also includes authorization, more complex attributes, roles, and group management.  Internet2's Signet project provides a good overview at http://middleware.internet2.edu/signet/concepts.html.

"Managing Roles and Privileges with Grouper and Signet Middleware,"
Lynn McRae and Tom Barton, Spring, 2006 Internet Member Meeting.

• Our recent discussions of roles, affiliations, etc. represent a new phase in the development of UCTrust and identity management in general at UC, which raised the issue of developing a roadmap.  It was agreed that we have parallel progressions for UCTrust and each of the campuses:
• UCTrust
1. UCTrust currently enables authentication for simple attributes, the eduPerson set of attributes and UCnetID.  Two levels of assurance are supported, UCTrust Basic and InCommon's unspecified assurance.
2. UCTrust will expand to meet the needs of the campuses.  This will mean, at least, supporting a richer set of attributes describing finer-detailed affiliations, roles, and group membership.  It will also mean higher levels of assurance and alignment with the levels of assurance being defined for federal eAuthentication and InCommon.
• Campuses
1. The campus implements some form of identification, registration, credentialing, and authentication processes and technology.  (All UC campuses are already past this stage, but the level of assurance varies, as does the technology's robustness and compatibility with modern standards like Shibboleth and LDAP.)
2. The campus joins InCommon.  (Because of #1, all campuses are at a point where they can consider InCommon membership, probably without a tremendous implementation effort.  Joining InCommon enables access to many library resources and other services, such as online entertainment.)
3. The campus refines its identity management processes to meet UCTrust's requirements.
4. The campus certifies that meets UCTrust's requirements.
5. The campus implements role-based authorization, privilege management, and group management.
• All campuses agreed to share information about where they are in this progression.  This will enable better planning for services that make use of UCTrust identity services, as well as for enhancements to UCTrust's services and interoperability among campus identity management systems.

Other Issues

• There is interest in presentations by other R1 universities about their identity management systems, as well as by vendors.  Our first university presentation will be by Lynn McRae of Stanford, who will also discuss the Signet privilege management system.  Nicole Lam has a contact at IBM, so we will arrange a session with them, too.
• Five campuses (LBNL, UCM, UCLA, UCSB, UCSC) currently use Sun software for at least a portion of their identity management system, and Berkeley is considering Sun.  San Francisco uses IBM software, and the the other campsues uses a combination of open source and home grown software.  (Note:  All campuses have a significant amount of home grown software for identity management, independent of whether they purchased their a framework.)  It may be worthwhile for IT Strategic Sourcing to look into Sun's support costs.

Other Topics of Discussion

• The University of Texas's "killer app" for identity management was wireless network access, as it was popular with upper management.  We agreed to look into using UCTrust for wireless access, although there are technical difficulties.
• Identification and registration of students varies among the campus.  Some campuses (e.g., Berkeley, Santa Barabara, and Merced) have an in-person process for issuing identification cards, while others (e.g., San Diego) do not.
• UCSD and UCLA have moved to a Shibboleth-based infrastructure for authentication to local applications.  Doing so provides a common API for both on-campus and off-campus applications, better security management, easier sharing of services with off-campus users, etc.

Next Meeting