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 Montana
Missoula, 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.
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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, …)
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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?)
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
Middleware - Other Key Drivers
GLOBAL MIDDLEWARE ENVIRONMENTS
The idea is to extend the range of directories, entities, attributes, authentication, and authorization across traditional campus boundaries
The 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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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)
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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.
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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)
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
Task Force Approach
MULTI-PASS (SPIRAL) MODEL
Pass 1- Plan
Determine existing and near term (application specific) LDAP requirements
Determine existing and near term (application and organization specific) AD requirements
Look 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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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)
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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.
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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.
Educause Western RegionalCopyright Clouse, Ford, & Henry 2004
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.