Fast Facts About the Directory Service

• Contains information about people at the University.
• Is used by a number of systems for user authentication (login and password verification.
• Receives information from the Human Resources System (PHR), the Student Information System (SIS), and the Affiliates system (managed through PHR).
• Is regularly updated with information with varying frequency. Most information is updated daily, some instantly.
• Uses the Lightweight Directory Access Protocol (LDAP).
• Is designed to protect personal information.
• May contain information that is used to authorize access to applications and/or data.
• Is intended to be a core piece of the user authentication and authorization framework for the University.
• Will be the holder of the primary user name and password for most systems that require authentication including email systems, the calendar and scheduling system (Oracle Calendar), the course management system (ELMS), access to numerous web pages, and more.

At the University of Maryland, we have undertaken to establish a common, centrally supported Directory service. The Directory service will ultimately serve as the primary source of information about people and things at the university when needed to be accessed by network applications. The Directory will serve as the central point of user authentication, which means that when an individual logs into a system they will use the same login name and password as they would use for any other system. In addition, applications that are provided appropriate access will be able to use information in the Directory to make decisions about level or type of access that should be granted. Finally, the Directory is intended to be highly available with 100% uptime, so systems and applications that depend on it can e confident that the service will be operational at all times.

The Directory Service is intended to serve as a resource for the university.

Our effort is to establish a common Directory of information about people and things at the University. The Directory currently contains information about faculty, staff, and students as well as information about the wide range of others who are affiliated with the university in some way. The information about faculty, staff, and affiliate comes primarily from the Human Resources database that is managed by the Office of Personnel. The information about students comes primarily from the Student Information System and is maintain by a number of offices.

Not all information in the Directory is available without some form of login. A careful review of each data element contained in the Directory is done to insure that the level of access granted is appropriate and that it supports the mission of the University. Information that is a matter of public record is made available to unauthenticated access. Every other data element is accessible only through authenticated access. For example, student information is not accessible through unauthenticated access.

The Directory uses Lightweight Directory Access Protocol (LDAP). LDAP uses objects to contain and manage the information it holds. Each object has a unique name or handle, which may be used to uniquely reference that object. This name is called a Distinguished Name, or DN. Each object contains a number of attributes. Each attribute has data type and size. Each attribute may have a single value or multiple values, depending on how that attribute is defined. An attribute may be defined such that a value is optional or required. Finally, each attribute has an associated set of access control records, which may be used to grant or deny access.

A schema defines the objects and attributes contained by an object. The person object is one such object. Each object is defined by a set of attributes. Each attribute within an object has a number of characteristics such as whether or not it is required or the data type for that attribute.

Some information is publicly available, some information is available only to the university community, and some information is available only for specific purposes. Some information that is publicly available includes information on faculty, staff and affiliates. Some information that is accessible only by members of the university community includes information about students. Some of the specific attributes for every entry in the Directory is only accessible for specific approved purposes.

Limiting access to student information is being done to closely parallel the general access to information about students through other means (such as the printed student directory). In order to search the Directory for student information, one must first authenticate to the Directory.

Examples of attributes which are not accessible except for authorized purposes includes passwords, information requested not to be published (home phone/addresses), Social Security Numbers, and the like.

One of the results of a common Directory is the ability to have a common collection of shared information made available to one or more applications. Today, there are relatively few applications which are directory enabled. There are a number of examples of commercial packages designed to work with LDAP directories as the source of core enterprise information. Directory enabled applications specific to the University have already been implemented, and more are likely to be.

Some examples of existing directory enabled applications include:

• Email
• Directory search (email addresses and other information)
  • https://directory.umd.edu/search
  • http://www.oit.umd.edu/staff/
• Central forwarding agent (name@umd.edu)
• CorporateTime scheduling software http://calendar.umd.edu/
• ELMS Course Management System http://elms.umd.edu
• Web sites
  • Authorization/authentication
  • http://www.agnr.umd.edu/AGNRWebAdmin/index.cfm

Some examples of potential candidates for being directory enabled:

• Unique ID
• Portal authorization/authentication
• Dial-up/DHCP access
• Card key access
• Roles based authorization
• Single/fewer sign-on
• Dynamic email lists (e.g., class, department membership)

The Directory is just a part of a larger effort to define the environment within which systems and applications may work in a highly decentralized and network-based world. The middleware initiative uses the Directory as a central part of the infrastructure required to support the environment. In the distributed network environment, a set of common tools and facilities are required to help establish a common framework within which to work.

As this effort continues, additional data elements may be added, additional applications will be designed to use the framework. One of the outcomes of this initiative will be a simpler, easier to navigate environment, with a minimal number of user names and passwords. Applications will need to access only one general resource to make numerous decisions about services, resources, and access rights.