Strategies for Directory Deployment - Centralized, Distributed, Federated, Decentralized

1. Strategies for Directory Deployment - Centralized, Distributed, Federated, Decentralized • Presenters (East to West): • Suresh Balakrishnan, University System of Maryland Dennis Cromwell, Indiana University - BloomingtonMelinda Jones, University of Colorado at BoulderMark Crase, California State University David Bantz, University of Alaska

2. University System of MarylandIdentity Management InfrastructureVision, Architecture, and Strategies Suresh Balakrishnan,

3. Vision • Create a unifying layer across autonomous institutions • Identification • Affiliation • Provide transparent access to shared services • Authentication • Authorization • Provide a foundation for more advanced services • E.g. PKI • Provide vehicle for coordination with K-12 education in the State • Integrate education in Maryland into a broader fabric

4. Library Applications • Currently in Use/Development • Rock-n-Roll Reserves • Digital Library Access • Future Possibilities • Shared and unique resources for institutions • Multiple institutional affiliations • Auto-populating the patron database

5. Architecture & Collaborative Efforts • Highly Decentralized Implementation Context • System-wide work group developing guidance materials • Tool Kit • Demonstrations of local and collaborative apps • Testing Shibboleth

6. Indiana University Global Directory Services • Centralized Directory Structure • Flat name space – 150,000 actual users • 100,000 students • 20,000 faculty and appointed staff • 30,000 others • Seven Campuses • Provides updates for the two authentication services – Kerberos and ADS • Implements the Eduperson schema with extensions

7. Indiana UniversityDirectory Entries • Directory automatically loaded from SIS, HR systems • IU faculty, staff and students • Sponsored Accounts • Affiliates of IU • Data is entered into PeopleSoft system • Picked up as part of load. • Account can not be created until entry in the Directory

8. Indiana University – Architecture • Open LDAP • Batch feeds from SIS and HRMS • API for LDAP abstracts access • ADS used in conjunction for non-enterprise type groups • Account Management System and Address Book reads Directory

9. Indiana University Future Directions • Real time updates from SIS/HRMS • “Guest” stored in directory • Cleaning up old technology components and integrate technical components • Disaster Recovery replication and automatic failover • Better purge procedures • Decision Support functions

10. 4 unique campuses – traditional, non-traditional, and health sciences • + System Services Campus • 49,000 students total (28,000 at Boulder campus) • 22,000 employees University of Colorado System Melinda Jones, University of Colorado at Boulder

11. Directory Services Project: Goals • Develop common infrastructure • Develop UCB Enterprise Directory • Create trusted, authoritative data source • Usable by variety of applications & services • Identity, data & relationship management • Authentication/Authorization

12. organizational Person person cuEduPerson coloradoPerson cn description seeAlso sn telephoneNumber userPassword facsimileTelephoneNumber ou, postalAddress, street, st, postsalCode, l postOfficeBox preferredDeliveryMethod,title Macgridnumber Machomelocpath Machomedir Uuid, au activities & research alternateContact campus degreeInstitution & Yr employmentStartDate Expertise feesIndicator highestDegree homeDepartment ISO major, minor, class Privacy, SID, SSN inetOrgPerson eduPerson affiliation jobClassification nickName orgDN orgUnitDN primaryAffiliation principalName schoolCollegeName cusysPerson departmentNumber displayName, employeeNumber employeeType homePhone,homePostalAddress jpegPhoto, labeledURI mail, uid Identifiers…

13. Core Team Steering Team 4-Campus Registry Boulder/Central Enterprise Directory Business Rules Campus Experts SIS HR Boulder Email

14. HR SIS Campus-specific Library – Digital AuthN Faculty “Portal” Campus File System Identity/ Access WebCT AuthN CUSYS Directory Card Office Student Portal UCB calendar White Pages AuthN – ITS svcs MacOS AuthN UCD Directory Spons. Entry UCB Directory CS Directory Bldr Email Identity Recon. Registry Directory Build cu.edu (concept) Common Infrastructure University-wide

15. The California State University • 23 Campuses • 1 Research Institution (R2) • 21 4-year Comprehensive Institutions • California Maritime Academy • 400,000 Students • 60,000 Faculty and Staff Mark Crase, California State University

16. Planning Activities • Identified internal and external drivers for multi-campus approach • Defined Development Principles: • Foster collaborative efforts among CSU campuses • Foster collaboration with others (I2, UC, CCC, etc.) • Use directories as the starting point for more comprehensive middleware effort • Standards-based w/o mandatory apps/tools • Initially, campus participation is voluntary, but adoption of eduPerson was mandatory • Communicated at all levels of institution

17. Initial Deployment Objectives • Maintain appearance of unified directory architecture • Adopt a common view (eduPerson, etc.) • Define common CSU objects and unique campus objects • Adopt a system-wide unique identifier • Security of Directory had to be no less that most secure application being supported • Standards compliant, but no mandatory tools (LDAP now, others later)

18. Initial Architecture Proposal • Distributed directory model (campus directories, LDAP v3 referrals to all others) • Domain component naming • Adoption of eduPerson 1.0 (now 2.0) • Extension to calstateEduPerson (affiliation, major, SecurityFlag, VOIP address) • Provision for campusEduPerson attributes • Global unique ID based on “uniqueness” algorithm • Secure directory servers (SSL)

19. Final Recommendations • Central directory servers (redundant and diverse) • Submit campus data to system wide directory registry service (like DoDHE CDS) • Common view with extensions, unique ID, security, • Minimum central attributes option • Expanded central attributes option

20. Centralized core data Campus applications Contacts: self-service UA Enterprise Directory 2003.10.14 David.Bantz@Alaska.edu

21. University of Alaska

22. UA Directory Status • 67,000 students; 10,000 employees; 760 departments • Departments fork linked to employees • Web gateway interface supports searching, listing, self-service data • Scheduled & ad hoc batch updates from multiple sources

23. UA Enterprise Directory StrategyEnvironmental Challenges • Distributed implementation team • Complex interface constraints - based on attributes or roles • Sub-set vs. super-set philosophies

24. UA Enterprise Directory Responses to Challenges • Two phase commit for self-service edits (Registry/EDir) • Registry (Oracle db) enforces UA rules (syntax, constraints, validation values) • Distributed admin facilitated by attribute-based roles (role-based ACIs)

25. UA Directory Architecture SQL

26. Directory Search (Anon.) B*ntz

27. Directory Search (Auth.)

28. Detailed Results (Anon.)

29. Self-service edits (Auth.)

30. Protecting Information • Employee ids, student ids, social security identifiers are not stored in the Directory • Web gateway intermediary communicates only via SSL • Data changed only by “known” processes (web gateway or MAU IT) • Gateway limits bulk harvesting