Appendix D

Strategy for an NIH-Wide, Secure, Centrally Coordinated Electronic Directory

Report and Recommendations

April 16, 1997

Prepared by

Prepared by: AMG, Central Directory Working Group

April 16, 1997

THE NEED

As the activities of NIH come to rely more heavily on information technology the need for a computer based NIH-wide directory becomes more critical. The purpose of this directory will be to reliably identify and describe people and other resources associated within NIH. It will be used directly by people and as a central point of coordination for other systems which manage or track resources. Thus it will be an essential and fundamental component of the future computing infrastructure at NIH. For these reasons the broadest possible scope should be taken into account in the design process. The following capabilities must be considered in its design:

· Extensibility: There must be a mechanism to add new classes of resources (e.g. mailing lists, organization units) and attributes which describe these resources without disrupting the existing directory structure.

· Security: The directory should have mechanisms to ensure that it is only updated by those users with appropriate permissions. In addition there should also be mechanisms which will allow the directory to function as the basis for NIH wide security needed to implement single logon and a secure intranet.

· Authority: The directory should be the definitive source for the information contained within it.

· Human Readability: The directory must be easily accessible to people. This will allow it to serve as a white pages for NIH. To facilitate use, the directory should be available in a number of ways including email address books and the web. Search mechanisms should be provided to make it easy to find information in the directory.

· Machine Readability: The information in the directory should be available to other systems via standards based protocols. There should also be mechanisms that allow access by and synchronization with existing NIH systems.

SCOPE AND OBJECTIVES OF THE WORKING GROUP

The working group focused its efforts on defining the role of the directory within the NIH environment, its broad requirements, and the technical, organizational and personal, interfaces that are needed. Recognizing that establishing and populating the directory will need to be a phased and incremental process, the working group also developed recommendations as to initial implementation.

ISSUES

Several issues must be resolved in order to implement an NIH wide directory. These include:

· Maintenance: How are people to be added to and deleted from the directory ? What are the mechanisms to be used to move people between ICDs?

· Attributes: What attributes (i.e. items of information) should be included in the directory, what is the mechanism for update of the directory schema?

· Updates: There must be a mechanisms and policies to ensure that the information contained in the directory is accurate and current.

· Management: How should data flow between central NIH resources and the ICDs?

RECOMMENDATIONS

Use the Lightweight Directory Access Protocol (LDAP). Establishing an NIH wide directory which meets the criteria outlined above presents challenges on many fronts. Fortunately many of the issues NIH faces are shared by other large organizations and by users of the Internet. Recently there has been very strong, industry wide convergence on the Lightweight Directory Access Protocol (LDAP) as a basis for establishing both corporate and Internet wide directories. The current versions (version 2) and the proposed version 3 of LDAP would provide a strong technical basis for the directory and would address a number of the requirements including: security, human and machine access and extensibility. Basing the directory on a widely accepted open standard also has benefits in terms of campus wide use of directory information, cost savings due to the availability of commercial products and controlled access by users outside of NIH. The exact design of an LDAP based directory is beyond the scope of the this working group, and it is recommend that a new working group, with appropriate technical expertise, be formed to deal with this and other technical issues.

Define Unique Personal Identifiers. Integration with existing systems is a very important issue. Two actions must be taken to accomplish this. First a unique identifier for all people (and other entities if needed) listed in the directory should be established and stored in the directory. This identifier will be used as a key to link existing systems to the directory information. The definition of the exact nature of this key is left to a future group, but it is recommended that this definition take into account the broadest possible future uses of the directory. In addition, to facilitate integration with existing systems, the directory information should also be easily accessible to relational databases.

Establish Functional And Technical Working Groups. The information to be contained in the directory must be carefully defined. It is recommended that a working group which includes representatives from NIH major information systems and the user community be formed to establish a schema and appropriate data definitions for the directory. This group should work closely with the technical working group. In addition to the requirements of NIH systems, directory standards established by HHS and the Internet Engineering Task Force (IETF) should also be considered, along with other requirements placed on the directory such as attributes needed for maintaining a secure Intranet. Additional work is also required on other issues, including the policies and procedures required for updating the directory when a user moves between ICDs. It is recommended that following actions be taken to begin the development of an NIH wide directory.

· Establish a technical working group to determine the design the system. This group should have representatives familiar with both LDAP based directories and relational databases.

· Establish a user oriented working group to establish the directory schema and provide input as to user requirements for the directory. This group should work closely with the technical group to ensure that user requirements are appropriately implemented. A preliminary list of attributes and major NIH systems which will interact with the directory is appended to this document.

Declare Directory Presence A Prerequisite For NIH Services. There are a number of management issues to be considered. Most importantly, for the directory to serve its intended purpose there must be policy based incentives for maintaining the information. To achieve this goal it is recommended that existence in the directory, and confirmation of directory information, become a requirement for the use of NIH resources similar to the current requirement for a valid ID. It is also recommended that this be an inclusive requirement which does not preclude the addition of outside users as required by ICDs or other systems.

Establishing a fully integrated NIH wide directory is significant task and will probably take several years to complete. The following priorities are recommended in order to establish and realize some benefit from the directory as quickly as possible:

· Provide "White pages" functionality and the ability to directly browse basic user information through LDAP enabled email clients and the web.

· Establish the unique identifier for NIH personnel to allow new systems to be developed compatibly with the directory.

· Integrate directory information with existing systems.

Once the directory is established appropriate policies should be put into place to ensure that the information is properly maintained.

COSTS

It is difficult to estimate the total cost of implementing this directory with knowing its overall design. However the costs do break down into three broad areas:

· Initial implementation. The cost of designing and establishing the directory infrastructure.

· Maintenance. The cost of maintaining directory information. Again this will be highly dependent on the design of the directory. It is recommended that to minimize cost, the procedures for directory maintenance be integrated into existing activities to as great an extent as possible.

· Integration. The cost of integrating directory information into existing systems. This will be highly system dependent. The overall cost could be helped by establishing some central projects which could be used by a number of systems. An example of this is to establish a mapping between the directory user ID and Social Security Number which is currently widely used for identifying people.

A preliminary estimate of actual costs for each of these areas is attached.

Working Group Membership:

Cherie Fisk (OD)

Bill Jones (DCRT)

Steve Fellini (DCRT)

Charles Havekost (DCRT)

Jim Brunetti (DCRT)

Jim Rutherford (NLM)

Linda Alger (ORS)

Lynda Bennett (NICHD)

Ralph Van Wey (NHLBI)

Roger Fajman (DCRT)

Jed Rifkin (NCI) Chair

	Estimated Total M/M	Estimated NIH M/M	Estimated Ctr M/M	Months Duration	Completion Month
Definition Phase	30	12	18	5	5
Directory Objectives
Policy & Procedure Implications
Core Directory System Concept
Directory Role & Services
Data Accuracy
Adds, Deletes, Changes
Deregistration
Data Aging and Validation
Unique Identifier
Public Key Certificates
LDAP Interfaces
SQL Interfaces
Analysis of Existing Systems (24)	36	12	24	6	8
Incorporation Of Unique Identifier
Directory Interface Requirement
System Change Requirements
Prelim. Cost & Schedule Estimate
System Design Phase	36	12	24	6	14
Directory Database
Directory Software
Data Acquisition And Validation
Public Key Certificate Management
End User Data Maintenance
AO Data Management
Hdwre & Sftwre Configuration
Existing System 1 Change
Existing System 2 Change
Existing System 3 Change
Development and Testing	36	18	18	6	18
End User Clients
AO Clients
System 1 Integration
System 2 Integration
System 3 Integration
Implementation and Operation	36	18	18	12	24
Installation And Conversion
Pilot Operations
Production Operation And Management
Total M/M (GS-13 equivalence)	174	72	102
Estimated Monthly Rate		$10,920	$15,600
Extended Cost	$1,984,320	$786,240	$1,198,080

Recommendations	Initial Step(s)	Proposed Agent
1. Create a Central Directory Functional Committee to plan and Prioritize the usage and attributes of the central directory.	Endorse the Central Directory Concept Draft committee charter for CIO approval	AMG subcommittee
2. Create a Central Directory Technical Committee to design and coordinate the implementation of the central directory. Including LDAP and SQL access.	Endorse the Central Directory Concept Draft committee charter for CIO approval	AMG subcommittee
3. Create an overall NIH central directory implementation plan based on LDAP.	Prepare plan Provide resources	AMG subcommittees CIO
4. Declare directory presence a prerequisite for NIH services.	Endorsement	CIO/NIH Director
5. Establish the following implementation priorities White Pages Unique Personal Identifier SQL access to directory information	Endorsement	CIO