Middleware Early Adopters Report: OrganizationPolicyProcess Challenges - PowerPoint PPT Presentation

1 / 79
About This Presentation
Title:

Middleware Early Adopters Report: OrganizationPolicyProcess Challenges

Description:

Private Residential Institution, founded 1769 ... LDAP master for white pages. DND backwards compatibility. Planned ... Ph/white page application. Identified ... – PowerPoint PPT presentation

Number of Views:108
Avg rating:3.0/5.0
Slides: 80
Provided by: greg432
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com