Title: Strawperson NIH Directory Service Architecture
1Strawperson NIH Directory Service Architecture
- NIH AMG Technical Subcommittee
2Changes from Draft 2
- More ICD control of directory
- structure
- updates
- physical implementation
- More evolutionary
- mandatory structure at top level
- guideline structure for ICD subtrees
3Requirements
- 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
4Requirements (continued)
- Provide mutual authentication
- Provide for hierarchical management
5Components
- Client Web browsers and other applications
- Directory servers
- Directory update Web application service
- Relational DBMSs
- NOS and server OS security registries
6Directory 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
7Directory 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.
8Directory 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
9Directory 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
10Directory 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)
11Directory 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
12Directory 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
13Directory 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.
14Directory 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
15Top-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
16Directory 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
17Directory 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
18Directory 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
19Directory Update Service Rationale (cont.)
- Ensure interoperability and security desirable
to enforce and automate NIH-wide directory update
business process (e.g. change phone )
20Directory 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
21Directory Update Service Problems
- Direct employee update of
- E-mail address
- Other
- Can directory update service be replicated
22Top-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
23Thisintentionally left blank
24Thisintentionally left blank