Middleware Early Adopters Report: OrganizationPolicyProcess Challenges

1
Middleware Early Adopters ReportOrganization/Pol
icy/Process Challenges
31 October 2000
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

3
Remedial IT architectureWhy middleware?

• Proliferation of customizable apps requires
  centralization ofcustomizations
• 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

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

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

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

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

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

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

10
Identifiers

• Before Current
• Universal Unique ID
• E-mail firstname.mi.lastname_at_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

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

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

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

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

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

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

17
Applications...

• Planned
• Access to academic material
• Grants and Contracts Forms
• Travel Expense Vouchers
• Authenticated Wireless
• Universal Campus PKI
• Mobile devices

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

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

20
Challenges...

• Human element of PKI Operation
• Hardware Keys
• Password synchronization
• Privacy without loss of Electronic Services

21
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

4
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

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

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

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

26
Where we are going

• Educate key campus constituents
• Deploy key applications
• Build directory service
• Deploy central authentication service
• Implement ongoing oversight process

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

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

29
Directories

• Status
• Directory server in production
• Resolving data and replication issues
• Oversight process in draft form

30
Authentication

• Before
• Unencrypted NIS authentication
• Passwords managed by departments
• Planned
• Authenticate off directory
• Pilot early 2001
• Status
• Developing technical policy/procedures

31
Authorization

• Before
• Local/application authorization
• Groups identified by departments
• Quasi-coordinated campus-wide
• Planned
• Manage groups in directory
• Status
• Developing data model

32
Applications

• Before
• Whitepages in ph
• Planned
• Applications portal
• DHCP
• Phone switch
• Account management
• E-mail forwarding (Sendmail)
• Thin-client data support

33
Applications...

• Status
• Class rosters with pictures
• E-kiosk
• Whitepages

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

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

36
Challenges and Countermeasures...

• Dedicating staff
• Retrain existing staff
• Leverage other technical staff
• Hire temporary help
• Consider architecture carefully

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

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

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

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

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

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

43
Authorization

• Before
• Application specific
• Current
• Student Employment system gets users
  affiliation from LDAP
• Planned
• Determining appropriate mix of centralized and
  decentralized authorization attributes

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)

45
Applications (cont)

• Planned (continued)
• One set of informational white pages
• firstname.lastname_at_hawaii.edu email address
  with optional user-specified delivery address
• System-wide portals
• Compatibility with national middleware
  initiatives

46
How we got started

• Steps we took
• Committed to standards
• Joined I2 Middleware Early Adopters program
• Looked for quick hit projects

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

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

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

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

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

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

53
Where we are going - Overview

• Standards Based, LDAP compliant
• Unique ID that isnt the SSN
• Authoritative person registry

54
Identifiers

• Current
• E-mail firstname.lastname_at_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

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

56
Authentication

• Current
• Name/password pair per service or server
• Planned
• Enterprise-wide UTLN/password pair using LDAP
  bind over SSL

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

58
Applications

• Current
• Distributed email administration
• Self-service IP address provisioning
• Infoboard (web publishing)
• Planned
• Remote Access
• Single Sign On
• PKI

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

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

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

62
Challenges - Technical

• Clean migration off legacy systems
• Production values must approach those of
  real-time systems
• Building for scale when future is unknown

4
63
Surprises

• Less resistance in the user community than
  expectedfor now.
• Increased directory awareness equates to
  heightened pressure on legacy systems

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

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)

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

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

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)

69
Identifiers

• Planned
• E-mail Aliasing

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

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)

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

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

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

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

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 Provosts Office

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)

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

79
For More Information

• www.internet2.edu/middleware/earlyadopters/
• Dartmouth College
• Robert Brentrup robert.j.brentrup_at_dartmouth.ed
  u
• Michigan Technological University
• Ann West awest_at_mtu.edu
• University of Hawaii
• Russ Tokuyama russ_at_hawaii.edu
• Tufts University
• Lesley Tolman lesley.tolman_at_tufts.edu
• University of Pittsburgh
• Jeff Cepull cepull_at_pitt.edu
• Jay Graham jwg_at_pitt.edu