Directory Strategic Vision
Written by Quanah Gibson-Mount, updated 10/30/05
Contents:
This document tries to cover the strategic vision for directory services at Stanford, focusing specifically on the centralized directory services provided by and managed by IT Services. This includes the campus OpenLDAP directory service and the campus Windows ADAM Directory service.
Principles
The goal of Stanford's directory system is to provide a highly stable, centrally administered directory service both for internal use by ITSS and for use by any and all campus systems that need to query LDAP data from the directory. The central directory service is used to store a subset of data from the Stanford Registry systems and the data specific to the operation of the directory service. We must attempt to balance the following concerns:
- A highly stable, and well-tested system or set of systems, capable of handling the full directory query volume of all directory clients, tied closely into its registry source systems, processing updates as they occur.
- Use of industry-standard LDAP technology and authentication mechanisms to ease integration with vendor applications and software developed elsewhere while avoiding locking ourselves into any one vendor.
- A highly secure directory system that provides reliable and secure access controls on data to meet privacy and regulatory requirements including HIPAA and FERPA. Users must be able to control visibility of their own personal information, subject to the constraints of regulatory requirements and university policy.
- The directory must be accessible to both applications and individual users, both through web interfaces and through directory-enabled desktop and mobile clients, particularly e-mail clients.
Given the prevelance of the web as a user interface to applications, a trend which is expected to continue, special attention should be paid to standardized methods for querying the directory via web based applications as the place that the most users will interact with the directory system.
Many Stanford applications need directory data in order to correctly function. The demand for access to the directory continues to rise, and it has become tightly integrated with many of Stanfords core applications. If we are unable to meet the needs of the user community through the directory service, they will resort to getting the data from the source systems, significantly increasing and compounding our integration problems, utilizing non-load balanced systems and data control difficulties.
Technologies
Stable core technologies:
- LDAP protocol version 3 as the underlying directory service
- Kerberos v5 used as the underlying directory authentication methodology via SASL/GSSAPI
- OpenLDAP as the central directory server software using Cyrus-SASL as the client library providing SASL/GSSAPI authentication
- Microsoft Active Directory as the central Windows directory server software
- Webauth V3 for web applications to do directory based queries
- Stanford.Who as the user driven web interface to directory based queries of "phonebook information"
- Stanford::Directory as the supported perl mechanism for directory based queries
- JNDI as the supported java mechanism for directory based queries
- PHP 5.05 or later as the supported php mechanism for directory based queries
Emerging technologies: (see Research below)
- OpenLDAP 2.3, the next major release of the OpenLDAP software. Several smaller new features of use are: back-ldap and back-meta for email clients attribute mapping and uniqueness overlay for enforcing attribute uniqueness on particular directory attributes
- syncRepl, a superior replication technology for OpenLDAP providers and replicas (OL 2.3)
- back-config for server configuration which will enable on the fly configuration changes (OL 2.3)
- dynamic groups instantiation. We currently use static groups on a very limited basis. Dynamic groups will allow us to further integrate with the workgroup manager and give us a more flexible group-enabled environment.
Deprecated technologies: (see Projects below)
- Windows Harvester, the current method for doing replication from the registry to Active Directory, with OpenLDAP as the "middleman".
Other technologies in use: (These technologies are currently deployed and useful in specific circumstances, but either are not attractive for broader use or have a limited scope of applicability -- we are neither recommending expanding them nor recommending eliminating them at this time.)
- Registry document service for courses, organizations, and people. We currently do not have course and organization data in the directory, so the clients have no other choice for those two data sets. For the people data, the directory does not fully reflect everything available at the person document service (such as bio data), and the directory currently cannot structure the data in ways needed for some applications (see weighted attributes under Projects).
- Remedy uses LDAP v2 over SSL to connect to the Active Directory service for its directory information. Remedy is working on a new version of their LDAP implementation, but until it is ready, this is the only way for Remedy to retrieve directory data.
- whois and finger gateway, which allow command line access to directory based queries of "phonebook information". It is most widely used by Eudora users, who pair it with the "Finger" functionality in Eudora for addressbook information.
Projects
First:
- Upgrade to OL 2.3
- Instantiate the value sorted attributes overlay
- Upgrade OS to Linux from Solaris
Next:
- Fully populate ADAM server fed by its own slog from the Registry
- Replace winharvester for AD with its own slog from the Registry
- Develop and deploy the course directory tree
- Continue to expand and refine the schemas represented in the Directory, in particular the eduPerson schema
- Add "calendar" as a service in the account registry and account directory tree
Later:
- Develop and deploy the organization directory tree
- Develop and deploy the shadow directory servers
Research
The following areas should be explored with an eye to their long-term inclusion in our directory strategy. Without more information, it is premature to specifically identify any of these areas for projects, but if the research pans out, they may move from this section into the project section for a full production implementation. Each research project is associated with an initial application that we can use to test the results of the research.
- Integrating workgroup manager into the directory service via dynamic groups. Part of this is already in place, in the form of the privilege group attribute in the person tree for the registry and directory. However, the concept of accounts having privileges also needs to be developed in the registry so it can be propagated to the directory. Once that is done, a process to create dynamic groups in the registry based off workgroup data needs to be developed.
- Implementing weighted attribute support in OpenLDAP. The registry document service allows for structured data, which is one reason that clients use it. The directory currently does not support structuring data, which leads to problems with some attributes where you want to fix the order in which values are listed. This is currently a blocker for the development of the course directory, and is a blocker for some clients to move to using the directory for person data.
- OpenLDAP 2.3 is currently in the early stages of release. It contains several new features that will be of use for Stanford's centralized directory service. http://www.openldap.org/software/roadmap.html contains a list of some of these new features.
- Investigate other attributes currently available in the person or account registry that we may wish to include in the directory as long as they are not bio related. http://www.stanford.edu/services/directory/trees/future_attributes.html contains potential attributes of interest that have already been identified.
- Directories containing restricted data populations that can be used for local or specialized needs.
- Investigate technologies that can allow XML expressions to/from LDAP.
- Investigate the directory becoming a certificate store as part of a campus PKI.
