Strawperson NIH Directory Service Architecture

1
Strawperson NIH Directory Service Architecture

• NIH AMG Technical Subcommittee

2
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

3
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

4
Requirements (continued)

• Provide mutual authentication
• Provide for hierarchical management

5
Components

• Client Web browsers and other applications
• Directory servers
• Directory update Web application service
• Relational DBMSs
• NOS and server OS security registries

6
Directory Hierarchy
directory update service
AMG mandatory structure
oNIH cUS
replicated homogeneous servers
ouNIH CA
ouDCRT
uidnnnnnnnnnN
minimum schema
AMG recommended structure
ouDCRT
ICD server
uidnnnnnnnnnN

7
Directory Hierarchy
d.u.s.
oNIH cUS
uidnnnnnnnnnN
ouNIH CA
ouDCRT
ouDCRT
...
uidnnnnnnnnnN
DCRT person
Enterprise person
common required attribute set
uidnnnnnnnnnN .
uidnnnnnnnnnN .
email telephone fax .
email telephone fax .
common optional attribute set
location references (enterprise only)
ouDCRT ouNCI .
account .
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.
8
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 uniqueIdentifiernnnnnnnnnNoNational
  Institutes of Health cUS
  
• 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

9
Directory Hierarchy- Pros

• Stresses uniqueness of UIDs (not more than one
  uniqueIdentifier.. oNIH CUS 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

10
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)

11
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. cngrantee oNIH
  cUS) 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

12
Directory Information Schema

• Lightweight Internet Person Schema (LIPS) 37
  common attributes (general personal
  organization securityancillary) used for
  defining white page oriented entries
• Reference http//www2.netapps.org/netapps/lipschem
  afinal.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

13
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 govt directory
  schemas or recommendations
  
• Center for Electronic Messaging Technologies
  Govt 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.
  

14
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.
  [phone] 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

15
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
  

16
Directory Architecture Diagram
Top-Level Directory Servers
LDAP Queries
LDAP updates
ODBC/SQL updates
RDBMSs
Browsers and other apps.
Directory Update Service Business Rules Workf
low
HTTPSLDAP IIOP RPC etc. updates
LDAP RPC Publish Subscribe e-mail etc. u
pdates
OS NOS Security Registries
17
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

18
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

19
Directory Update Service Rationale (cont.)

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

20
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/DCENIS
• MVS/RACF

21
Directory Update Service Problems

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

22
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 fai
lover Per site administration and monitoring Syn
c protocol DISP LDIF proprietary
Note LDIF not part of LDAP standard
23
Thisintentionally left blank
24
Thisintentionally left blank