1. Multi-Campus Middleware: Technical and Organizational Dimensions A. Michael Berman, Cal Poly Pomona Mark Crase, CSU Office of the Chancellor Kent McKinney, CSU Hayward Copyright A. Michael Berman, Mark Crase, and Kent McKinney, 2002. This work is the intellectual property of the authors. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the authors. To disseminate otherwise or to republish requires written permission from the authors

2. Overview of Presentation California State University: background, strategy, drivers A grass roots experiment: the Directories Working Group Developing an Institutional Response

3. First, some background… The California State University 23 Campuses 1 R2 Research 21 4-year Comprehensive California Maritime Academy 350,000 Students 80,000 Faculty and Staff

4. Integrated Technology Strategy In 1993, the CSU Presidents came together to ensure that each campus in the system would have the technology infrastructure required to support each institution’s academic and administrative programs. The result was the creation of the CSU Integrated Technology Strategy

5. Integrated Technology Strategy Outcomes-based strategy Built on Integrated Academic and Administrative Initiatives Supported by a Robust Infrastructure Access (Hardware, Software, Network) Training Support Services

6. Technology Prerequisites Outcomes Initiatives SupportTraining Access Network Hardware Software Initiatives / Projects Distributed Learn. & Teach. Multimedia Repository Library Resources Student Friendly Services Common. Mgt. Systems Streamline I/T Delivery Procurement Process Improvement One Card Access Infrastructure Initiative Centers for Inst. Tech. Develop. Optimal Personal Productivity Excellence in Learning and Teaching Quality of Student Experience Administrative Productivity and Quality Baseline Training & User Support Infrastructure   ITS FRAMEWORK FULL BASELINE CURRENT

7. Institutional Leadership Information Technology Advisory Committee Campus CIO’s Chancellor’s Office Staff Middleware Steering Committee CIO’s, Campus Technical Staff, CO flywheels Directories Working Group Campus Technical Staff

8. Drivers for a Multi-campus Approach to Middleware Financial While a one-size-fits-all approach may not work for all components, some economies of scale can be achieved. Political Being a State-subsidized institution, proper stewardship of public resources is always important, but it is especially important when budgets are tight.

9. Drivers for a Multi-campus Approach to Middleware Coordination Success even at the campus level will depend on a well coordinated approach. A Systemic effort will help reinforce the importance of coordination and cooperation. Help communicate the value of middleware and the benefits of the effort. Consistent with CSU Integrated IT Strategy

10. SupportTraining Network Hardware Software Access Infrastructure InitiativeBaseline Training & User Support Infrastructure Middleware Service Outcomes Initiative Applications The position of Middleware in the ITS Pyramid when viewed through the technology.

11. Drivers for a Multi-campus Approach to Middleware Maximize Value of Technology Investments Infrastructure Terminal Resources Project Common Management Systems PHAROS Library Project Help balance requirements for Strategic and Tactical planning Improve integration with other education institutions (e.g. EDUCAUSE, Internet2, etc.)

12. California State University Directories Working Group Technical Working Group charged by CSU system wide CIO’s to develop an Enterprise Directories strategy and test bed implementation

13. Group Dynamics Directories as the starting point for more comprehensive middleware effort Ad hoc effort to work collaboratively Volunteers/interested parties - 20-40 persons representing most campuses Smaller detailed architecture sub-group

14. Principles Collaborative effort among all CSU campuses Maintain appearance of unified directory architecture Adopt a system wide unique identifier Common view (eduPerson, etc.) Standard software (LDAP now, others later) Security at least as good as source data/applications/business processes

15. Key Recommendations Federated directory approach Common view incorporating eduPerson LDAP architecture Unique ID (unique vs. Linking) Internet2 involvement

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

17. Test Bed Implementation Five campuses (SLO, Hayward, Northridge, Pomona, Fresno) Mixed directory software (iPlanet, OpenLDAP, Oracle) Various levels of compliance with system wide schema (mandatory-optional attributes) Various population subsets (student, staff, real/sample) Various client access methods (specialized search engines, Microsoft ‘address book’, Netscape ‘address book’, LDAP command line clients)

18. Some Results So Far Response times are long (local server capacity, client referrals) Client handling of referrals varies (some do – some don’t) Coordination of referral trees at multiple sites is difficult

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 Will depend on projected system wide uses

20. Future of Group Larger scale central directory performance testing Automation of campus-to-central data feeds Design central registry reconciliation processes Lessons learned: need to commit resources, not just volunteer System wide direction: to be determined by Steering Committee

21. From Experiment to Institutional Response First Step: Middleware presented to the CSU Executive Council Executive Council is 23 Presidents + Chancellor 2/3 receive Middleware briefing in February Consensus: “We’re not sure what it is, but if this is what we need, let’s do it.”

22. “Citizen of the CSU” Scenarios Alice Chu is a junior biology major at Cal State Hayward, and a Citizen of the CSU. As a “traditional” student, most of Alice’s coursework is in classrooms at the Hayward campus, but last semester she was an intern at a biotechnology company in Anaheim. Using the 4Cnet, she was able to access all her usual Hayward resources, even though she was connected to her company’s intranet. Since she was in the area, she also registered to receive email about lectures in biology at Cal Poly Pomona and Cal State Fullerton, and attended one in-person and another via video streaming etc…

23. Result: Middleware Steering Committee Formed Charged by CSU CIO, David Ernst CIO’s from multiple campus, CSU auditor Asked to “come up with a plan” for Middleware for CSU Formed in May 2002, report due in October 2002

24. Highlights of Draft Recommendations Organized into three phases January 2003 – June 2003 July 2003 – December 2003 January 2004 – December 2004

25. Phase One: Jan 2003 – June 2003 Establish CSU Middleware Policy Board, reporting to TSC of Presidents Create initial policies Establish CSU-wide LDAP definition < EduPerson Establish a single, state-wide LDAP directory service replicate external-facing portion of individual directories one-third of campuses providing data to this directory. Pilot Shibboleth authorization.

26. Phase One: Jan 2003 – June 2003 Register the CSU as a certificate authority Establish a model and whitepaper to define best practices for identity reconciliation. Prepare a “good practices” whitepaper on developing campus registry and directories recipe for campus development statewide workshop

27. Phase One: Jan 2003 – June 2003 Work with CalVIP to integrate of the directory structure into Video initiatives. Working group to evaluate business case for CSU-wide permanent identifier for individuals Get commitment from CMS Executive Committee to assure integration into CMS baseline (ERP Project)

28. Phase Two: July 2003 – December 2003 Complete external directories for all entities. Move Shibboleth from pilot into full production. Develop a plan to integrate campus-wide directories into CMS and CSU Mentor (Admissions) Develop a plan to integrate campus-wide directories into Pharos (Library system). Pilot secure messaging/digital signature system, possibly based on PKI-Lite specification CSU-wide identifier - consider initial development of technology and procedures for implementation

29. Phase Three: January 2004 – December 2004 Complete Integration with CMS and CSU Mentor Complete integration with Pharos Extend secure messaging/digital signatures to all campuses Assignment of permanent identifiers in full operation. Pilot extension of Middleware infrastructure to Community College and K12 community.

30. Reaction within CSU CIO’s – very supportive – “we need to do this” Initial response from Library, ERP initiative has been positive Challenge to find resources in tight budget environment