educause western regional

Educause Western RegionalCopyright Clouse, Ford, & Henry 2004

Developing a University Middleware Plan with a Diverse Task Force

S.Clouse, R.Ford, J.HenrySchool of Business Administration, IT Office, Computer Science Department

University of MontanaMissoula, Montana

Copyright Clouse, Ford, & Henry, 2004. 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.


What is Middleware?

GENERAL CONCEPT The mechanisms used to provide “single login, single identity” across a range of applications and domains

MORE SPECIFICALLY (from Internet-2 Middleware Initiative)• Directories include information about people and things (entities) and

their attributes, accessible to both users and applications• Identifiers are (unique) labels for entities• Authentication is the process of verifying that use of an identifier is

valid• Authorization is the process of deciding what an authenticated entity is

allowed to do• Security is the process of controlling authentication and authorization


The Middleware Challenge

To design and build a middleware framework that accommodates the diverse needs of central systems and managers, multiple academic and business units, and individual students and staff, and can be built and maintained with reasonable costs

Ideally, this framework would also allow “participation” in emerging global middleware frameworks (e.g., NSF Middleware, Cyberinfrastructure, …)


What is the Current State of Middleware?

FAMILIAR COMPONENTS • The typical enterprise information system (main source of entities and

attributes)• A mix of system and/or application specific user-name/password files, user-

capability files, system configuration files, …• Lightweight Directory Access Protocol (LDAP): a commonly used directory

structure• Active Directory: Microsoft’s version of the directory structure• On the “lower” edges: other lower level mechanisms for IP and IP name

space management (DNS, DHCP, NAT, …)• Emerging: global middleware components/standards (NSF initiative)GENERAL RESULT Mix of legacy databases and files, trying to mesh with

new global directory elements -- all striving for the same goals but with conflicting implementations


Middleware - Typical Campus Drivers

SYSTEM/LCUSTER/SERVER CONFIGURATION • Windows clusters: AD is mandatory• Unix/Linux clusters: consideration of true directory (vs. server based

A&A) may not be mandatory (yet), but it is inevitable • Mac clusters: same as Unix/Linux

BOTTOM LINE Since rolling out Windows/2000 system administrators (at least those with Windows commitments) have had to force the issue on campus wide directory structures. By now virtually every organization has some kind of AD and may also have LDAPs and other directories


Middleware - Typical Campus DriversENTERPRISE SYSTEMS Academic/Administrative Suite, Library System,

Course Management System, Email, Campus Card system, … Each system demands authentication and authorization based on entities and attributes, traditionally using its own system-specific directory mechanisms

• A/AS’s: typically built around a large internal database as directory => slow evolution to support LDAP and/or AD

• Library Systems: same as A/AS’s• Course Management Systems: evolving/evolved to LDAP and/or AD• Email: evolved to LDAP (Unix) XOR AD (Windows) • Others: varies along this spectrum BOTTOM LINE The requirement is typically “mutual coexistence” of both

LDAP and AD (and other application-specific directories?)


Middleware - Other Key Drivers

GLOBAL MIDDLEWARE ENVIRONMENTSThe idea is to extend the range of directories, entities, attributes,

authentication, and authorization across traditional campus boundariesThe applications envisioned are • current support for multiple (global) domain organizations -- e.g., the

University of Montana has four campuses -- UM - Missoula in Missoula, UM - Montana Tech in Butte, UM - Western in Dillon, and UM-Helena in Helena, all with unique “.edu” names but shared apps

• now evolving support for inter-organization resource sharing, i.e., shared access that crosses local directory structures

• now envisioned support for the “next generation cyberinfrastructure” in which cross-organization, cross-domain access will be the norm, not the exception -- goal is seamless sharing across global domains

EISBanner HDAP

LDAPFamily

ADFamily

OtherDirectories

App 1 App 2 App 3

Regulatory & Compliance Environment

Campus Directory Schematic

WORLD


Let’s Build It and Use It(what are the obstacles to use?)

IF YOU BUILD IT, WILL THEY COME?• Best case Build a directory solution that works for all campus

applications -- you can assume that all applications will convert to its use, over time

• Next-best Build a directory solution that satisfies some key enterprise/application systems -- you can assume that some will convert now and others may convert “later”

• Not-so-good Build a directory solution that satisfies central designers and some apps, then force all campus systems to use it

TYPICAL PROBLEM Key application X doesn’t A&A against an external directory (or requires features that are expensive or inconvenient to include in the directory)


Let’s Build It and Use It(what are the obstacles to “build”?)

DESIGN HURDLES• Agreement on initial directory structure, i.e., entities and attributes• Agreement on specific software and versions, i.e., exactly whose

directory• Agreement on processes that will evolve the directory structure, i.e.,

resolution of the inevitable “my application needs a new type of entity and/or new attributes” and “to realize the full potential of the new version of my application I need these entities/attributes to be added or modified”

BOTTOM LINE: For a medium to large organization, building a real directory is as much a social process as a technical process


Let’s Build It and Use It(what are the implementation obstacles?)

IMPLEMENTATION HURDLES• Must minimize single points of hardware failure: to the extent possible

(fiscal and technical constraints) the directory must survive individual computer crashes

• Must minimize network partitioning failure: to the extent possible (fiscal and technical constraints) the directory must survive network outages

BOTTOM LINE: The “directory” becomes a “directory system”, implemented with carefully designed and placed primaries and secondaries, algorithms to assure consistency across replicated distributed databases, etc.

And balancing fiscal, technical, and social concerns becomes an ever increaseing challenge


Let’s Build It and Use It(high level design constraints)

WHERE DOES THE INFORMATION COME FROM?• Data about system entities/attributes: relatively static, small volume,

typically entered by system administrators• Data about people entities/attributes: more dynamic, large volume,

most often must flow from, to, between enterprise systems

BOTTOM LINE: The “directory system” becomes a heavily used extension of information from enterprise holdings -- it likely now falls into the campus’ “compliance framework” because of the information it maintains about people and things. It also extends the enterprise holding by centralizing critical information used by and of interest to only system administrators -- it likely now falls into the campus’ “network security framework” because of the information it holds about systems.


Designing A Modern Directory System

OBSERVATION #1 A practical solution is obtainable only through multiple compromises involving systems/applications, some degree of fault tolerance, some compromise on attributes, and some “flow” between other enterprise systems and the “directory”, and some balance between facilitating access and restricting access

OBSERVATION #2 Compromise does not make everyone happy; in fact, a compromise might not make anyone happy

OBSERVATION #3 A central computer/network organization can- Unilaterally determine the compromise (i.e., push a central design on

the community), OR- Assist the user community in determining the compromise (i.e., pull a

design from the community)


A University Wide Task Force

MEMBERSHIP GOAL Width and breadth, in both technical and socio-political terms

Central IT Task Force formed by and reports through the CIOAcademic co-leaders Faculty from (major stakeholders) Business and

Computer Science -- Business through aggressive adoption of the M/S software, CS through semi-independent Unix and Windows labs and interest in global middleware

Other Members -- one rep each, representing- Computing Center Existing AD, LDAP, DNS, …- Library semi-independent library system plus large PC clusters- Student Affairs: PC clusters and (ugh) dorm users- Other academic departments: Education (PC and Mac clusters, outreach

component), Forestry (large, semi-independent research clusters, unique applications base

EISBanner HDAP

LDAPFamily

ADFamily

OtherDirectories

OIMOracle Portal

Unit ADForestEmail Unix

Email Exchange

Blackboard

Endeavor

Web

Portal

Data Warehouse

Other Apps

Test LabAD Forest


Task Force Approach

MULTI-PASS (SPIRAL) MODELPass 1- PlanDetermine existing and near term (application specific) LDAP

requirements Determine existing and near term (application and organization specific)

AD requirementsLook specifically at different options for AD design (subdomains,

organizational units, separate forests)Consider• Impact on maintenance of system information• Impact on maintenance of user information


Steering Committee Process

• Getting to know one another and learning about the differing needs (academic vs. administrative)

• Development of unit IT goals – more difficult for administrative/central representatives.

• Looked globally at middleware then focused on AD issues because of immediate needs.

• Documents:– Single Forest AD Model– Multiple Forest AD Model– DNS/DHCP/NAT Issues– Enterprise Middleware Model


Progress to Date - Phase One

GENERAL: too much information to tackle in one pass -- restrict consideration to system information only

LOGICAL REQUIREMENTS ON CENTRAL DIRECTORY General recommendations: fault tolerance, client support (directory

update service), and process (steering committee)Balance between centralized and distributed solutions- Analysis specific to single forest- Analysis specific to multiple-forest


Progress to Date - Phase 1

SINGLE FOREST DOCUMENT• Initial recommendations - Assuming Single Forest with multiple

subdomains and OU’s• Comments on fault tolerance & need for Steering Committee

REVIEW PROCESS– Received four reviews– Two focused had a decentralized perspective.– Two had a centralized perspective.– TF was surprised at what was not mentioned (i.e. steering

committee & support structure)


Progress to Come - Phase 2

• Cycle back through Single and Multiple Forest Models• Fault tolerance, more detail• User data and attributes - general• Flow of user data to/from enterprise systems• Impact on compliance framework


Conclusions

• Complex dynamics between distributed/academic units and central/administrative units (Technical, Social, & Political).

• Important for both distributed and central units to clarify IT needs and goals.

• IT technology is changing rapidly – implementing new products is very difficult in a mixed/distributed

environments.– Connecting both distributed and central applications via

middleware will be difficult.– Both central and distributed applications want to be THE

enterprise directory.


Continued Conclusions

• Regulation/compliance – Central responsibility – Difficult to monitor and control with distributed systems.– Distributed units may lose autonomy and the flexibility to

implement, manage, and upgrade systems on their own schedule.– Requires continuous communication between distributed and

central units.• Task force needs to focus more on users and less on the needs and past

problems from a systems administration perspective.• Progress is slow because the road is so long and winding.


Thanks!

• Questions or Comments?• http://www.umt.edu/middleware• Email Addresses

– [email protected]– [email protected]– [email protected]

Copyright Clouse, Ford, & Henry, 2004. 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.

http://www.umt.edu/middleware

mailto:[email protected]

