This paper is a proposed structure for an LDAP-based systemwide directory for the University of California. It is based on the work of of UC's Enterprise Directory Project.
Each of the campuses has their own directory, so the systemwide directory need not meet all of the needs of campus directories. The unique needs of the systemwide directory include:
In conjunction with UC's developing PKI infrastructure, support authorization for systemwide applications, such as UC for Yourself and access to library resources.
Provide a systemwide online white pages service.
Provide the data elements needed to produce the printed UC Directory telephone book.
Support the creation and maintenance of UCnetIDs, digital identifiers for people that are unique throughout the UC system.
The Directory Information Tree (DIT) represents uniquely-identified entries for all members of the UC community. Those entries contain the information required to support the functions listed above, as well as links to the full information maintained by the campuses for each of those people. The overarching principal is to provide appropriately-controlled access to the totality of directory information maintained about the members of the UC community while minimizing the operational impact of doing so.
The following diagram illustrates the overall structure of the Directory Information Tree (DIT):
The following list of synchronized attributes was selected to be the appropriate set to support the required functions of the systemwide directory. This set need not be nearly as extensive as any campus directory, since the DIT structure outlined above allows for access to all campus attributes, albeit via an indirect reference through the synchronized seeAlso attribute.
It should be noted that this set requires very little extension of the eduPerson 1.5 object class. In particular, only the following additional attributes are required:
SSN (possibly hashed)
Birth Date (possibly hashed)
UCnetID
For inclusion in the systemwide UC Directory printed telephone book, there are other required extensions to eduPerson, but nothing that is not already required for that application.
The following table summarizes the synchronized attributes.
The Required attributes are in that category either because they are required for UCnetID assignment or are required by eduPerson.
The Required for White Pages and Phone Book attributes are in that category because they are required for inclusion in the printed systemwide telephone book or in the white pages services to be developed as part of this project.
The Recommended attributes are encouraged for implementation, but not required. They will be synchronized into the systemwide directory if present.
The Optional attributes will be synchronized into the systemwide directory if present.
Notes:
In the Access column, both "Public" and "Authorized Applications" imply read and search access permissions only. "Public" is conditioned by the presence of the Include in Systemwide White Pages attribute; when Include in Systemwide White Pages is not present, "Public" is the same as "Authorized Applications." "Directory Maintenance" actually applies to all attributes and implies all forms of access permissions.
In the Inter-Campus Resolution column, "Separate Listings" is used when otherwise-unrelated multiple values of multiple attributes need to be grouped. For example, listings in the systemwide telephone book require that title and phone number, among other attributes, be grouped with campus name. Attributes in this category will have a sequence number appended to a common base name so that, for example, ucTitle_1, ucTelephoneNumber_1, and ucCampus_1 would belong to one listing for a person;and ucTitle_2, ucTelephoneNumber_2, and ucCampus_2 would belong to a second listing for the same person. When appropriate, multi-valued attributes are also maintained with the same values. In this example, the commonly-implemented telephoneNumber would be populated with all of the unique values in the ucTelephoneNumber_* attributes.
While all synchronized attributes can be modified by the "Directory Maintenance" group, they will not generally be modified outside of the synchronization processes. The way to update information is to do so in the appropriate campus system and resynchronize.
The systemwide directory is designed to be a common repository that is maintained collectively by the campuses through their normal directory maintenance procedures and a set of OP-maintained synchronization processes. While this allows for the creation of the directory with a minimal amount of operational impact, it does imply additional cooperation among the campuses under certain circumstances. These circumstances are:
At the time a new network identity is created for a person at one campus, there needs to be a check to determine if this person has already been identified at another campus (and assigned a UCnetID). This check can be implemented as a Web Service and incorporated into campus identity management systems to minimize the operational impact of this.
Whenever an inconsistency is suspected in the one-to-one mapping between UCnetIDs and people, that issue will need to be resolved with consultation among all of the campuses that have identified this person or these people. In addition to updating the mapping between UCnetIDs and people, some or all of those campuses may need to make changes to their directories in order to resolve the inconsistency. [An alternative would be to allow any campus to modify the mapping for all campuses. This would be easier to put into operation, if acceptable to everyone.]