Middleware Early Adopters Report: Organization/Policy/Process Challenges

Middleware Early Adopters Report:Organization/Policy/Process Challenges31 October 2000

Internet2 Fall 2000 Meeting: Early Adopters Report

PanelistsRobert 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


Remedial IT architectureWhy middleware?Proliferation of customizable apps requires centralization ofcustomizationsIncrease in power and complexity of the network requires access to user profilesElectronic personal security services is now an impediment to the next-generation computing gridsInter-institutional applications require interoperational deployments of institutional directories & authentication


What is Middleware?Specialized networked services that are shared by applications and usersA set of core software components that permit scaling of applications and networksTools that take the complexity out of application integrationSits above the network as the second layer of the IT infrastructureThe intersection of what networks designers and applications developers each do not want to do


Specific Application RequirementsDigital 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 directoriesNext-generation portals want common authentication and storage Administrative applications are adopting internet oriented infrastructures


Dartmouth CollegeProfileCombines the best features of an undergraduate liberal arts college with those of a research universityPrivate Residential Institution, founded 1769Professional Schools of Medicine, Business and Engineering4000 Undergraduate Students1200 Graduate Students 1200 Faculty380 Arts and Sciences, 760 Medical School


Why Deploy Middleware?Improve Customer ServiceImprove Administrative EfficiencyData and Transaction SecurityInternal and External E-commerceUse inter-institution standardsPossible Mandates


Where we startedDartmouth Name Directory (DND)Developed in 1986 to support e-MailMultiple Institutions SupportedCollege, Medical Center, Alumni, Valley.netE-mail: Reed College, Washington CollegeDatabase Sharing: Middlebury College


Where we are going - OverviewStandards BasedDirectories, Authentication, AuthorizationCross-institutionalDirectory lookupResource Sharing and AccessMore Directory and PKI Enabled Applications


IdentifiersBefore & CurrentUniversal Unique IDE-mail: firstname.mi.lastname@dartmouth.eduEnd user defined forwarding addressPartial / Nickname matchingUNIX account creation automated requests authenticatedPlannedUUID and E-mail unchangedMatching feature hard to add


DirectoriesBeforeDartmouth Name Directory (DND)Loaded from HRS and SIS, Sponsored accountsUser Modifiable: Nickname, E-mail, Paper mail, Campus Phone, URL, PasswordLibrary PatronsStudents loaded from SIS, Faculty & Staff on demandNT ids for print spoolingfrom authenticated e-mailOpen LDAP experiments


Directories...CurrentiPlanet LDAP duplicating DNDloaded from HRS & SISPeerLogic X.500 for Payroll Authorization PilotCorpTime using Kerberos & DNDPlannedLDAP loaded from HRS & SISEduperson SchemaDirectory Enabled Apps using central LDAP


AuthenticationBefore & CurrentDND passwordKerberos ticket using KClient/SidecarPlannedKerberosPort 80 ticket passing CGIPublic KeysInstalled in Web Browser and/or PK Client


AuthorizationBeforeMembership in DNDAdded other field checkseg.Dept affiliation discriminationCreated Course Enrollment ListsInter Domain Access Protocol (IDAP)Oracle Listener Process for UID recovery and table index


Authorization...CurrentLDAP master for white pagesDND backwards compatibilityPlannedLDAP primary categorization data sourceRule Language based authorization conditionsApplication Specific logic


ApplicationsBeforeE-mail, IP Dial-up, CWIS accessLibrary Remote Logins, Course Resource accessWeb Applications with SidecarWeb, UNIX, NT account creation, Degree Audit, Debit Card BalancesDCIS, Inter-Lib Loan, Document Delivery, IP address proxyCurrentPKI based Payroll Authorization


Applications...PlannedAccess to academic materialGrants and Contracts FormsTravel Expense VouchersAuthenticated WirelessUniversal Campus PKIMobile devices


How we got startedDriven by Vertical ApplicationsCross Group Project TeamTech Services, Admin Computing, Info Systems DirectorsKey Developers, Directory, E-mail, Admin PilotConsulting ServicesFundingPilot support by application and new projects budgets


Challenges and CountermeasuresPKI Policies and ProceduresCertificate and RegistrationMust change scale from 100 to 10,000Support Personnel for PKICampus Wide RolloutDocumentation, Consulting Support, Funding


Challenges...Human element of PKI OperationHardware KeysPassword synchronizationPrivacy without loss of Electronic Services


Challenges - TechnicalSelection of PKI packageDriven by support for forms and platformsHow many will we need?Client software installation significantLarge footprint and complexVersion update problemsUser management of credentials using files4


SurprisesVertical Application ahead of PKITechnical and Staff RolesUser Roles and DelegationDocument RepositoryNeed more than flat directory structureNeed to archive for some number of years, then can deleteIssues by-passed in development cycleDirectory integration and maintenanceMultiple applications using PKI / Policies


Surprises...Selected PKI technology to get secure signatures for Pilot but...Operational practices preventing guaranteePeople forget the credential passwordEffort to re-issue credentials caused short cutsSave time for users but...Additional Personnel needed to run PKI


Michigan TechProfileMichigan Technological UniversityPublic research universityTotal enrollment: 6,321 60% in engineeringGraduate enrollment: 660400 faculty and 1000 staffRanked programs in Environmental, Mechanical, and Metallurgical Engineering


Why deploy middleware?Manage cost while offering more servicesOffer tailored electronic servicesEnsure resources follow the userManage use of networked resourcesManage staffing requirementsReduce duplication of effortUse same data to feed different applicationsManage access to resources


Where we are goingEducate key campus constituents Deploy key applications Build directory serviceDeploy central authentication serviceImplement ongoing oversight process


IdentifiersBeforeHave unique identifier based on SCT BannerRequired for smart card, accounts, library Was it enough?PlannedReview identifiers and future requirementsStatus Developing plan to include new audiences


DirectoriesBefore Ph/white page application Identified public directory information Loaded from HR and Student systemsPlanned Implement LDAP enterprise directory Integrate authentication Integrate campus and directory apps Implement oversight process


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


AuthenticationBefore Unencrypted NIS authentication Passwords managed by departmentsPlanned Authenticate off directory Pilot early 2001Status Developing technical policy/procedures


AuthorizationBefore Local/application authorization Groups identified by departments Quasi-coordinated campus-widePlanned Manage groups in directoryStatus Developing data model


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


Applications...Status Class rosters with pictures E-kiosk Whitepages


How we got started Established an IT project team Developed initial project plan Purchased hardware and softwareTalked to key campus playersAdded campus data and technical staffEducated teamDeveloped more detailed project plan


Challenges and CountermeasuresSelling middleware Deliver applicationsIdentifying applications Flexible project management Good communicationDeploying in distributed environment Include department technical staff Ensure local control and performance


Challenges and Countermeasures...Dedicating staff Retrain existing staff Leverage other technical staff Hire temporary help Consider architecture carefully


SurprisesDifficult to sell Time commitment Dependency on clean data Continuous processGrouping in directories Translating political to technical Authentication and authorizationPolicy development


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 schoolsUH-Hilo and UH-West Oahu7 community colleges on four islandsExtensive distance learning programs on six islandsAffiliates include Research Corp, Foundation and East-West Center~ 60,000 students, faculty, staff


Why deploy middlewareDriving 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


IdentifiersBefore 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 IDsCurrent 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 systemPlanned A unique non-SSN personID with linkages to roles


DirectoriesBefore To varying degrees, paper phonebook Ph/Qi Telephone database ID database Source Data RealityCurrent Initial LDAP servers in production Contains ID, passwd, SSN, name, affiliation, home campusPlanned Accurate & timely updates from primary information sources (hires, terminations, registrations, etc.)


AuthenticationBefore 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 UnixCurrent First departmental application authenticating via LDAP from JavaPlanned One ID/password for authentication at enterprise & departmental levels Models for directory enablement from multiple platforms


AuthorizationBefore Application specificCurrent Student Employment system gets users affiliation from LDAPPlanned Determining appropriate mix of centralized and decentralized authorization attributes


ApplicationsBefore Online phone directory using PH/QI Multiple access to Unix NIS database (faked logins)Current (LDAP) Web Mail Student Employment Web appPlanned HR Leave Accounting Data (continued)


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


How we got startedSteps we took Committed to standards Joined I2 Middleware Early Adopters program Looked for quick hit projects


Challenges andCountermeasuresCentralized Functions (UH System) Human Resources FinanceDecentralized 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


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


SurprisesGood 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


Tufts UniversityProfileSmall, complex, independent, nonsectarian9,000 Students3 Campuses in Massachusetts7 SchoolsSchool of Arts, Sciences and EngineeringSchool of MedicineSchool of Dental MedicineSackler School of Graduate Biomedical SciencesSchool of Veterinary MedicineSchool of Nutrition Science and PolicyFletcher School of International Law and Diplomacy


Why Deploy Middleware?

Secure and efficient functioning in the electronic world relies on middleware Dependable authentication and authorizationCommon infrastructure promises reduced duplication, increased service quality


Where we startedOnline Directory 1996: White Pages functionality1997: Extended for limited account managementUniversal Tufts Log-in Name1998: Used for new email platformLDAP1998: Servers for email routing and addressbook lookup


Where we are going - OverviewStandards Based, LDAP compliant

Unique ID that isnt the SSN

Authoritative person registry


IdentifiersCurrentE-mail: firstname.lastname@tufts.eduEnd user defined forwarding addressBulk account creation automated Local support providers enabled to create and manage accountsPlannedUnique Universal IDFurther operationalize UTLNsChange processImplementation of stated retirement policyExpansion of use enterprise-wide


DirectoriesCurrentFoxpro databaseLoaded from HR, SIS and Medical affiliates dbasesFeeds read only LDAP subsetUser Modifiable: Nickname, E-mail, Paper mail, Campus Phone, URL, Password

PlannedLDAP loaded from HR, SIS and Medical affiliates databasesUse of Eduperson schemaDirectory enabled applications using central LDAP


AuthenticationCurrentName/password pair per service or server

PlannedEnterprise-wide UTLN/password pair using LDAP bind over SSL


AuthorizationCurrentLargely ad-hocNew services deployed with LDAP authorization built inDistributed email administration enabled through attributes of organizational roles and rights PlannedEnable latent LDAP-stored authorizationRetro fit existing services to LDAP authorization model


ApplicationsCurrentDistributed email administrationSelf-service IP address provisioningInfoboard (web publishing)PlannedRemote AccessSingle Sign OnPKI


How we got startedDirectory Data Quality and Ownership IssuesIMAP/LDAP/SMTP compliant emailReplacing the Banyan mail F2 keyAccount ManagementPressure from underserved affiliate communities


Challenges and CountermeasuresTufts Schools are at various levels of IT awareness and needMiddleware serves a profoundly centralized function Tufts is a profoundly decentralized organizationAll this stuff costs money


Challenges and Countermeasures, cont.Significant involvement of the communitySpecial attention of cross-organizational issuesAppeal to individual interests, not the enterprise visionLeverage any implicit understanding of why middleware must happen


Challenges - TechnicalClean migration off legacy systemsProduction values must approach those of real-time systemsBuilding for scale when future is unknown4


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


University of PittsburghProfilePublic, State-related, Research Institution founded in 178732,000 Students3,850 Faculty 5,325 StaffMore Than 12 Schools and Interdisciplinary ProgramsUniversity of Pittsburgh Medical Center (UPMC)Five Campus Locations in PennsylvaniaTitusville GreensburgJohnstownBradfordPittsburgh


Why Deploy MiddlewareEstablish 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)


Where We StartedUniversity of Pittsburgh Directory Service (UPDS) in Early 1990sCustom built applicationDifficult to Update and MaintainPlans for Central Directory Service Began in1998Accounts Management was Initial ApplicationDesigned to supportSingle Sign-on LDAP Interface for E-mailPKIPKI ImplementedInitial use 1998 virtual computer store


Where We are Going Overview

Focus on StandardsExpand Utilization of PKIStandardize on Single Authentication Method Consolidate AuthorizationeduPerson Inter-Institutional DirectoriesResource SharingImplement Additional Directory Aware Applications Student Information SystemsCourse Management ToolsHuman Resources and Payroll


Identifiers

BeforeSSN was Unique IDComputer Account Mapped to SSNUsername Ended in ST to Designate Student Accounts (e.g. jwgst10)Decentralized Account Administration (1500 Administrators)Account Creation/Termination Relied on AdministratorsCurrent Unique Identifier in Central Directory (CDS ID)Computer Account Mapped to PersonST Designation DroppedAccount Creation/Termination is AutomaticAccount Administration Consolidated (~40 Administrators)


Identifiers

PlannedE-mail Aliasing


Directories

Before UPDS and White PagesNo Global Address BookE-mail address housed in a separate systemUpdated Infrequently (~every two weeks)

Current Oracle-Based Central DirectoryGlobal Address Book provided via LDAPE-mail Information incorporated in DirectoryInformation Updated Nightly


Directories

PlannedStandard use of Directory Enabled ApplicationsEstablish Central Authoritative Source of Entity InformationImplementation of eduPersonWidespread use of PKIDirectory Enabled Networks (DEN)


Authentication Before Kerberos AuthenticationSystem Specific AccountsCurrent Kerberos AuthenticationNDS Authentication Synchronized to KerberosFewer System Specific AccountsPlanned Directory-based AuthenticationSingle Sign OnPKI Integration (SmartCards) Elimination of Legacy Authentication


Authorization Before Kerberos AccountIndividual Access Control Lists (ACL)Data ExtractionsIP and Domain RestrictionsCurrent Kerberos AccountIndividual Access Control Lists (ACL)Data ExtractionsIP and Domain Restrictions Directory InformationPlanned Directory Information


Applications

BeforeText-based Account LookupWeb-Based Search Engine

Current PKI used by e-StoreGlobal Address Book Integration Computer Accounts Management System


Applications

PlannedAuthentication to Restricted Web SitesAllocate University IT ResourcesRemote AccessAuthorized Access to Administrative SystemsHuman Resources and PayrollProcurement SystemCourse Management SystemStudent Information Systems


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


Challenges and Countermeasures

Early Adoption of PKIDigital Certificate PortabilityProvide Compelling Reasons for Users to ParticipateSupport Issues for PKI

Aligning Directory and Account Systems with University PoliciesIdentifying individuals entitled to access to IT resources

Departments Reluctant to Relinquish Control of Account Creation (1500 Administrators)


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 AffiliatesAlumniChaplin Emeritus FacultyVisiting Student or Faculty

Definition of Exceptions to Automatic Account Creation and Termination


For More Informationwww.internet2.edu/middleware/earlyadopters/Dartmouth CollegeRobert Brentrup robert.j.brentrup@dartmouth.eduMichigan Technological UniversityAnn West awest@mtu.eduUniversity of HawaiiRuss Tokuyama russ@hawaii.eduTufts UniversityLesley Tolman lesley.tolman@tufts.eduUniversity of PittsburghJeff Cepull cepull@pitt.eduJay Graham jwg@pitt.edu


Dartmouth, a coordinated school?Dartmouth shares a common implementation of personnel directory (authentication and white pages) and Kerberos infrastructure with the College Medical Center and a local non-profit ISP. Administrative systems development is centralized. Campus computer systems management is centralized.Need for signatures on and security for electronic transactionsBusiness is both internal and inter-institutional so the infrastructure needs to be an accepted standard4Dartmouth, a coordinated school?Dartmouth shares a common implementation of personnel directory (authentication and white pages) and Kerberos infrastructure with the College Medical Center and a local non-profit ISP. Administrative systems development is centralized. Campus computer systems management is centralized.Need for signatures on and security for electronic transactionsBusiness is both internal and inter-institutional so the infrastructure needs to be an accepted standard4

Middleware Early Adopters Report: Organization/Policy/Process Challenges

Documents

Early Adopters ACO Model

Schools Future Our - ICMA a School Brochure... · Schools.....

Internet2 Middleware Initiatives: Early Harvest to Early...

Aquiles Burlamaqui. Introdução Fundamentos Modelos...

Xuviate Offer for Early Adopters

Robot Middleware Standard “RT Middleware” Geoffrey...

Strengthen rotary: Early adopters 25 sept13

Middleware for Scalable Real-time Multimedia...

1 IL MIDDLEWARE Richiami sulla caratterizzazione dei sistemi...

CATEGORIES OF ADOPTERS

Early Adopters to Participatory Professional Development

Middleware Early Adopters Report: Technical Implementations