Registry Directory Infrastructure at Stanford Jeff Hodges Stanford

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

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

Registry/Directory Infrastructure Overall Problem Statement, cont’d • Directories, as a class, are subtly different than generalpurpose 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 3

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

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

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

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 – Web. Authentication – Authenticated Printing service – Dial. In Network Service – Whitepages (I. e. general purpose) Directory service 30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges 7

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

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

Registry/Directory Infrastructure Email Routing To: user@Stanford. edu 1. SMTP (Incoming Email Message) 2. cn=user? 3. Maildrop=user@host. stanford. edu 2. LDAP Mail Server (MTA) Registry & Source Systems Directory 3. LDAP 4. SMTP “user” on Host. stanford. edu 30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges 10

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

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 Mc. Rae, 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 12

Acknowledgements & References, cont’d • References… – – 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/ 30 April 1998 Registry & Directory Infrastructure @ Stanford / Jeff Hodges 13