Directories are the operational lynchpin of almost all middleware services. They can contain critical customization information for people, processes, resources and groups. By placing such information in a common storage area, diverse applications from diverse locations can access a consistent and comprehensive source for current values of key data. In future information technology environments, directories will be among the most critical services offered.
Directories are highly optimized (for reads>>writes) databases that contain key institutional and personal data for use by a wide variety of applications. Directories need ways to describe the sequence of fields in the database (a schema), the names of the fields (a namespace) and the contents of the fields (attribute values). Directories also need indices into the database (identifiers).
Examples of fields in a directory could include institutional status, bookmarks, email aliases, personal photos, permissions, private keys, calendars, etc. Identifiers to access the directory mail include social security number, public key certificates, unique id, email address, etc.
Creating a campus-wide directory service
There are three stages to deploying a campus directory service:
Designing the directory, including its use on campus, policies concerning access and update to its contents, determining sources of information, identfying applications that will make use of the data, etc.
Developing the directory, including a deep technical architecture that captures the design criteria within a robust and scalable implementation, building interfaces between legacy systems and the directory, and .
Operating the directory, including providing users and systems with tools to update information, expanding the application base that uses the directory, and upgrading the infrastructure as needed.
Multicampus and community directory issues
The early drivers for directories are likely to be campus based applications, but the higher ed and research communities will need interoperability between campuses and standards at several levels. For example, there will likely be needs for standardized naming of directory services so that multicampus applications can do lookups across servers. Schema extensions to accomodate research applications may need to be installed at participating campuses. Consistent practices in interpreting the contents of standard schema items would insure that meaning was preserved. Campus and multicampus directory issues should be considered in parallel as an institution develops its local services.
Developing a directory requires careful consideration and balancing of a number of technical parameters. Tradeoffs abound between centralized and distributed management, inclusion of proprietary protocols, replication versus synchronization, etc.
The technical issues are complex enough to be beyond the scope of this document at this time, but the references contain excellent materials on directory technical issues and basic design strategies.
Particular attention needs to be paid to the interactions of the directory and security. The security system is essential for controlling access to the directory; in turn the directory will be storing all of the critical security information within it. Performance factors that improved the security operations may have negative consequences on directories, and vice versa.
The campus will need technical expertise in several related areas: core directory technologies (such as LDAP, X509.3, HTTP), distributed directory technologies (such as Novell, Active Directories, etc.), legacy institutional databases, email (usually one of the high payoff applications to be converted early), and other applications as required.
If there is an existing base of distributed directories and little central authority, then campuses can aim for meta-directories. A meta-directory appears to applications and end-users as a single seamless service, but really constitutes a central broker that directs queries to the appropriate distributed server. Meta-directories can particular problems associated with them, such as multiple and inconsistent versions of common data and performance issues.
The greater difficulties in building a true enterprise-wide directory service in higher ed lies in conducting consensus processes for policy and funding. With their ad hoc data administration environments, many campuses have not crisply defined issues of data ownership and access. A directory project brings all these issues to the fore. Similarly, there are many unresolved issues on directory data concerning privacy, Open Records, FERPA, etc.
The funding of a directory initiative may also challenge campuses. The cost of a central infrastructure includes multiple servers, development of interfaces to legacy systems, and management of the schema. Someone must pay to retrofit key applications to use directories. Departments must be trained in new tools and redeploy their environments to reflect the enterprise service.
Advocacy of a directory initiative should draw senior leadership as befits infrastructural issues. At the same time, there are some external drivers that can be used to build urgency and importance. Federal initiatives in digital signatures for students, scientific communities need to exchange management data, and licensing of scholarly materials are some of the levers that can be used.
There are numerous good resources for information about directories. These include
Understanding and Deploying LDAP Directory Services, by Howes, Smith and Good (Macmillan)
An LDAP Roadmap and FAQ by Jeff Hodges (www.kingsmountain.com/ldapRoadmap.shtml)
LDAP version 3 Specifications (www3.innosoft.com/ldapworld/ldapv3.html)