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

Overview of Presentation

• California State University: background, strategy, drivers

• A grass roots experiment: the Directories Working Group

• Developing an Institutional Response

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

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

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

• Technology

Prerequisites

Outcomes

Initiatives

SupportTraining

Access

Net

wor

k

Har

dwar

e

Sof

twar

e

Initiatives / Projects

Dis

trib

uted

Lea

rn. &

Tea

ch.

Mul

timed

ia R

epos

itory

Libr

ary

Res

ourc

es

Student Friendly S

ervices

Com

mon. M

gt. System

s

Stream

line I/T Delivery

Procurem

ent Process Im

provement

One C

ard

Access Infrastructure Initiative

Cen

ters

for

Inst

. Tec

h. D

evel

op.

• 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

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

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.

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

SupportTraining

Net

wor

k

Har

dwar

e

Sof

twar

e

Access Infrastructure Initiative Baseline Training & User Support Infrastructure

Middleware

ServiceOutcomes

InitiativeApplications

The position of Middleware in the ITS Pyramid when viewed through the technology.

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.)

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

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

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

Key Recommendations

• Federated directory approach

• Common view incorporating eduPerson

• LDAP architecture 

• Unique ID (unique vs. Linking)

• Internet2 involvement

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)

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)

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

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

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

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.”

“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…

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

Highlights of Draft Recommendations

• Organized into three phases• January 2003 – June 2003• July 2003 – December 2003• January 2004 – December 2004

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.

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

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)

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

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.

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