Middleware Early Adopters Report:
Organization/Policy/Process
Challenges
31 October 2000
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
2
Remedial IT architecture
Why middleware?
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 nextgeneration computing grids
Inter-institutional applications require
interoperational deployments of
institutional directories & authentication
Internet2 Fall 2000 Meeting: Early Adopters Report
3
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
4
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
Internet2 Fall 2000 Meeting: Early Adopters Report
oriented infrastructures
5
Dartmouth College
Profile
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
Challenges...
Human element of PKI Operation
• Hardware “Keys”
Password synchronization
Privacy without loss of Electronic
Services
Internet2 Fall 2000 Meeting: Early Adopters Report
20
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
21
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
22
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
23
Michigan Tech
Profile
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
24
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
25
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
26
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
27
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
28
Directories
Status
• Directory server in production
• Resolving data and replication issues
• Oversight process in draft form
Internet2 Fall 2000 Meeting: Early Adopters Report
29
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
30
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
31
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
32
Applications...
Status
• Class rosters with pictures
• E-kiosk
• Whitepages
Internet2 Fall 2000 Meeting: Early Adopters Report
33
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
34
Challenges and
Countermeasures
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
35
Challenges and
Countermeasures...
Dedicating staff
•
•
•
•
Retrain existing staff
Leverage other technical staff
Hire temporary help
Consider architecture carefully
Internet2 Fall 2000 Meeting: Early Adopters Report
36
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
37
University of Hawaii
Profile
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
38
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
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
Challenges and
Countermeasures
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
47
Challenges and
Countermeasures (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
48
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
49
Tufts University
Profile
“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
50
Why Deploy
Middleware?
• Secure and efficient functioning in the electronic
world relies on middleware
– Dependable authentication and authorization
– Common infrastructure promises reduced duplication,
increased service quality
Internet2 Fall 2000 Meeting: Early Adopters Report
51
Where we started
Online Directory
• 1996: “White Pages” functionality
• 1997: Extended for limited account
management
Universal Tufts Log-in Name
• 1998: Used for new email platform
LDAP
• 1998: Servers for email routing and
addressbook lookup
Internet2 Fall 2000 Meeting: Early Adopters Report
52
Where we are going
- Overview
Standards Based, LDAP compliant
Unique ID that isn’t the SSN
Authoritative person registry
Internet2 Fall 2000 Meeting: Early Adopters Report
53
Identifiers
Current
• E-mail: firstname.lastname@tufts.edu
– End user defined forwarding address
• Bulk account creation automated
– Local support providers enabled to create and manage
accounts
Planned
• Unique Universal ID
• Further “operationalize” UTLNs
– Change process
– Implementation of stated retirement policy
– Expansion of use enterprise-wide
Internet2 Fall 2000 Meeting: Early Adopters Report
54
Directories
Current
• Foxpro database
– Loaded from HR, SIS and Medical affiliates dbases
– Feeds read only LDAP subset
– User Modifiable: Nickname, E-mail, Paper mail, Campus
Phone, URL, Password
Planned
• LDAP loaded from HR, SIS and Medical affiliates
databases
– Use of Eduperson schema
• Directory enabled applications using central LDAP
Internet2 Fall 2000 Meeting: Early Adopters Report
55
Authentication
Current
• Name/password pair per service or server
Planned
• Enterprise-wide UTLN/password pair using
LDAP bind over SSL
Internet2 Fall 2000 Meeting: Early Adopters Report
56
Authorization
Current
• Largely ad-hoc
• New services deployed with LDAP authorization built in
• Distributed email administration enabled through attributes
of organizational roles and rights
Planned
• Enable latent LDAP-stored authorization
• Retro fit existing services to LDAP authorization model
Internet2 Fall 2000 Meeting: Early Adopters Report
57
Applications
Current
• Distributed email administration
• Self-service IP address provisioning
• Infoboard (web publishing)
Planned
• Remote Access
• “Single Sign On”
• PKI
Internet2 Fall 2000 Meeting: Early Adopters Report
58
How we got started
Directory Data Quality and Ownership
Issues
IMAP/LDAP/SMTP compliant email
• Replacing the Banyan mail F2 key…
Account Management
Pressure from underserved affiliate
communities
Internet2 Fall 2000 Meeting: Early Adopters Report
59
Challenges and
Countermeasures
Tufts Schools are at various levels of IT
awareness and need
Middleware serves a profoundly
centralized function – Tufts is a
profoundly decentralized organization
All this stuff costs money
Internet2 Fall 2000 Meeting: Early Adopters Report
60
Challenges and
Countermeasures, cont.
Significant involvement of the
community
Special attention of crossorganizational issues
Appeal to individual interests, not the
enterprise vision
Leverage any implicit understanding of
why middleware must happen
Internet2 Fall 2000 Meeting: Early Adopters Report
61
Challenges - Technical
Clean migration off legacy systems
Production values must approach those of
real-time systems
Building for scale when future is unknown
Internet2 Fall 2000 Meeting: Early Adopters Report
4
62
Surprises
Less resistance in the user community
than expected…for now.
Increased directory awareness equates
to heightened pressure on legacy
systems
Internet2 Fall 2000 Meeting: Early Adopters Report
63
University of Pittsburgh
Profile
Public, State-related, Research Institution
founded in 1787
• 32,000 Students
• 3,850 Faculty
• 5,325 Staff
• More Than 12 Schools and Interdisciplinary
Programs
• University of Pittsburgh Medical Center (UPMC)
• Five Campus Locations in Pennsylvania
– Titusville
– Greensburg
– Johnstown
– Bradford
– Pittsburgh
Internet2 Fall 2000 Meeting: Early Adopters Report
64
Why Deploy Middleware
• Establish strategic direction for future
development efforts
• Establish a standard environment for transactions
and security
• Provide a foundation for internal and external ecommerce
• Provide a foundation for efficient inter-institutional
communication
• Enhance customer service (self service)
Internet2 Fall 2000 Meeting: Early Adopters Report
65
Where We Started
• University of Pittsburgh Directory Service (UPDS)
in Early 1990s
– Custom built application
– Difficult to Update and Maintain
• Plans for Central Directory Service Began in1998
– Accounts Management was Initial Application
– Designed to support
• Single Sign-on
• LDAP Interface for E-mail
• PKI
• PKI Implemented
– Initial use – 1998 virtual computer store
Internet2 Fall 2000 Meeting: Early Adopters Report
66
Where We are Going
Overview
• Focus on Standards
– Expand Utilization of PKI
– Standardize on Single Authentication Method
– Consolidate Authorization
• eduPerson
– Inter-Institutional Directories
– Resource Sharing
• Implement Additional Directory Aware
Applications
– Student Information Systems
– Course Management Tools
– Human Resources and Payroll Internet2 Fall 2000 Meeting: Early Adopters Report
67
Identifiers
• Before
– SSN was “Unique” ID
– Computer Account Mapped to SSN
– Username Ended in “ST” to Designate Student
Accounts (e.g. jwgst10)
– Decentralized Account Administration (1500
Administrators)
– Account Creation/Termination Relied on Administrators
• Current
– Unique Identifier in Central Directory (CDS ID)
– Computer Account Mapped to Person
– “ST” Designation Dropped
– Account Creation/Termination is Automatic
– Account Administration Consolidated (~40
Administrators)
Internet2 Fall 2000 Meeting: Early Adopters Report
68
Identifiers
• Planned
– E-mail Aliasing
Internet2 Fall 2000 Meeting: Early Adopters Report
69
Directories
• Before
– UPDS and White Pages
– No Global Address Book
– E-mail address housed in a separate system
– Updated Infrequently (~every two weeks)
• Current
– Oracle-Based Central Directory
– Global Address Book provided via LDAP
– E-mail Information incorporated in Directory
– Information Updated Nightly
Internet2 Fall 2000 Meeting: Early Adopters Report
70
Directories
• Planned
– Standard use of Directory Enabled Applications
– Establish Central Authoritative Source of Entity
Information
– Implementation of eduPerson
– Widespread use of PKI
– Directory Enabled Networks (DEN)
Internet2 Fall 2000 Meeting: Early Adopters Report
71
Authentication
• Before
– Kerberos Authentication
– System Specific Accounts
• Current
– Kerberos Authentication
– NDS Authentication Synchronized to Kerberos
– Fewer System Specific Accounts
• Planned
– Directory-based Authentication
• Single Sign On
• PKI Integration (SmartCards)
– Elimination of Legacy Authentication
Internet2 Fall 2000 Meeting: Early Adopters Report
72
Authorization
• Before
– Kerberos Account
– Individual Access Control Lists (ACL)
– Data Extractions
– IP and Domain Restrictions
• Current
– Kerberos Account
– Individual Access Control Lists (ACL)
– Data Extractions
– IP and Domain Restrictions
– Directory Information
• Planned
– Directory Information
Internet2 Fall 2000 Meeting: Early Adopters Report
73
Applications
• Before
– Text-based Account Lookup
– Web-Based Search Engine
• Current
– PKI used by e-Store
– Global Address Book Integration
– Computer Accounts Management System
Internet2 Fall 2000 Meeting: Early Adopters Report
74
Applications
• Planned
– Authentication to Restricted Web Sites
– Allocate University IT Resources
• Remote Access
– Authorized Access to Administrative Systems
• Human Resources and Payroll
• Procurement System
– Course Management System
– Student Information Systems
Internet2 Fall 2000 Meeting: Early Adopters Report
75
How we got started
• A Strategic Direction Defined for Security and
Standards
• A Need to Support Increased Demand for eCommerce
• Strategic Direction Endorsed by Provost’s Office
Internet2 Fall 2000 Meeting: Early Adopters Report
76
Challenges and
Countermeasures
• Early Adoption of PKI
– Digital Certificate Portability
– Provide Compelling Reasons for Users to Participate
– Support Issues for PKI
• Aligning Directory and Account Systems with
University Policies
– Identifying individuals entitled to access to IT resources
• Departments Reluctant to Relinquish Control of
Account Creation (1500 Administrators)
Internet2 Fall 2000 Meeting: Early Adopters Report
77
Surprises
• Technical People were Surprised that Cultural
and Policy Issues were the Principal Barriers
• User Adoption of Digital Certificates has been
Slow
• Definition of University Affiliates
– Alumni
– Chaplin
– Emeritus Faculty
– Visiting Student or Faculty
• Definition of Exceptions to Automatic Account
Creation and Termination
Internet2 Fall 2000 Meeting: Early Adopters Report
78
For More Information
• www.internet2.edu/middleware/earlyadopters/
• Dartmouth College
– Robert Brentrup
robert.j.brentrup@dartmouth.edu
• Michigan Technological University
– Ann West
awest@mtu.edu
• University of Hawaii
– Russ Tokuyama
russ@hawaii.edu
• Tufts University
– Lesley Tolman
lesley.tolman@tufts.edu
• University of Pittsburgh
– Jeff Cepull
– Jay Graham
cepull@pitt.edu
jwg@pitt.edu
Internet2 Fall 2000 Meeting: Early Adopters Report
79