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, Internet 2 /University of Michigan Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 11
Directories. . . Current • i. Planet LDAP duplicating DND – loaded from HRS & SIS • Peer. Logic X. 500 for Payroll Authorization Pilot • Corp. Time using Kerberos & DND Planned • LDAP loaded from HRS & SIS – Eduperson Schema • Directory Enabled Apps using central LDAP Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 19
Challenges. . . Human element of PKI Operation • Hardware “Keys” Password synchronization Privacy without loss of Electronic Services Internet 2 Fall 2000 Meeting: Early Adopters Report 20
Challenges - Technical Selection of PKI package • Driven by support 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 21 4
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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 28
Directories Status • Directory server in production • Resolving data and replication issues • Oversight process in draft form Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 32
Applications. . . Status • Class rosters with pictures • E-kiosk • Whitepages Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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, People. Soft 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 “person. ID” with linkages to roles Internet 2 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. ) Internet 2 Fall 2000 Meeting: Early Adopters Report 41
Authentication Before • Enterprise Unix IDs (NIS), RACF Ids, People. Soft 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 Internet 2 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 Internet 2 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) Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 45
How we got started Steps we took • Committed to standards • Joined I 2 Middleware Early Adopters program • Looked for “quick hit” projects Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 F 2 key… Account Management Pressure from underserved affiliate communities Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 62 4
Surprises Less resistance in the user community than expected…for now. Increased directory awareness equates to heightened pressure on legacy systems Internet 2 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 Internet 2 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) Internet 2 Fall 2000 Meeting: Early Adopters Report 65
Where We Started • University of Pittsburgh Directory Service (UPDS) in Early 1990 s – Custom built application – Difficult to Update and Maintain • Plans for Central Directory Service Began in 1998 – Accounts Management was Initial Application – Designed to support • Single Sign-on • LDAP Interface for E-mail • PKI Implemented – Initial use – 1998 virtual computer store Internet 2 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 • edu. Person – Inter-Institutional Directories – Resource Sharing • Implement Additional Directory Aware Applications – Student Information Systems – Course Management Tools – Human Resources and Payroll Internet 2 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. jwgst 10) – 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) Internet 2 Fall 2000 Meeting: Early Adopters Report 68
Identifiers • Planned – E-mail Aliasing Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 70
Directories • Planned – Standard use of Directory Enabled Applications – Establish Central Authoritative Source of Entity Information – Implementation of edu. Person – Widespread use of PKI – Directory Enabled Networks (DEN) Internet 2 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 (Smart. Cards) – Elimination of Legacy Authentication Internet 2 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 Internet 2 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 Internet 2 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 Internet 2 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 e. Commerce • Strategic Direction Endorsed by Provost’s Office Internet 2 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) Internet 2 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 Internet 2 Fall 2000 Meeting: Early Adopters Report 78
For More Information • www. internet 2. 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 Fall 2000 Meeting: Early Adopters Report Internet 2 79
Скачать презентацию Middleware Early Adopters Report Organization Policy Process Challenges 31 October
0e62ee76aa7cfb38aa606bbc3c4a1bc6.ppt