Technical Primer: Directories

1. Technical Primer: Directories Michael R. Gettes Principal Technologist Georgetown University gettes@Georgetown.EDU http://www.georgetown.edu/giia/internet2

2. MACE-DIR • Keith Hazelton, Chair, Wisconsin • eduPerson objectclass • LDAP-Recipe • Dir of Dirs for Higher Education (DoDHE) • Shibboleth project dir dependencies • Meta Directories – MetaMerge • Groups (Dynamic vs. Static; Management) • Afilliated Directories (Stitched, Data Link) • http://middleware.internet2.edu/directories

3. MACE-DIR:eduPerson 1.0 (1/22/01 release) • MACE initiated (Internet2 + EDUCAUSE) • Globally interesting useful attributes • Get community buy-in, must use it also • eduPersonAffiliation (DoDHE), eduPersonPrincipalName (Shibboleth) • “Less is more”, how to use standard objectclasses • http://www.educause.edu/eduperson

4. eduPerson 1.5 object class • Included as part of the NSF Middleware Initiative (NMI) Release 1.0 announced today, May 7th • eduPerson 1.0 is the production version, 1.5 status is “released for public review” (RPR) • Next NMI release will include final 1.5 based on review period discussions

5. eduPerson 1.5 object class • Changes from 1.0: • Introductory section added • RFC2252 style definitions included for the eduPerson object class itself and for each of the eduPerson attributes. • Notes on additional attributes from existing object classes, existing notes clarified, syntax and indexing recommendations updated.

6. eduPerson 1.5 object class • Two new attributes: • eduPersonPrimaryOrgUnitDN • eduPersonEntitlement • Simple case: value is the name of a contract for licensed resource • http://xstor.com/contract1234 • Values of eduPersonEntitlement can be URLs or URNs

7. eduPerson 1.5 object class • eduPersonEntitlement • Values of eduPersonEntitlement can be URLs or URNs • http://www.w3.org/Addressing/ • RFC2396 Uniform Resource Identifiers • RFC2141 Uniform Resource Names • URNs to allow federation of name creation without name clashes. • urn:mace:brown.edu:foo • mace-submit@internet2.edu for information on URN registration

8. eduOrg 1.0 • eduOrg 1.0 released as “Experimental” object class • Basic organizational info attributes from X.520 • Telecomm, postal, locale • eduOrgHomePageURI • eduOrgIdentityAuthNPolicyURI • eduOrgLegalName • eduOrgSuperiorURI • eduOrgWhitePagesURI

9. LDAP-Recipe positioning and the NMI R1 • A special case document • Pre-existed NMI and MACE document standards for format and naming. • Will conform to NMI/MACE naming and future process for acceptance. • Content??? Well, we shall see…

10. LDAP-RecipeVersion 1.5 (pre May 7, 2002) • Directory Tree • Schema (Design, upgrading, maint) • AuthN (binding and pw mgmt) • eduPerson attr discussion (select) • Access Control • Replication • Name population

11. LDAP-RecipeVersion 2.0 (NMI R1 May 7, 2002) • Groups, Groups, Groups • Static, Dynamic, app issues, builds on “NMI Groups Doc” • E-Mail Routing considerations • Attribute firewalling, Sendmail, app issues • eduPersonOrgDN and eduPerson{Primary}OrgUnitDN • Original Intent for eduPerson 1.0 and Primary • RDN Issues (a must read) • Software reference (small, needs to grow)

12. MACE-DIR:Directory of Directoriesfor Higher Education • Web of Data vs. Web of People • Prototype: April, 2000 (by M. Gettes) • Highly scalable parallel searching • Interesting development/research problems • Configs, LDAP libraries, Human Interface • Realized the need to: • Promote eduPerson & common schema • Promote good directory design (recipe) • Work proceeding – Sun Microsystems Grant • http://middleware.internet2.edu/dodhe

13. MACE-DIR:DoDHE and LDAP Analyzer • Todd Piket, Michigan Tech (aka Mr. Pinkert) • Web based tool to empirically analyze a directory • eduPerson compliance • Indexing and naming • LDAP-Recipe guidance (good practice) • Beta: http://morpheus.dcs.it.mtu.edu/~tcpiket/dodhe

14. MACE-Dir Futures • Technical Advisory Board • eduOrg, eduPerson, edu??????? • Shibboleth and other related work • Roles (RBAC) • Group Implementations (Eileen Shepard, BC; Tom Barton, Memphis) • Blue Pages • LDAP-Recipe (next?) • Affiliated Directories (Rob Banz, UMBC) • pkiUser/pkiCa, Bridge CA, etc… • Video Middleware (commObject{Uri} OCs) • GRID interoperability • Directory Policy

15. MACE-Dir Futures (continued) • EduOrg “blue page” entries • EduOrgUnit 1.0 object class and attributes • Affiliated directories scenarios • Identity management in Health Sciences • Assembling info on the fly • Data/Metadata bundles as units of exchange • Exploring with our Technical Advisory Board

16. MACE-SHIBBOLETH • Steven Carmody, Brown, Chair • A Biblical pass phrase – “password” • Get it right or “off with your head” • Inter-institutional Authentication/Authorization • Web Authorization of Remote Sites with Local Credentials • Authentication via WebISO • October, 2001 – Demo target • http://middleware.internet2.edu/shibboleth May, 2002

17. VID-MIDVideo Middleware • Recently Formed • Authentication and Authorization of H.323 sessions. • Client to Client • Client to MCU • Directory enabled • How to find video enabled people? • What is necessary to describe video capabilities? • Will likely extend to IP Telephony and so on…

18. PKI is 1/3 Technical and 2/3 Policy? Policy Technical

19. HEPKI • TAG – Technical Activities Group • Jim Jokl, Chair, Virginia • Mobility, Cert Profiles, PKI-Lite, etc, etc, lots of techno • PAG – Policy Activities Group • Default Chair, Ken Klingenstein, Colorado • Knee-deep in policy, HEBCA, Campus, Subs+RP • PKI Labs (AT&T)– Neal McBurnett, Avaya • Wisconsin-Madison & Dartmouth • Industry, Gov., Edu expert guidance • http://www.educause.edu/hepki

20. Fed CA-A CA-B CA-C CA-D Bridge CA and Trust Paths Policy & Namespace Bridge CA Bridge CA Verisign HE

22. Bridge CAs • Higher Education Bridge CA – FBCA peering • We have a draft HEBCA CP (Net@EDU PKI WG) FBCA Compatible • How many HEBCAs? (EDUCAUSE!) • Do we really understand PKI implementations with respect to policy needs? (proxy certificates, relying party agreements, name constraints, FERPA, HIPAA, who eats who?) • BCA seems to be the most promising perspective. Will each person be a BCA? • Does ALL software (Client/Server) need to be changed? • Mitretek announces new BCA deployment model 2/15/2001 • Scalable & deployable • Server plug-ins make client changes less likely

23. domainComponent (DC=) Naming • Traditional X.500 naming: • cn=Michael R Gettes, ou=Server Group, ou=UIS, o=Georgetown University, c=US • domainComponent (DC) naming: • uid=gettes,ou=People,dc=georgetown,dc=edu • HEPKI is issuing guidance and advice on DC= naming

24. Attributes for PKI • Store them in a Certificate? • Attributes persist for life of Certificate • No need for Directory or other lookup • The Certificate itself becomes the AuthZ control point • Store them in a Directory? • Very light-weight Certificates • Requires Directory Access • Long-term Certificate, Directory is AuthZ control point. • How many Certificates will we have? • Pseudonymous Certificates

25. David Wasley’s PKI Puzzle

26. We’re Building A“Bridge Over The River PKI”

27. A word about “Portals”

28. Portals: Authentication • Security is not easy • if it was, then everyone would be doing it.  • Applications MUST NOT handle authentication • Don’t assume you will have access to passwords at the portal • The portal is YAA (yet another application) • but portals have web servers to do the dirty work • portals can trust the web server to authenticate • and pass “identity” on to the portal

29. Portals: Authorization • Security is not easy • if it was, then everyone would be doing it.  • Applications should handle authorization • The portal is YAA (yet another application) • Portals can decide access on their own by consulting • local and remote services to determine eligibility then • grant/deny based on response or otherwise by whim.

30. Portal Issues • Authentication • WebISO • Authorization • Groups • Roles • Directories, Shibboleth • Vendor Independent Techniques

31. Errata--ica

32. National Science FoundationNMI program • $12 million over 3 years • www.nsf-middleware.org • Middleware Service Providors, Integrators, Distributors • GRID (Globus) • Internet2 + EDUCAUSE + SURA • May 2002 – first set of deliverables from all parties

33. The Liberty Alliancewww.project-liberty.org • Sun Microsystems, American Express, United Airlines, Nokia, MasterCard, AOL Time Warner, American Airlines, Bank of America, Cisco, France Telecom, Intuit, NTT DoCoMo, Verisign, Schlumberger, Sony … • Initiated in September 2001. • Protect Privacy, Federated Administration, Interoperability, Standards based but requires new technology, hard problems to solve, a Network Identity Service • Funny, doesn’t this stuff sound familiar?

34. Got Directory?

35. Techniques for Product Independence • Good/Evil – make use of cool features of your product. • Does this make it more difficult or impossible to switch products later? • Does this make you less interoperable? Standard? • Does this limit your ability to leverage common solutions? • All the above applies to enabled apps as well.

36. Groups, Groups, Groups • Static vs. Dynamic (issues of large groups) • Static Scalability, performance, bandwidth • Dynamic Manageability (search based, but search limits) • Is there something neutral? • Indexed Static Groups • MACE-DIR consideration (Todd Piket, MTU) • Index unique/member • The likely approach, IMHO, doesn’t inhibit dynamic stuff • Group Math • (& (group=faculty)(!(group=adjunct)) (member=DN) )

37. Roles • Is this an LDAP issue? • MIT roles DB – a roles registry • Are groups good enough for now? • Probably not, see next • Are your apps prepared for this? Maybe they need some service to consult? Will Shibboleth help here? • Vendors have proprietary solutions.

38. Stitching disparate directories • How to relate to distinct directories and their entries. Kjk@colorado & kjk@ViDe -- are they the same? • Locate someone in a large directory (DoDHE) and then switch to their video abilities • Suggestion: define new object of a “data source directory”. Associate it with a Cert. Send signature of all data elements for an object, store in same. This allows for digital trust/verification. Still working this out. Not much work in this space? (the affiliated dirs problem) • X.520 AttributeIntegrityInfo Attribute – will it suffice?

39. A Campus Directory Architecture border directory metadirectory Enterprise applications dir enterprise directory departmental directories OS directories (MS, Novell, etc) directory database registries source systems

40. Middleware 201DirectoriesConfiguration & Operations Michael R. Gettes Principal Technologist Georgetown University Gettes@Georgetown.EDU

41. How Deep? • Background • Site Profile - configuration • Applications • General Operational Controls • Schema • Access Lists • Replication • Related Directories • LDAP-Recipe – http://middleware.internet2.edu

42. Site Profiledc=georgetown,dc=edu • Netscape/iPlanet DS version 4.16 • 2 Sun E250 dual cpu, 512MB RAM • 105,000 DNs (25K campus, others = alums + etc) • Directory + apps implemented in 7 months • Distinguished names: uid=x,ou=people • DC rap, “Boom shacka lacka” • Does UUID in DN really work? • NSDS pre-op plugin (by gettes@Princeton.EDU) • Authentication over SSL; Required • Can do Kerberos – perf problems to resolve • 1 supplier, 4 consumers

43. Authentication:Overall Plan @ Georgetown • Currently, Server-Side PKI self-signed • Best of all 3 worlds • LDAP + Kerberos + PKI • LDAP Authentication performs Kerberos Authentication out the backend. Jan. 2001 to finish iPlanet plug-in. • Credential Caching handled by Directory. • Cooperative effort – Georgetown, GATech, Michigan • All directory authentications SSL protected. Enforced with necessary exceptions • Use Kerberos for Win2K Services and to derive X.509 Client Certificates • One Userid/Password (single-signon vs. FSO)

44. Applications • Mail routing with Sendmail 8.12 (lists also) • Netscape messaging server v 4.15 (IMAP) • WebMail profile stored in LDAP • Apache server for Netscape roaming (no SSL) • Apache & Netscape enterprise web servers • Blackboard CourseInfo Enterprise 5.5.1 • Whitepages: Directory Server GateWay • DSGW for priv’d access and maintenance

45. Applications (Continued) • Remote access with RADIUS (funk). • No SSL (3/2000); proper LDAP binds (fix 8/2000) • Authenticates and authorizes for dial-up, DSL and VPN services using RADIUS called-id. • We want to use this for other access control such as Oracle

46. CalledId from NAS is mapped to guRadProf User calls 202-555-1110 RADIUS server NAS (terminal server) LDAP Filter is: guRadProf = 2025551110 + NetID = gettes Dialup Users Netid = gettes guRadProf = 2025550001 guRadProf = 2025551110 guRadProf = OracleFin Directory Server RADIUS + LDAP

47. Applications (Continued) • Alumni services (HoyasOnline). • External vendor in Dallas, TX (PCI). • They authenticate back to home directories. Apache used to authenticate and proxy to backend IIS server. • Email Forwarding for Life

48. HoyasOnline Architecture OS/390 LDAP Master LDAP Replica TMS Other local hosts GU provided self-service applications NET ID HRIS PCI (Dallas) Vendor-provided services SIS WWW hoyasonline Content Way Down In Texas Alumni Gratuitous Architectural Graphic (GAG) Client Browser

49. Applications (Continued) • Access+ • Georgetown developed • Web interface to legacy systems using Unix front-end to custom made mainframe tasks. Many institutions have re-invented this wheel. • LDAP authentication, mainframe doesn’t yet do SSL. Always exceptions to rules. • Student, Faculty, Staff, Directory/Telephone Access+ Services. This technique keeps mainframe alive. (good or bad?)

50. Applications (Continued) • Specialized support apps • Self service mail routing • Help Desk: mail routing, password resets, quota management via DSGW • Change password web page • Person registry populates LDAP people data, currently MVS (mainframe) based. • PerLDAP used quite a bit – very powerful! (make sure version >= 1.4) • Now moving to Net::LDAP