Middleware Early Adopters Report: Organization/Policy/Process Challenges

1. Middleware Early Adopters Report:Organization/Policy/Process Challenges 31 October 2000

2. Panelists • Robert Brentrup, Dartmouth College • Ann West, Michigan Technological University • David Lassner, University of Hawaii • Lesley Tolman, Tufts University • Robert Pack, University of Pittsburgh • Moderator: Renee Woodten Frost, Internet2 /University of Michigan Internet2 Fall 2000 Meeting: Early Adopters Report

3. Proliferation of customizable apps requires centralization of“customizations” Increase in power and complexity of the network requires access to user profiles Electronic personal security services is now an impediment to the next-generation computing grids Inter-institutional applications require interoperational deployments of institutional directories & authentication Remedial IT architectureWhy middleware? Internet2 Fall 2000 Meeting: Early Adopters Report

4. What is Middleware? • Specialized networked services that are shared by applications and users • A set of core software components that permit scaling of applications and networks • Tools that take the complexity out of application integration • Sits above the network as the second layer of the IT infrastructure • The intersection of what networks designers and applications developers each do not want to do Internet2 Fall 2000 Meeting: Early Adopters Report

5. Specific Application Requirements • Digital libraries need scalable, interoperable authentication and authorization. • The Grid as the new paradigm for a computational resource, with Globus as the middleware, including security, location and allocation of resources, scheduling, etc. relies on campus-based services and inter-institutional infrastructures. • Instructional Management Systems (IMS) need authentication and directories • Next-generation portals want common authentication and storage • Administrative applications are adopting internet oriented infrastructures Internet2 Fall 2000 Meeting: Early Adopters Report

6. Dartmouth CollegeProfile • Combines the best features of an undergraduate liberal arts college with those of a research university • Private Residential Institution, founded 1769 • Professional Schools of Medicine, Business and Engineering • 4000 Undergraduate Students • 1200 Graduate Students • 1200 Faculty • 380 Arts and Sciences, 760 Medical School Internet2 Fall 2000 Meeting: Early Adopters Report

7. Why Deploy Middleware? • Improve Customer Service • Improve Administrative Efficiency • Data and Transaction Security • Internal and External E-commerce • Use inter-institution standards • Possible Mandates Internet2 Fall 2000 Meeting: Early Adopters Report

8. Where we started • Dartmouth Name Directory (DND) • Developed in 1986 to support e-Mail • Multiple Institutions Supported • College, Medical Center, Alumni, Valley.net • E-mail: Reed College, Washington College • Database Sharing: Middlebury College Internet2 Fall 2000 Meeting: Early Adopters Report

9. Where we are going - Overview • Standards Based • Directories, Authentication, Authorization • Cross-institutional • Directory lookup • Resource Sharing and Access • More Directory and PKI Enabled Applications Internet2 Fall 2000 Meeting: Early Adopters Report

10. Identifiers • Before & Current • Universal Unique ID • E-mail: firstname.mi.lastname@dartmouth.edu • End user defined forwarding address • Partial / Nickname matching • UNIX account creation automated • requests authenticated • Planned • UUID and E-mail unchanged • Matching feature hard to add Internet2 Fall 2000 Meeting: Early Adopters Report

11. Directories • Before • Dartmouth Name Directory (DND) • Loaded from HRS and SIS, Sponsored accounts • User Modifiable: Nickname, E-mail, Paper mail, Campus Phone, URL, Password • Library Patrons • Students loaded from SIS, Faculty & Staff on demand • NT ids for print spooling • from authenticated e-mail • Open LDAP experiments Internet2 Fall 2000 Meeting: Early Adopters Report

12. Directories... • Current • iPlanet LDAP duplicating DND • loaded from HRS & SIS • PeerLogic X.500 for Payroll Authorization Pilot • CorpTime using Kerberos & DND • Planned • LDAP loaded from HRS & SIS • Eduperson Schema • Directory Enabled Apps using central LDAP Internet2 Fall 2000 Meeting: Early Adopters Report

13. Authentication • Before & Current • DND password • Kerberos ticket using KClient/Sidecar • Planned • Kerberos • Port 80 ticket passing CGI • Public Keys • Installed in Web Browser and/or PK Client Internet2 Fall 2000 Meeting: Early Adopters Report

14. Authorization • Before • Membership in DND • Added other field checks • eg.Dept affiliation discrimination • Created Course Enrollment Lists • Inter Domain Access Protocol (IDAP) • Oracle Listener Process for UID recovery and table index Internet2 Fall 2000 Meeting: Early Adopters Report

15. Authorization... • Current • LDAP master for white pages • DND backwards compatibility • Planned • LDAP primary categorization data source • Rule Language based authorization conditions • Application Specific logic Internet2 Fall 2000 Meeting: Early Adopters Report

16. Applications • Before • E-mail, IP Dial-up, CWIS access • Library Remote Logins, Course Resource access • Web Applications with Sidecar • Web, UNIX, NT account creation, Degree Audit, Debit Card Balances • DCIS, Inter-Lib Loan, Document Delivery, IP address proxy • Current • PKI based Payroll Authorization Internet2 Fall 2000 Meeting: Early Adopters Report

17. Applications... • Planned • Access to academic material • Grants and Contracts Forms • Travel Expense Vouchers • Authenticated Wireless • Universal Campus PKI • Mobile devices Internet2 Fall 2000 Meeting: Early Adopters Report

18. How we got started • Driven by Vertical Applications • Cross Group Project Team • Tech Services, Admin Computing, Info Systems Directors • Key Developers, Directory, E-mail, Admin Pilot • Consulting Services • Funding • Pilot support by application and new projects budgets Internet2 Fall 2000 Meeting: Early Adopters Report

19. Challenges and Countermeasures • PKI Policies and Procedures • Certificate and Registration • Must change scale from 100 to 10,000 • Support Personnel for PKI • Campus Wide Rollout • Documentation, Consulting Support, Funding Internet2 Fall 2000 Meeting: Early Adopters Report

20. Challenges... • Human element of PKI Operation • Hardware “Keys” • Password synchronization • Privacy without loss of Electronic Services Internet2 Fall 2000 Meeting: Early Adopters Report

21. Challenges - Technical • Selection of PKI package • Driven by support for forms and platforms • How many will we need? • Client software installation significant • Large footprint and complex • Version update problems • User management of credentials using files Internet2 Fall 2000 Meeting: Early Adopters Report 4

22. Surprises • Vertical Application ahead of PKI • Technical and Staff Roles • User Roles and Delegation • Document Repository • Need more than flat directory structure • Need to archive for some number of years, then can delete • Issues by-passed in development cycle • Directory integration and maintenance • Multiple applications using PKI / Policies Internet2 Fall 2000 Meeting: Early Adopters Report

23. Surprises... • Selected PKI technology to get secure signatures for Pilot but... • Operational practices preventing guarantee • People forget the credential password • Effort to re-issue credentials caused short cuts • Save time for users but... • Additional Personnel needed to run PKI Internet2 Fall 2000 Meeting: Early Adopters Report

24. Michigan TechProfile • Michigan Technological University • Public research university • Total enrollment: 6,321 • 60% in engineering • Graduate enrollment: 660 • 400 faculty and 1000 staff • Ranked programs in Environmental, Mechanical, and Metallurgical Engineering Internet2 Fall 2000 Meeting: Early Adopters Report

25. Why deploy middleware? • Manage cost while offering more services • Offer tailored electronic services • Ensure resources follow the user • Manage use of networked resources • Manage staffing requirements • Reduce duplication of effort • Use same data to feed different applications • Manage access to resources Internet2 Fall 2000 Meeting: Early Adopters Report

26. Where we are going • Educate key campus constituents • Deploy key applications • Build directory service • Deploy central authentication service • Implement ongoing oversight process Internet2 Fall 2000 Meeting: Early Adopters Report

27. Identifiers • Before • Have unique identifier based on SCT Banner • Required for smart card, accounts, library • Was it enough? • Planned • Review identifiers and future requirements • Status • Developing plan to include new audiences Internet2 Fall 2000 Meeting: Early Adopters Report

28. Directories • Before • Ph/white page application • Identified public directory information • Loaded from HR and Student systems • Planned • Implement LDAP enterprise directory • Integrate authentication • Integrate campus and directory apps • Implement oversight process Internet2 Fall 2000 Meeting: Early Adopters Report

29. Directories • Status • Directory server in production • Resolving data and replication issues • Oversight process in draft form Internet2 Fall 2000 Meeting: Early Adopters Report

30. Authentication • Before • Unencrypted NIS authentication • Passwords managed by departments • Planned • Authenticate off directory • Pilot early 2001 • Status • Developing technical policy/procedures Internet2 Fall 2000 Meeting: Early Adopters Report

31. Authorization • Before • Local/application authorization • Groups identified by departments • Quasi-coordinated campus-wide • Planned • Manage groups in directory • Status • Developing data model Internet2 Fall 2000 Meeting: Early Adopters Report

32. Applications • Before • Whitepages in ph • Planned • Applications portal • DHCP • Phone switch • Account management • E-mail forwarding (Sendmail) • Thin-client data support Internet2 Fall 2000 Meeting: Early Adopters Report

33. Applications... • Status • Class rosters with pictures • E-kiosk • Whitepages Internet2 Fall 2000 Meeting: Early Adopters Report

34. How we got started • Established an IT project team • Developed initial project plan • Purchased hardware and software • Talked to key campus players • Added campus data and technical staff • Educated team • Developed more detailed project plan Internet2 Fall 2000 Meeting: Early Adopters Report

35. Challenges andCountermeasures • Selling middleware • Deliver applications • Identifying applications • Flexible project management • Good communication • Deploying in distributed environment • Include department technical staff • Ensure local control and performance Internet2 Fall 2000 Meeting: Early Adopters Report

36. Challenges andCountermeasures... • Dedicating staff • Retrain existing staff • Leverage other technical staff • Hire temporary help • Consider architecture carefully Internet2 Fall 2000 Meeting: Early Adopters Report

37. Surprises • Difficult to sell • Time commitment • Dependency on clean data • Continuous process • Grouping in directories • Translating political to technical • Authentication and authorization • Policy development Internet2 Fall 2000 Meeting: Early Adopters Report

38. University of HawaiiProfile • All public post-secondary education in Hawaii; 10 campuses and 5 ed centers on 6 islands • UH-Manoa - research university with medical and law schools • UH-Hilo and UH-West Oahu • 7 community colleges on four islands • Extensive distance learning programs on six islands • Affiliates include Research Corp, Foundation and East-West Center • ~ 60,000 students, faculty, staff Internet2 Fall 2000 Meeting: Early Adopters Report

39. Why deploy middleware • Driving Factors • Users with too many IDs & passwords • Backlog of applications that require authentication and authorization • Need for dependable, robust, general-purpose infrastructure • Requirement for compatibility with national/international standards and initiatives Internet2 Fall 2000 Meeting: Early Adopters Report

40. Identifiers • Before • SSN as Student ID and Employee ID, library ID number • Enterprise Unix IDs (NIS) for most services; Also RACF IDs, PeopleSoft IDs; many single-service IDs • Current • Unique Identifier in Unix flat file w/Perl routines (“Unison”) used for role reconciliation and source for Unix name space • Unison ID extended for use as HR employee number in new system • Planned • A unique non-SSN “personID” with linkages to roles Internet2 Fall 2000 Meeting: Early Adopters Report

41. Directories • Before • To varying degrees, paper phonebook  Ph/Qi  Telephone database  ID database  Source Data  Reality • Current • Initial LDAP servers in production • Contains ID, passwd, SSN, name, affiliation, home campus • Planned • Accurate & timely updates from primary information sources (hires, terminations, registrations, etc.) Internet2 Fall 2000 Meeting: Early Adopters Report

42. Authentication • Before • Enterprise Unix IDs (NIS), RACF Ids, PeopleSoft IDs • Feed from Unix to Radius server for modem pool • Numerous departmental web sites with ID/password; Some “fake” a login to Unix • Current • First departmental application authenticating via LDAP from Java • Planned • One ID/password for authentication at enterprise & departmental levels • Models for directory enablement from multiple platforms Internet2 Fall 2000 Meeting: Early Adopters Report

43. Authorization • Before • Application specific • Current • Student Employment system gets user’s affiliation from LDAP • Planned • Determining appropriate mix of centralized and decentralized authorization attributes Internet2 Fall 2000 Meeting: Early Adopters Report

44. Applications • Before • Online phone directory using PH/QI • Multiple access to Unix NIS database (“faked logins”) • Current (LDAP) • Web Mail • Student Employment Web app • Planned • HR Leave Accounting Data • (continued) Internet2 Fall 2000 Meeting: Early Adopters Report

45. Applications (cont) • Planned(continued) • One set of informational white pages • firstname.lastname@hawaii.edu email address with optional user-specified delivery address • System-wide portals • Compatibility with national middleware initiatives Internet2 Fall 2000 Meeting: Early Adopters Report

46. How we got started • Steps we took • Committed to standards • Joined I2 Middleware Early Adopters program • Looked for “quick hit” projects Internet2 Fall 2000 Meeting: Early Adopters Report

47. Challenges andCountermeasures • Centralized Functions (UH System) • Human Resources • Finance • Decentralized Functions (By Campus) • Student Services • Student Information Systems (10 instances of 4 packages) • Mixed Functions • ITS serves as IT support unit for both the UH System and the UH-Manoa campus Internet2 Fall 2000 Meeting: Early Adopters Report

48. Challenges andCountermeasures (cont) • Other Challenges • Primary data sources include 10 SISs, HRMS, RCUH, UHF, EWC and ad-hoc • Need robust reliable systems architecture • Synchronization problems growing; architecture for information flow needs help Internet2 Fall 2000 Meeting: Early Adopters Report

49. Surprises • Good News • No significant organizational obstacles; Functional units are cooperative and recognize value of initiatives • But • Internal pressures and needs growing more quickly than visible results Internet2 Fall 2000 Meeting: Early Adopters Report

50. Tufts UniversityProfile • “Small, complex, independent, nonsectarian” • 9,000 Students • 3 Campuses in Massachusetts • 7 Schools • School of Arts, Sciences and Engineering • School of Medicine • School of Dental Medicine • Sackler School of Graduate Biomedical Sciences • School of Veterinary Medicine • School of Nutrition Science and Policy • Fletcher School of International Law and Diplomacy Internet2 Fall 2000 Meeting: Early Adopters Report