The CalNet Directory Service at the UC Berkeley campus is based on the Lightweight Directory Access Protocol (LDAP). This document describes what the service offers, how it operates, and how application programs can interface with it. Some of the issues addressed by this definition will change as new applications are modified to take advantage of directory services protocols. Requirements for the current service implementation address both legacy applications that do not have mechanisms to utilize directory service protocols, as well as applications that are directory-enabled.

The CalNet Directory Service establishes a secure, centralized service for obtaining authoritative information about campus-affiliated people and services. Features of this service include:

a) look up services: applications can use this service to obtain the current directory information for students, employees, and other people affiliated with UC Berkeley,

b) authorization services,

c) lower-security basic authentication service.

Several applications currently serving the campus community, such as the shared campus calendar, CalAgenda, and the Laptop IP Service (LIPS) currently use the CalNet Directory Service.

The CalNet Directory Service contains many data attributes relating to individuals and services, and allows controls over which individuals or applications can access particular attributes. It also stores application-specific attributes.

LDAP directories are designed to be readily extensible. As a result, in addition to information about campus people, the CalNet Directory Service could also incorporate other types of widely accessed campus information.

In order to obtain a high level of security, applications can utilize the CalNet Authentication Service (based on Kerberos). This service offers a secure, third-party, mutual authentication process to ensure that the entities using a network resource are who they claim to be. See The CNS Network Authentication Project Site [link] for more information on this related project.

The CalNet Directory Service also provides a less secure authentication service by utilizing the Directory Service userPassword attribute. The password may be passed in the clear over the network.

The Directory UID attribute stores the CalNet ID and can be up to 30, human-readable alphanumeric characters

The UID attribute will be initialized with the UCLink or Socrates account name for each individual. If no UCLink or Socrates account name exists for an individual, an algorithm, based on first, middle, and last names, will create a CalNet ID. The UID must be unique for all participating systems. The Kerberos user principal name is initialized with employee numbers or student ID numbers.

Using the CalNet gateway, individuals may change the default CalNet ID to a preferred CalNet ID.

Any subsequent changes will only be authorized if the individual's name has been changed in the payroll or student database. Only changes derived from the individual's name as recorded in the official databases are allowed. These changes must be requested through the IST User & Account Services (UAS) office.

Any applications utilizing the Directory service must comply with maximum feasible security criteria and these apply to all legs of traffic pathways.

All applications utilizing the Directory service should be aware of security vulnerabilities based on using the less secure Directory authentication service, which relies on the UID and userPassword attributes.

Applications should migrate to the higher security provided by the CalNet Authentication Service as soon as is feasible for their service.

To avoid customer confusion and potential compromise of the Secure CalNet ID (Kerberos) passphrase, application providers are encouraged to refer to the Directory UID and userPassword attributes in terms relating to their individual applications. For example, the "CalAgenda username and password". When applications migrate to the CalNet Authentication Service security, the common usage "(Secure) CalNet ID and password" is appropriate.

Applications must provide a mapping protocol if their application cannot utilize the 30-character CalNet ID.

Data owners are entities who control the data stored in the Directory Service. They are responsible for determining:

a) to whom data may be made available

b) what attributes of their data can be made accessible to others through the use of access controls.

Data stored in the CalNet Directory Service must be restricted to those attributes that contained centralized public information or attributes required to manage application.

Application providers who maintain data through the Directory Service must create an administrative account to be used to perform administrative functions for that service, such as

a) adding, modifying or deleting attribute values.

b) managing ??? processes

Applications to create administrative accounts will be submitted to UAS.

..

a) data definitions

b) getting started, consulting assistance

c) schedule

d) uptime

e) hardware/license specs

Contact [email address] to obtain more information.