Skip to main content

The UC Common Authentication Project (Terry Ryan, Associate University Librarian for Systems, UCLA, with CDL staff)

June 24, 1998 Author: CDLCategories:

Systems that offer access to confidential or proprietary information require methods of identifying users and permitting them to use the resources for which they are authorized.  Traditional computer systems have required a user to enter an ID and “secret” password to obtain access, but this method does not offer a high level of security and is not easily scalable in a networked environment.  Institutions like UC, with its large community, and its multiple applications and platforms, need a strong, scalable system that separates user identification and authorization.  The UC Common Authentication Project, which began in 1997, seeks to meet those needs for UC.

Permitting access to confidential or proprietary information actually involves three processes: authentication, verification of a user’s roles and attributes, and authorization.  Authentication is identification of an individual — in other words, it answers the question, Who is this person and how can that identity be confirmed? Verification of users’ attributes and roles is done via a directory entry, where more information about the user is stored.  Authorization allows the identified user to use certain resources or perform certain actions, based on their confirmed roles or attributes — for example, to see his or her own personal benefits information or search a database that UC Irvine has licensed only for its faculty.

A full authentication service has the potential to simplify the use of various abstracting and indexing and full text databases.  Passwords eventually can be phased out, the cumbersome process of maintaining a list of IP addresses for verification may be eliminated, and processes to extend services and privileges will become more efficient.  Several “self-service” goals for CDL systems and services, such as patron-initiated requests and status checking, would be streamlined by stronger systemwide authentication.  Negotiations for commercial information resources have included discussion about the vendors’ ability to support emerging authentication methods.

Background

In July 1997, the Joint Operations Group (JOG), a planning group that advises AVP M. Stuart Lynn, of Information Resources and Communications, on information technology, resource allocation, standards, and issues, endorsed a proposal for a UC Common Authentication Project (UCCAP), with a multi-campus Authentication Working Group.  The aim of UCCAP is to produce a UC Common Authentication System (UCCAS), which will “provide UC-wide strong authentication which will eventually support a broad range of applications and services.  “This goal “envisions providing a ‘network passport’ for every UC faculty, student, and staff” that would be recognized by other campuses and could be used “for access control, digital signatures, and other uses.”

The Authentication Working Group has investigated two access control options: Kerberos and Public Key Infrastructure (PKI), based on Public Key Certificates (PKCs). Kerberos, developed by MIT in the 1980s, is intended for a closed community with a central administrator.  Although it provides some advantages over PKC technology, it is more vulnerable (since a single database holds all the keys), does not support digital signatures, does not scale well, and, for the most part, cannot be used by unaffiliated systems.  Public Key Certificates, on the other hand, are designed for general commerce without a central administration, can support millions of users, separate the authentication and authorization functions, can support digital signatures, are supported in major web servers and browsers, and can be used by unaffiliated systems.  Recommendations now integrated into the project include the following:

  • UC-wide authentication should be based on PKC technology rather than Kerberos-based systems.
  • UCOP should take the lead in developing standards and practices for a PKI and related directory services.
  • Campuses should be responsible for campus-specific deployment of the standards.

Current Work

Project team members are currently developing a prototype authentication system at UCOP that incorporates all three parts of access control (authentication, directory, and authorization).  The prototype will include a UC Certificate Authority, a University Directory that identifies user attributes and roles, and authorized access to sample applications, including the Melvyl Web system and BENCOM, an employee self-service system that allows a user access to his or her benefits information.  At the campus level, four campuses (UC Davis, UC Irvine, UCLA, and UC San Diego) have certificate servers available and are ready to work with UCOP to test access to the Melvyl Web system and BENCOM.

The Authentication Working Group continues to explore technical and policy issues.  Those with the most potential impact on libraries are the following:

  • Portability of certificates among platforms.  Certificates are “happiest” when tied to one machine for one user.  The Working Group is investigating options for using certificates in library public workstations and computer labs.
  • Management of certificates, including revocation in case of compromise.
  • Strong client support and user training. The use of certificates is not transparent, and users will need documentation and troubleshooting help.
  • Possible need for different kinds of certificates (e.g., to access library systems vs. personnel information) requiring different levels of identity verification (e.g., issued over the network vs. issued only after display of a picture ID with Social Security number).
  • Certificates for non-UC library patrons.  The UCCAP is focused on UC faculty, staff, and students.  Support for non-UC users may require departmental issuance of certificates.
  • Confidentiality of user information.  Certificates are a pointer to directory information about certificate holders. Privacy and confidentiality concerns may affect the content of certificates UC supports.

CDL is represented on the UCCAP planning groups since authentication decisions could have significant impact on libraries as we grapple with how to control access to our digital collections and services.  Several UC library staff are also participating in parallel campus authentication initiatives, and many more could become involved in answering questions and solving user problems if the prototype system evolves into a production system.  To monitor UCCAP issues and progress, check their web site: <http://www.ucop.edu/~authuser/cap/>.