1. Registry & Directory Infrastructure at Stanford Note! This talk was superseded by.. Registry & Directory Infrastructure: A Case History..as of 31-Mar-1999 Jeff Hodges Stanford University 30 April 1998

2. Registry & Directory Infrastructure @ Stanford / Jeff Hodges 2 Registry/Directory Infrastructure Overall 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

3. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 3 Registry/Directory Infrastructure Overall 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

4. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 4 Registry/Directory Infrastructure Overall 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.

5. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 5 Registry/Directory Infrastructure Definitions 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.

6. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 6 Registry/Directory Infrastructure Definitions 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

7. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 7 Registry/Directory Infrastructure Definitions 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

8. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 8 Overall Directory/Registry Infrastructure Dissemination Registrar Personnel Registry Middleware Event Broker SLOG (Business Rules Implementation) LDAP-based Directory Service Desktop Clients Systems of Record Network-based Applications Desktop Clients LDAP Reads LDAP R/W TDS Network-based Applications Network-based Applications

9. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 9 Overall Directory/Registry Infrastructure Update Registrar Personnel Registry Middleware Event Broker SLOG Directory Service Desktop Clients Network-based Applications Systems of Record Desktop Clients LDAP TDS Web-based User Interface for Data Maintenance HTTP (authenticated) Network-based Applications Network-based Applications HTTP (authenticated) TDS

10. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 10 Registry/Directory Infrastructure Email 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 & Source Systems Directory 2. cn=user? 3. Maildrop=user@host.stanford.edu

11. 30 April 1998Registry & Directory Infrastructure @ Stanford / Jeff Hodges 11 Registry/Directory Infrastructure Summary 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

12. 30 April 1998Registry & 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.

13. 30 April 1998Registry & 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/