Middleware Early Adopters Report:Organization/Policy/Process Challenges
31 October 2000
Internet2 Fall 2000 Meeting: Early Adopters Report 2
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 3
Remedial IT architectureWhy 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 next-generation computing grids
Inter-institutional applications require interoperational deployments of institutional directories & authentication
Internet2 Fall 2000 Meeting: Early Adopters Report 4
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 5
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 oriented infrastructures
Internet2 Fall 2000 Meeting: Early Adopters Report 6
Dartmouth CollegeProfile
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 7
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 8
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 9
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 10
Identifiers
Before & Current• Universal Unique ID• E-mail: [email protected]
–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 11
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 12
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 13
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 14
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 15
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 16
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 17
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 18
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 19
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 20
Challenges...
Human element of PKI Operation• Hardware “Keys”
Password synchronization
Privacy without loss of Electronic Services
Internet2 Fall 2000 Meeting: Early Adopters Report 214
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 22
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 23
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 24
Michigan TechProfile
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 25
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 26
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 27
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 28
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 29
Directories
Status• Directory server in production
• Resolving data and replication issues
• Oversight process in draft form
Internet2 Fall 2000 Meeting: Early Adopters Report 30
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 31
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 32
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 33
Applications...
Status• Class rosters with pictures
• E-kiosk
• Whitepages
Internet2 Fall 2000 Meeting: Early Adopters Report 34
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 35
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 36
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 37
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 38
University of HawaiiProfile
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 39
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 40
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 41
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 42
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 43
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 44
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 45
Applications (cont)
Planned (continued)• One set of informational white pages
• [email protected] email address with optional user-specified delivery address
• System-wide portals
• Compatibility with national middleware initiatives
Internet2 Fall 2000 Meeting: Early Adopters Report 46
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 47
Challenges andCountermeasures
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 48
Challenges andCountermeasures (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 49
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 50
Tufts UniversityProfile
“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 51
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 52
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 53
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 54
Identifiers
Current• E-mail: [email protected]
– 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 55
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 56
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 57
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 58
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 59
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 60
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 61
Challenges and Countermeasures, cont.
Significant involvement of the community
Special attention of cross-organizational 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 624
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 63
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 64
University of PittsburghProfile
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 65
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 e-commerce
• Provide a foundation for efficient inter-institutional communication
• Enhance customer service (self service)
Internet2 Fall 2000 Meeting: Early Adopters Report 66
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 67
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 68
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 69
Identifiers
• Planned–E-mail Aliasing
Internet2 Fall 2000 Meeting: Early Adopters Report 70
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 71
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 72
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 73
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 74
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 75
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 76
How we got started
• A Strategic Direction Defined for Security and Standards
• A Need to Support Increased Demand for e-Commerce
• Strategic Direction Endorsed by Provost’s Office
Internet2 Fall 2000 Meeting: Early Adopters Report 77
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 78
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 79
For More Information
• www.internet2.edu/middleware/earlyadopters/• Dartmouth College
–Robert Brentrup [email protected]
• Michigan Technological University–Ann West [email protected]
• University of Hawaii–Russ Tokuyama [email protected]
• Tufts University–Lesley Tolman [email protected]
• University of Pittsburgh–Jeff Cepull [email protected]–Jay Graham [email protected]