Middleware early adopters report organization policy process challenges
This presentation is the property of its rightful owner.
Sponsored Links
1 / 79

Middleware Early Adopters Report: Organization/Policy/Process Challenges PowerPoint PPT Presentation


  • 41 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Middleware Early Adopters Report: Organization/Policy/Process Challenges

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Middleware early adopters report organization policy process challenges

Middleware Early Adopters Report:Organization/Policy/Process Challenges

31 October 2000


Panelists

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


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 next-generation computing grids

Inter-institutional applications require interoperational deployments of institutional directories & authentication

Remedial IT architectureWhy middleware?

Internet2 Fall 2000 Meeting: Early Adopters Report


What is middleware

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


Specific application requirements

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


Dartmouth college profile

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


Why deploy middleware

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


Where we started

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


Where we are going overview

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


Identifiers

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


Directories

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


Directories1

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


Authentication

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


Authorization

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


Authorization1

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


Applications

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


Applications1

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


How we got started

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


Challenges and countermeasures

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


Challenges

Challenges...

  • Human element of PKI Operation

    • Hardware “Keys”

  • Password synchronization

  • Privacy without loss of Electronic Services

Internet2 Fall 2000 Meeting: Early Adopters Report


Challenges technical

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

4


Surprises

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


Surprises1

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


Michigan tech profile

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


Why deploy middleware1

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


Where we are going

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


Identifiers1

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


Directories2

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


Directories3

Directories

  • Status

    • Directory server in production

    • Resolving data and replication issues

    • Oversight process in draft form

Internet2 Fall 2000 Meeting: Early Adopters Report


Authentication1

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


Authorization2

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


Applications2

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


Applications3

Applications...

  • Status

    • Class rosters with pictures

    • E-kiosk

    • Whitepages

Internet2 Fall 2000 Meeting: Early Adopters Report


How we got started1

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


Challenges and countermeasures1

Challenges andCountermeasures

  • 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


Challenges and countermeasures2

Challenges andCountermeasures...

  • Dedicating staff

    • Retrain existing staff

    • Leverage other technical staff

    • Hire temporary help

    • Consider architecture carefully

Internet2 Fall 2000 Meeting: Early Adopters Report


Surprises2

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


University of hawaii profile

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


Why deploy middleware2

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


Identifiers2

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


Directories4

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


Authentication2

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


Authorization3

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


Applications4

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


Applications cont

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


How we got started2

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


Challenges and countermeasures3

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


Challenges and countermeasures cont

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


Surprises3

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


Tufts university profile

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


Why deploy middleware3

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


Where we started1

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


Where we are going overview1

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


Identifiers3

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


Directories5

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


Authentication3

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


Authorization4

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


Applications5

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


How we got started3

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


Challenges and countermeasures4

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


Challenges and countermeasures cont1

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


Challenges technical1

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

4


Surprises4

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


University of pittsburgh profile

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


Why deploy middleware4

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


Where we started2

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


Where we are going overview2

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


Identifiers4

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


Identifiers5

Identifiers

  • Planned

    • E-mail Aliasing

Internet2 Fall 2000 Meeting: Early Adopters Report


Directories6

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


Directories7

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


Authentication4

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


Authorization5

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


Applications6

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


Applications7

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


How we got started4

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


Challenges and countermeasures5

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


Surprises5

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


For more information

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]

Internet2 Fall 2000 Meeting: Early Adopters Report


  • Login