# Presentation: 090136

## “Strawperson” NIH Directory Service Architecture

- NIH AMG Technical Subcommittee

## Changes from Draft 2

- More ICD control of directory
- structure
- updates
- physical implementation
- More evolutionary
- mandatory structure at top level
- guideline structure for ICD subtrees

## 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
- NOS and server OS security registries

## Directory Hierarchy

- o=NIH, c=US

- AMG **mandatory** structure

- uid=nnnnnnnnnN

- ou=NIH CA

- ...

- minimum schema

- directory update service

- AMG **recommended** structure

- ou=DCRT

- uid=nnnnnnnnnN

- ou=DCRT

- replicated
- homogeneous
- servers

- ICD server

## Directory Hierarchy

**common optional attribute set***

**common required attribute set**

**location references**
**(enterprise only)**

-  email:
-  telephone:
-  fax:
-   .

-  uid=nnnnnnnnnN
-    .

- DCRT person

-  account=
-    .

-  ou=DCRT
-  ou=NCI
-   .

- Enterprise person

**DCRT req./opt. attribute set**

- *Attributes defined in the “common optional attribute set” have meaning based on the scope of the namespace in which they are found.

- uid=nnnnnnnnnN

- ou=NIH CA

-  email:
-  telephone:
-  fax:
-   .

-  uid=nnnnnnnnnN
-    .

- d.u.s.

- o=NIH, c=US

- ou=DCRT

- ou=DCRT

- uid=nnnnnnnnnN

- ...

## Directory Hierarchy

- All persons with UIDs represented at topmost directory level using Lightweight Internet Person Schema
- Distinguished name form of NIH UID persons in directory *“uniqueIdentifier=nnnnnnnnnN,o=National Institutes of Health, c=US”*
- ICDs represented at topmost directory level
- Replicated homogeneous directory servers store topmost level information; updated via directory update service
- Minimum person attribute schema required within ICD namespaces when representing persons for white page lookup (e-mail, fax, telephone, etc.)
- NIH UIDs used within ICD namespaces
- UID entries have organizational unit references to facilitate information synching to sub-namespaces

## Directory Hierarchy- Pros

- Stresses uniqueness of UIDs (not more than one “uniqueIdentifier=.., o=NIH, C=US” allowed)
- Partitioning allows locally administrated namespaces
- Partitioning of information in namespaces allows ICD-specific uses of directory services via ICD-specific objectClasses (e.g., transistion of legacy namespace into NIH UID namespace)
- Allows scoping of attributes
- More than one ICD can represent person data using NIH UID as common key

## Directory Hierarchy - Cons

- Topmost directory level distinguished names do not contain common name. Distinguished names will be of little help for user identification without additional lookups (application specific). Could be problematic when doing directory maintenance.
- Full organization affiliation of person not represented. Define attribute and naming scheme for UID entries?
- Some CA software does not support relative distinguished names of “uniqueIdentifier” (e.g., Netscape CA 1.x)

## Directory Hierarchy Issues

- How is directory going to be accessed most frequently? Is hierarchy optimized for this?
- Non-NIH personnel (grantees, ...). Have separate namespace at top level (e.g., cn=grantee, o=NIH, c=US)? Some particular defining entry attribute?
- Require a personnel organizational unit within each ICD namespace to facilitate person lookup within all namespaces?
- Admin groups needed within hierarchy to indicate membership and facilitate modifications of ICD level admin access

## Directory Information Schema

- Lightweight Internet Person Schema (LIPS), 37 common attributes (general, personal, organization, security,ancillary), used for defining white page oriented entries
- Reference http://www2.netapps.org/netapps/lipschemafinal.html
- Co-sponsored by Network Applications Consortium (NAC), Microsoft, Netscape, Lotus, Banyan, Worldtalk, Zoomit.
- NIH-wide customized objectclasses can be defined for use within any NIH directory namespaces

## Directory Information Schema - Issues

- LIPS makes sense only for white page oriented entries. Other objectclasses need to be defined as NIH standards.
- LIPS not a standard but being currently implemented by some vendors (e.g., Netscape 3.x directory server)
- Follow currently used DHHS or gov’t directory schemas or recommendations?
- Center for Electronic Messaging Technologies Gov’t Electronic Directory
- DHHS-wide Directory approved by DHHS IRM Advisory Council
- Administration of NIH objectclasses and NIH-wide customized objectclasses and their attributes (additions, deletions, definitions).
- Access control over entries, objectclasses, and attributes.

## Directory Information Schema - Issues

- What minimum person attributes needed in person UID entries? Additional NIH objectclasses in topmost directory?
- Attribute formats need to be consistent (e.g., (555) 123-4567 or +1 555 123-4567 or 1 555 123 4567). Effects LDAP client searches and server replication.
- Synchronization of NIH-wide customized objectclasses, attributes and attribute formats
- Data planning and enterprise data surveys
- what data does NIH keep
- what needs to go into directory
- will private info be included? Privacy Act ramifications.
- identify master copies of info (e.g., home address master copy in HRDB?)
- identify data ownership
- what groups need to be created for management

## Top-Level Update Architecture

- Directory **queries** performed directly by LDAP clients
**Top-level** directory **updates** performed by centrally-managed Web application server
- ICD subdirectory updates **optionally** performed by directory update service

## Directory Architecture Diagram

**RDBMSs**

**OS & NOS**
**Security**
**Registries**

**Top-Level Directory Servers**

**Browsers**
**and other**
**apps.**

**Directory Update**
**Service: Business**
**Rules + Workflow**

**HTTPS,LDAP, IIOP,**
**RPC, etc. updates**

**LDAP Queries**

**LDAP**
**updates**

**ODBC/SQL**
**updates**

**LDAP, RPC, “Publish &**
**Subscribe”, e-mail, etc.**
**updates**

## Directory Update Service

- Multiple interfaces: HTTPS, LDAP, IIOP, RPC, ...
- Automate business process
- Enforce business & update authorization rules
- Perform workflow (e.g. change approval)
- Maintain audit information
- Synchronize directory with other DBs

## Directory Update Service Rationale

- Simplicity
- Many key data sources already centralized:
- Organization structure (HRDB)
- Organizational affiliation (HRDB)
- Telephone and FAX(?) numbers
- Badge numbers (NIH UID)
- Other?

## Directory Update Service Rationale (cont.) 

- Ensure interoperability and security, desirable to **enforce** and **automate** **NIH-wide** directory update **business process** (e.g. change phone #)

## Directory Update Service Rationale (cont.)

- Need to update other data repositories in sync with directory:
- RDBMSs (examples?)
- Add/update/delete users/groups/ACLs  in Server OS and NOS security registries:
- Windows NT
- Novell Netware
- UNIX/DCE,NIS
- MVS/RACF

## Directory Update Service Problems

- Direct employee update of:
- E-mail address?
- Other?
- Can directory update service be replicated?

## Top-Level 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, LDIF, proprietary
- Note: LDIF **not** part of LDAP standard

## This slide intentionally left blank

## This slide intentionally left blank