# Presentation: 659304

## “Strawperson” NIH Directory Service Architecture

- NIH AMG Technical Subcommittee

## Requirements

- Support access via LDAP v2 (v3 future)
- Support access via ANSI SQL and ODBC
- Support an X.500 directory information model
- Provide high availability via server replication and automatic failover

## Requirements (continued)

- Provide mutual authentication
- Provide for hierarchical management

## Components

- Client Web browsers and other applications
- Directory servers
- Directory update Web application service
- Relational DBMSs

## Directory Logical Model

- o=NIH, c=US

- ou=NIDA

- ...

- minimum schema

- ou=NLM

- ou=IMPAC

- ou=NLM

- ...

- enterprise level

- ICD level

- .
- .
- uid=nnnnnnnnnN
- .
- .

- .
- .
- uid=nnnnnnnnnN
- .
- .

- No standard for ICD DITs

## Directory Physical Model

- query*

- query*

- query

- client query
- software

- minimum
- schema
- replication
- (LDIF)

- * query needed for repopulating directory entries

- LDAP
- query

- SQL query

- Users & Services

- Information Sources

## Physical Model

- Centrally operated servers for O=NIH
- ICDs use central server **or** provide their own, linked to top level by referral

## Central Directory Physical Implementation

- Replicated, homogeneous, geographically separated servers
- at least 3 on Bethesda campus
- at least 1 each in RTP and Frederick
- Load balancing and failover
- Per site administration and monitoring
- Sync protocol: DISP or proprietary

## High Availability

- Tactical
- ICDs responsible for fault tolerant operation
- Require geographically separate replicas?
- Future
- ICD (master) servers maintain read-only replicas on central server
- Requires replication interoperability

## SQL Access

- Tactical
- RDB of minimal schema data updated periodically from central and ICD servers
- Update via LDIF or tree walk using LDAP?
- Data cleansing at this step?
- Future
- Replication back to directory server using SQL data source

## Security

- Hierarchical Management
- ICDs have update access rights in own OU
- Ad hoc update access rights to common directories, e.g. yellow pages

## Directory Server Authentication

- Authentication by directory server-specific mechanism
- Netscape: X.509 certificates
- NDS: Netware client
- NT 5: X.509 certificates or Kerberos
- X.500: ?

## Ancillary Database

- Maps NIH UID to individual identifying information (e.g. SSN)
- Used to maintain same UID for life of individual

## Deregistration

- Internet-enabled applications
- Check for existence of directory entry for individual by NIH UID
- Can be done by application or server
- Legacy applications
- Map registry accounts to NIH UID
- Check for existence of NIH UID in directory
- Deferred registry update from directory

## Issues and Problems

- Performance: will searches across ICD directories perform and scale well?
- Organize by object class above ICD?
- LDAP referrals: do they really work across heterogeneous directories?
- No standard for DNs across ICDs?
- Private info in directories/DBs? Access?

## Issues and Problems (continued)

- No standard for DNs across ICDs?
- Implications of DNs that can change?
- OK to store private info in directories and DBs? Adequate access control?
- Need to maintain audit trail?