- DRAFT -

UC Enterprise Directory 8/20/2002 Project Meeting Notes

Tuesday, August 20, 2002, 10:00-3:00
1111 Franklin, Room 9204
UCOP

Attendees

Rob Chevalier (UCB)
Jann Fong (UCB)
Carol Miller (UCD)
Randy Moory (UCD)
Jatinder Singh (UCD)
Katie Stevens (UCD)
Marina Arseniev (UCI)
Brian Roode (UCI)
Don Worth (UCLA)
Albert Wu (UCLA)
Andrew Tristan (UCR)
Arlene Allen (UCSB)
Eric Goodman (UCSC)

Elazar Harel (UCSD)
Jim Madden (UCSD)
Frank Wittemore (UCSD)
Bill Gayle (UCSF)
John Morehead (UCSF)
Chet Burgess (UCOP)
Michael Clune (UCOP)
Patrick Collins (UCOP)
Kathy Keller (UCOP)
Neil Ratzlaff (UCOP)
Jerry Wilcox (UCOP)
David Walker (UCOP - Chair)

Campus Updates

Berkeley
Berkeley has run a campus directory since 1995; LDAP was introduced in 2000. The backend database is Sybase. Authentication is done with Kerberos. Identity matching is done on Social Security Number (SSN) and birth date. The directory supports the concept of public and private information; only authorized people can access private information. Current challenges include:

Including alumni, retired employees, emeriti, etc. in the directory.

Achieving better granularity of role information to support authorization.

Policies to allow test entries for application development.

Implementing the eduPerson 1.5 object classes.

Making the servers more robust.

Enhancing the schema for departmental listings (yellow pages).

Marina Arseniev asked if Berkeley is considering the LDAP service in Sybase 12.5. Jann Fong answered that they plan to look at it. It was mentioned that Sybase 12.5 may have an issue with providing authentication services.

Davis [handout - MS Word]
Davis currently runs an Oracle-based directory and account management system called Mothra, using feeds from SIS, Payroll and other sources to create an identity for all people who need computer accounts. An LDAP-based white pages directory is published from Mothra. Kerberos is used for authentication by all portal-based applications; some departments use Kerberos for LAN server authentication.

The campus has started an enterprise directory project. The outcome of this project is intended to be the official record of campus identity; administrative workflows will be modified to ensure that people are registered with the enterprise directory before being entered into SIS, payroll, etc. Accurate identity management is the current challenge.

Irvine
AdCom and NACS (Network and Academic Computing Services) are working together to provide directory services.

AdCom provides an LDAP directory, using OpenLDAP, that is tied to the campus Kerberos authentication service provided by NACS. They use the eduPerson schema, plus attributes required by uPortal. Students are included, unless they have opted to block the publishing of their information. AdCom is currently working on the definition of workflow-required roles for administrative applications.

NACS has run a CSO (Ph/Qi) name server for about ten years; it now also is accessible via LDAP. That directory is the source of UCInetIDs and the campus Kerberos principals.

Los Angeles
UCLA has had a unique "UID" identifier for employees and students for a number of years. It's eight digits long, plus a check digit (nine digits total), and they "go to great lengths" to ensure uniqueness. There is a database based on eduPerson 1.0 that is not accessible via LDAP, but is via a Web Services interface. There is also a white pages service that was originally based on Ph/Qi, but is now LDAP-based. All of these databases are keyed on the campus UID. There is currently no common authentication service.

UCLA is currently looking at the following issues:

Adding other people, such as temporary workers.

A common authentication service.

A more flexible and less well-known identifier for login IDs.

Whether electronic mail should be "ubiquitous." If yes, this would raise the issues of how to provide access to everyone, and how to keep the address current in the directory. It was mentioned that UC Davis has already said that electronic mail is official.

Riverside
Riverside has an Oracle-based database of employees. Its content is maintained by departmental coordinators; there is no current feed from PPS. They now have an LDAP directory and are heading toward using Kerberos for authentication. The LDAP directory provides white pages and mail routing.

San Diego [handout - MS Word]
UCSD currently provides a 14,000 entry web-based directory as part of its Telephone Management System (TMS). They also provide an LDAP service; its content is a subset of the prototype of the Campus Integrated Directory (CID).

The CID is intended to support a single record per person, as well as a system of roles and heirarchies. The campus started a Single-Signon Project in June to determine CID requirements to support authentication and authorization.

San Francisco [handout]
San Francisco has been providing a Ph/Qi server for a long time, and the Library has an LDAP server that provides white pages and controls access to library resources.

The campus is currently looking at various directory-related issues:

Platform

Schema (They will base their schema on eduPerson 1.5)

Group management (static vs. dynamic)

Population (students, "special" students, employees, employees of UCSF affiliates, etc.)

UCSF is working on the implementation of an identity service that is based on PPS's IID service that was developed by UCSF for UC systemwide. They will be adding a SOAP interface and enhancing the identity matching criteria. Giving identities to patients is controversial, but UCSF is adding hooks to identify patients.

UCSF has a Department System (DEP) that records organizational heirarchy for authorization purposes.

Santa Barbara - [handout]
Santa Barbara has had a campus registry for a number of years that became LDAP-based in 1997. They use iPlanet software on Wintel servers, fronted by a load balancer. The growth of attributes is slow, as each one is negotiated with the original provider of the information to ensure that appropriate use and that maintenance works smoothly. UCSB does not currently have a single identifier for people.

Santa Cruz
Santa Cruz had a project about a year ago to develop a person registry, but it was stopped due to lack of funding. The campus uses Kerberos for authentication, as part of their Athena infrastructure; also many applications use a "Student ID / PIN" database. Santa Cruz recently purchased PeopleSoft's student administration module; it can utilize LDAP-based authentication, but Santa Cruz is not using that feature right now.

Uses of Enterprise Directory Services

As outlined in the agenda, enterprise directories are used for the following purposes:

Identity Management. An enterprise directory is usually viewed as the definitive source for the unique, one-to-one mapping between people and enterprise-wide identifiers.
Online and Printed White Pages. We are also starting to see some work at providing departmental listings (i.e., yellow pages).
Electronic Mail Routing. Some campuses have established a campus-wide name space that maps to mail-server-local name spaces for users' mailboxes.
Authentication. X.509 authentication is largely in the future, however. More commonly, a Kerberos service, associated with the directory, is used for authentication.
Authorization. Enterprise directories are often used to define roles for people with respect to applications. This is, most often, tied to particular applications or portals (e.g., PeopleSoft or uPortal). Some campuses are starting to think about heirarchy-based roles that can be used generically across multiple applications; the right model for assigning roles is not yet clear.

A UC system-wide directory (as opposed to campus-wide directories) is needed for the following purposes:

Maintenance of an identifier (the UCnetID) for people that is unique and persistent across all campuses.
Publishing of the UC system-wide Directory.
Authentication and authorization for applications that are used system-wide.

There was some discussion of whether each of these campus-wide and system-wide directories should be structured as a single LDAP service, or as multiple LDAP services. For example, portals can make extensive use of an LDAP directory to manage workflows and users' roles. It may not be appropriate to burden an LDAP server used for white pages and authentication, for example, with the portal's potentially extensive object class; it may be better to create a separate, but linked and/or synchronized, LDAP server for the portal's exclusive use.

It is also the case that LDAP is used for many purposes other than people registries. Those other directories will likely be managed separately.

Membership in Directories

"Faculty, staff, and students" does not describe the extent of the people identified in enterprise directories. For example, UCSF needs to identify employees of affiliated organizations, and UCI identifies vendors for billing inquiries. UCLA keeps applying students and alumni in the directory, but without the "student" affiliation attribute. These are probably campus-local needs, but we should not preclude the possibility of needing to assign a system-wide identity to other groups, as well.

In general, there was a consensus that there is not much harm in assigning identities to anyone, as long as affiliations are kept straight. There is, however, a cost of maintaining records for any group of people, particularly if automated maintenance is not practical.

Content of Directory Entries

Version 1.5 of eduPerson specifies the right set of object classes for exchange of directory information among different institutions. Within UC, however, we should extend eduPerson, at least as necessary to support the maintenance of the UC system-wide directory. There was differing opinion as to whether campuses should be encouraged to implement common object classes, beyond those needed by the system-wide directory. This will be resolved after an examination of the campuses' directory schemas.

Affiliations and Roles

While it was generally agreed that it is premature to have a detailed, system-wide discussion of roles, it was believed that a discussion of affiliations is in order. EduPerson suggests a small set of affiliations (faculty, student, staff, alum, member, affiliate, employee), but acknowledges that this set will probably grow in the future. At UC, people have seen the need to distinguish, for example, members of the Academic Senate from people who teach classes, or undergraduate students from graduate students. A subgroup will be formed to propose an appropriate set of affiliations to be used within UC. [A role describes a person's relationship to a set of functions or processes; examples might include low-value buyer or student advisor. An affiliation describes a person's relationship to the organization; examples might include student or staff.]

Policy and Access Rights

The information in enterprise directories comes from multiple sources, each with their own policies governing the use of that information. In general, those policies must still be observed when that information is moved into an enterprise directory. In any event, there needs to be a negotiation between the directory service provider and the office of record for each attribute in the directory.

An interesting wrinkle that has been observed at Irvine and other campuses is that an office of record will grant access to an application, only to find in the future that the data has been used in other, non-negotiated, ways by the implementors of the original application. The original agreement may also require some form of verification of the application. This tends to be an artifact of granting access to information for applications, rather than people. Unfortunately, such access permissions are often hard to avoid, so implementors must be responsible with regard to this issue

There were differing schools of thought over the "ownership" of directory data (and management of network identity):

Some campuses prefer that the directory be entirely fed from other applications (e.g., Payroll and SIS), owning none of the data itself.
Other campuses see the enterprise directory as a service of an organizational unit that has specific responsibility for identity management; applications like Payroll and SIS would get identify information and other directory data from this service.
A third position, somewhere between the first two, is that there would be a central identity management application and repository, but that the crucial "Is this a new person, or one that the University has already identified?" question is answered (for all applications) by the people who currently answer that question for each of the applications (e.g., Payroll and SIS). This has the advantage of minimizing the disturbance to the existing workflows of hiring employees and admitting students, but requires agreement on how to answer the question.

UCnetIDs and System-Wide Directory Needs

A number of issues were raised with respect to the management of UCnetIDs and the requirements of the system-wide directory.

It was reaffirmed that there is a need to manage identities in the context of the entire UC system.
It was also reaffirmed that system-wide identity does not suffice for all local needs, mainly because of the different communities that must be supported.
Some campuses have observed that the identity matching algorithm for UCnetIDs does not always provide a one-to-one match between people and UCnetIDs, although the frequency of this happening was not discussed. Also, the fact that UCnetIDs are assigned on an overnight basis makes them less useful to the campuses. For the campuses that assign local identifiers at the point of initial entry, a Web Services interface for assigning UCnetIDs in real time was discussed. UCSF is doing some work in this area for their local identity management that may help.
The campuses are anxious to know what they need to provide to UCOP to support the assignment of UCnetIDs and for maintenance of the system-wide directory. David Walker volunteered to collect that information. It is not anticipated that there will be large changes from what is currently provided.

Directory Design Issues

The issue of what information should be placed in an enterprise directory, as opposed to application-specific databases, came up in a number of contexts. While this is a design issue that should be addressed for each individual data item, the following general issues were identified:

An enterprise directory should have the data items needed to support its functions of identity management, white pages services (and, perhaps, yellow pages), electronic mail routing, authentication, and authorization.
If some data item is used by only one application, it should be in that application's database. Care should be taken, however, to consider data items that are likely to be used by multiple applications in the future. Care should also be taken to ensure that two applications' apparently-common data items are truly common. For example, even something like "home address" may have different interpretations or maintenance requirements in student and payroll systems.
An enterprise directory system must be highly robust and responsive. Care should be taken with data items that may adversely affect the enterprise system's availability or performance.
Care should be taken with data items that have usage restrictions that are dictated by policy or law. Placing such items in a directory will likely require two implementations of access restrictions, since there are usually other items in the application's database that require the same access restrictions. These issues are even larger, of course, if the access restrictions require a human decision.
Consideration should be given to appropriate currency of information. This can affect placement and/or update processes.
A growing number of application systems require the use of LDAP to implement some or all of their application-specific databases. It should be recognized that the fact that an application-specific database may built with the same technology used by the enterprise directory does not affect the issues listed here.

Next Steps

David Walker will collect the requirements for the system-wide directory.
A subgroup will be formed to propose an appropriate set of commonly-defined affiliations.
David Walker will compile the object classes used in the campuses' directory schemas. Depending on the outcome of this work, a subgroup may be formed to address common directory attributes that are not included in the requirements for the system-wide directory.

David Walker - 9/4/2002