Registry & Directory Infrastructure at Stanford

Note! This talk was superseded by..Registry & Directory Infrastructure: A Case History

..as of 31-Mar-1999

Jeff HodgesStanford University

30 April 1998

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

2

Registry/Directory InfrastructureOverall Problem Statement

• Highly decentralized enterprise with multiple, virtually autonomous systems of record

• Common, shared business objects, e.g. People– Personnel’s system: faculty & staff– Registrar’s system: students– Affiliated enterprises’ systems: SLAC, Hospital– Non-trivial number of variously-affiliated

people who aren’t in any system• Other objects: Groups, (network) Services

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

3

Registry/Directory InfrastructureOverall Problem Statement, cont’d

• Directories, as a class, are subtly different than general-purpose relational databases (RDBMSs)

• RDBMS properties

– strongly typed data

– can represent complex relationships

– transaction support

– support on-the-fly data view generation

• “find all the people whose managers are located in New York”

– no open “on the wire” protocol standard

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

4

Registry/Directory InfrastructureOverall Problem Statement, cont’d

• Directory properties

– strongly typed and structured information, like RDBMS

– open standard access protocols

– core standard schema

– object-oriented

– highly distributable

– extensible schema

– but can’t cut on-the-fly views, no notion of “report generation”, etc.

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

5

Registry/Directory InfrastructureDefinitions and Scope

• A Registry is a service that serves the needs of applications for coordinated maintenance of identity information about a class of business objects.

– E.g. People, services, groups

• A Registry is a transaction-oriented service…

– Client applications will use it mostly to enter and update entries.

– Read-oriented access may be handled by other components of the overall system, e.g. the Directory.

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

6

Registry/Directory InfrastructureDefinitions and Scope, cont’d

• The scope of the Registry is enterprise-wide

• All people affiliated with the university should be in the Registry

– I.e. if you need others within the enterprise to recognize your affiliation, you need to be in the Registry.

• A primary materialization of this requirement:

– Needing an authentication principal - a SUNet ID

– Many network services are authenticated• E.g. AFS distributed file system, various web pages,

distributed computing resources (e.g. POP-based email service)

• Authentication infrastructure is Kerberos-based

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

7

Registry/Directory InfrastructureDefinitions and Scope, cont’d

• Registry entries are shared via the Directory

• Various infrastructure applications utilize the Directory when they need information about people, e.g...

– “@Stanford.edu” email routing

– WebAuthentication

– Authenticated Printing service

– DialIn Network Service

– Whitepages (I.e. general purpose) Directory service

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

8

Overall Directory/Registry InfrastructureDissemination

RegistrarPersonnel

Registry

Middleware Event Broker

SLOG(Business Rules Implementation)

LDAP-based

Directory Service

Desktop Clients

Systems of Record

Network-basedApplications

Desktop ClientsDesktop Clients

LDAP Reads

LDAP Reads

LDAP R/WTDS

TDS

TDS

Network-basedApplicationsNetwork-basedApplications

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

9

Overall Directory/Registry InfrastructureUpdate

RegistrarPersonnel

Registry

Middleware Event Broker

SLOG

Directory Service

Desktop Clients

Network-basedApplications

Systems of Record

Desktop ClientsDesktop Clients

LDAP

TDS

Web-based User Interface for

Data Maintenance

HTTP (authenticated)

Network-basedApplicationsNetwork-basedApplications

HTTP (authenticated)

TDS

TDS

TDS

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

10

Registry/Directory InfrastructureEmail Routing

Mail Server(MTA)

To: user@Stanford.edu(Incoming Email Message)

1. SMTP

2. LDAP

3. LDAP

“user” on Host.stanford.edu

4. SMTP

Registry& SourceSystems

Directory2. cn=user?3. Maildrop=user@host.stanford.edu

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

11

Registry/Directory InfrastructureSummary

• Natures of Registries and Directories are subtly different

• X.500/LDAP-based directory services are not RDBMSs

• Makes sense to combine them into overall system - play on their strengths

• Project at Stanford is far from, if ever, “finished” -- will continually evolve

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

12

Acknowledgements & References

• The Registry/Directory team is comprised of (at least): Booker Bense, Carol Farnsworth, Michael Hart, Jeff Hodges, Craig Jurney, John Klemm, Bill Lucker, Lynn McRae, Dennis Michael, RL “Bob” Morgan, Catherine Mulhall, Pat Nolan, Michael Puff, Dennis Rayer, Sandy Senti, Tim Torgenrud, Dwayne Virnau.

30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges

13

Acknowledgements & References, cont’d

• References…– http://www.stanford.edu/group/itss-ccs/project/registry/

– http://www.stanford.edu/group/itss-ccs/project/registry/registries.html

– http://www.stanford.edu/group/itss-ccs/project/sunetid/

– http://www.stanford.edu/group/networking/directory/

• This talk will be available at..– http://www.stanford.edu/~hodges/talks/